On Tue, 2015-02-03 at 13:58 -0500, David A. De Graaf wrote:
This setup works, but is fragile.
For one thing, it is unsupported.
Well, 'supported' is always a somewhat weird notion when you're
dealing with free operating systems. Do we 'support' shared /boot ?
The installer happens to allow it, but we don't do any tests on it,
and no-one seems hugely enthused about fixing any problems it causes,
so...is it 'supported'?
Secondly, the boot machinery in /boot is static, and once created,
there's no way to recreate it. Should it ever be lost, or made
Well, you can always just take a backup. The 'configfile' directive is
a supported part of grub2. It shouldn't change so long as grub2 is
Thirdly, when it's time to install a new Fedora in the parallel
filesytem, I must be exquisitely careful not to allow the Master
Boot Record and all the usual boot mechanism to be recreated, but
instead to follow these instructions precisely:
Here are instructions stolen from Adam Williamson's blog post
with slight edits:
1. Begin Fedora installation as usual.
2. Enter the Installation Destination spoke.
3. Click on "Full disk summary and bootloader.." at the bottom
4. Select the disk with a check and click "Do not install
5. Click Close, and proceed with installation as desired
6. When installation is complete and Fedora tells you to reboot,
DON'T! Instead hit ctrl-alt-f2, and run the following
7. chroot /mnt/sysimage
8. echo "GRUB_DISABLE_OS_PROBER=true" >> /etc/default/grub
9. grub2-install --no-floppy /dev/sda6 --grub-setup=/bin/true
10. grub2-mkconfig -o /boot/grub2/grub.cfg
Yeah, I do wish someone would pick up the bug about creating the grub
config file when not installing the bootloader...
This actually works! I've done it. Having separate /boot
offers the advantage that yum updates to, say, F21 affect solely the
f21 root filesystem, and likewise for F20. Nothing ever messes with
Yes, this is why I'd strongly advise using a setup like this *anyway*
over using a shared /boot.
However, I live in terror that one day I might lose Adam
Williamson's recipe, mistype it (steps 8, 9, 10), or simply forget
to block the installer from its normal actions (step 4).
Well, that wouldn't really be unrecoverable if it ever happened. You'd
be able to recreate the 'master' bootloader config from the newly-
installed OS. It'd just be a case of doing an appropriate grub2-
install invocation. And you'd at least have the OS you just installed
The RIGHT way is to revert to the traditional cohabitation of
multiple boot files in a common /boot partition.
I'm glad that's being considered.
I disagree. It's not 'traditional', and it's not a good design, it's a
There are a million different ways people do multiboot, and more or
less everyone thinks theirs is the obvious, sensible, normal,
traditional way to do it...and really, none of them is any good and
it's a miracle they don't all fall apart more often. Having dealt with
all the multifarious bugs in all of 'em over the years, FWIW, I avoid
multiboot like the plague. One system, one OS. If I want to run any
others I do it in virtualization. Makes life much simpler. Multiboot
is fundamentally and unavoidably a hacky mess.
If the bootloader spec proposal ever gets any traction it would
improve matters a bit, but I'm not sure where we stand on that.
One thing more: The problem being attacked here stems from losing
control of what's in initramfs, I sincerely believe. This file,
originally was merely an intermediate step - a basic all-purpose
kernel that would initialize the conditions to start the real
Er...it's not a kernel and never has been. It's a filesystem.
The initramfs has always been specific to at least a kernel version.
We now have the dracut stuff which customizes initramfs to the
installed system, but even before that, you couldn't safely have let
Fedora N anaconda re-generate the initramfs for Fedora N-1. It'd never
have been a good idea. What changed was various stuff in how anaconda
deals with initramfs files, all for good reason - I went through the
history already, it's in an older post somewhere.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net