Does anyone reuse /boot or /var partitions ?

[Adam Williamson]

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 
> obsolete,
> I'm screwed.

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 
around.

> Thirdly, when it's time to install a new Fedora in the parallel root 
> 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
> http://www.happyassassin.net/2014/01/08/how-to-do-manual-multi-boot-configuration-with-fedora/
> 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 
> left
>  4.   Select the disk with a check and click "Do not install 
> bootloader"
>  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 
> commands:
>  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 
> subdirectories
> offers the advantage that yum updates to, say, F21 affect solely the 
> f21 root filesystem, and likewise for F20.  Nothing ever messes with 
> /mainboot
> (but me).

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 
available.

> 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 
mess.

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 
> kernel.

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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net