Adam Williamson composed on 2015-01-22 18:39 (UTC-0800):
On Thu, 2015-01-22 at 21:21 -0500, Felix Miata wrote:
Not mounting as boot a partition containing kernels and/or initrds in its root I could understand and agree with, but not forced reformatting.
As things stand anaconda just doesn't have this degree of precision. I think I'm right in saying nothing in anaconda looks at the actual contents of existing partitions at all. It just knows whether there's already a filesystem on the device, and whether you're reformatting it.
Even so, I don't understand what the problem is that dracut can't be limited to producing images based on /lib/modules, name matches to the installing arch, whatever is in the list of packages Anaconda has selected to install, or some other kind of matching. Simply recognizing that a filesystem is supported or not ought to be enough for it to decide if a fresh filesystem is appropriate for the little activity /boot gets.
So honestly I pretty much consider most multiboot configs more trouble than they're worth, but what I'm not understanding from any of the descriptions so far is what actual value you get from sharing a partition mounted at /boot between multiple distributions?
I provided no use case for sharing a /boot partition among more than one / on a multiboot system. I objected to eradicating non-conflicting subdirectories located on a filesystem proposed for use as /boot, and provided reasons supporting my objection.
The point of the partition mounted at /boot *to a Linux distribution* is that it's where it should install its kernels and things to.
Right, but I recall nothing in FHS that says an admin should have no right to store other things that do not conflict with what is expected to live there, rather like /mnt or /media.
FWIW, something is putting "theme" files in /boot even though what the theme is for is not installed. Why aren't theme files for the bootloader among the places other things that use themes expect to find them?
Nothing I've seen so far actually seemed to indicate any situation where it was useful for one distribution to be able to see another's kernels.
Neither I.
All the setups discussed so far seem to be based on the design where you have a 'master' bootloader which chainloads each distro's own bootloader. OK, but then what's the point of sharing or reusing a /boot partition?
Creating extra trouble potential?
I don't actually see, in your description, where you need to reuse a /boot partition. The first OS install creates it fresh, then
In my scenario, the OS installation does not create a filesystem on a /boot partition. I first create partitioning, then format partition for bootloader, put bootloader on partition, and only afterward install the first operating system.
subsequent installs don't use it - they have their /boot directories on their root partitions. You don't actually seem to re-use the partition you call 'realboot' in a later OS installation at all, do you? Or am I missing a step somewhere?
Maybe you skipped over #2, #3 & #4 in my list? I don't re-use *as* /boot. Use as /boot only ever happens here for the first OS installation. But, I do on occasion have use for the content I put on it both before and after the first OS installation, as well as while the first is the only, regardless of where it's mounted.
For "before" it might have a rawhide directory with network installation kernel and initrd, which I would expect to use again later if I abort the installation before completion, or it aborts itself when the network goes down for several hours. I can't be the only one doing network installs without using removable media or PXE.
It *does* already have a bootloader on it, and since I don't ever allow Grub2 to be installed except to a *buntu installation, Anaconda wiping mine would mean no booting HD at all, and me having to redo everything I did to get Anaconda started in the first place, after backing up what Anaconda put there, and afterward putting it back.