Re: [lmi] More robust multibooting

[Vadim Zeitlin]

On Tue, 10 Sep 2019 23:46:03 +0000 Greg Chicares <address@hidden> wrote:

GC> For quite a while, I had been managing a multiboot system as follows:
GC>  - set up a dedicated boot partition
GC>  - mount that as /boot in every installation's /etc/fstab
GC>  - when debian issues a new 'stable' release, create a new partition
GC>      for it, and do a fresh installation from scratch there

 Hi,

 FWIW I don't really see much point in multi-booting different Linux
systems, when it's simpler to just install them in chroot or, if you want
to be more modern, Docker containers and have just a single bootable
system.

GC> Then I tried to install fedora (so that I'd have an optional system
GC> that's more similar to the RHEL server in the office).

 Please note that Fedora is not that similar to RHEL at all. CentOS is
almost identical to RHEL, however, so I recommend having a CentOS boot
partition/chroot/Docker container/VM/whatever instead.

GC> You see where this is going. When I install a new GNU/Linux system,
GC> by default it wants to take ownership of grub.

 I haven't installed RH/Fedora since a very long time, doesn't it give you
an option of leaving the boot loader alone?

GC> Long story short, my debian system became unbootable. I tried rebooting
GC> it from several different live CDs (debian; 'grub rescue disk';
GC> 'rescatux'), but none of those actually worked in this case--at worst,
GC> they failed utterly, and at best, they booted into a partly-working
GC> system.

 Sorry, I have no idea why did this happen. I understand that Fedora could
have overwritten the old Grub installation, but you still ought to be able
to boot from Grub command line.

GC> Now, since debian had promoted 'buster' to 'stable', I figured it
GC> was time to upgrade anyway, so I installed 'buster' on its own
GC> partition. When I chrooted into the old 'stretch' system, it mostly
GC> worked, but not quite: notably, my trackball didn't work, and it's
GC> rather difficult to use xfce with no pointing device.

 I have problems with the pointing device on my notebook under Buster too,
and I still haven't found the real solution (it does work for me, just in a
suboptimal way, so the problem is less urgent). As a very dumb workaround I
can only advise connecting any old USB mouse to the machine.

GC> But by now I had dug so deeply into grub that I wanted to find out
GC> how to make it "just work". Here's the answer I came up with:
GC> 
GC> $cat /etc/grub.d/40_custom
GC> menuentry 'Debian GNU/Linux 9 (stretch SIMPLE) (on /dev/sda1)' {
GC>         insmod part_msdos
GC>         insmod ext2
GC>         set root='hd0,msdos1'
GC>         search --no-floppy --label --set=root --label stretch
GC>         echo    'Loading stretch (simply) ...'
GC>         linux   /vmlinuz root=LABEL=stretch ro intel_iommu=on 
libata.force=noncqtrim
GC>         echo    'Loading initial ramdisk ...'
GC>         initrd  /initrd.img
GC> }
GC> 
GC> This is starkly different from the menu entries written by
GC> 'update-grub'. Most notably, the boot partition isn't mentioned
GC> here at all. This installation (which is the 'stretch' system I've
GC> been using for years) is on /dev/sda1 = (hd0,msdos1), and this
GC> 40_custom stanza mentions no other drive or partition at all.
GC> And it has the great virtue of actually working.

 I use LVM on all my Debian machines (and RAID 1 on most of them), so I
don't even know what does update-grub do in the simple case, when neither
is used, but the stanza above looks fine to me and, anyhow, as long as it
boots the system, I don't see what else could be asked from it.

GC> First of all, UUIDs are really not such a great idea. True, they
GC> were helpful on my old supermicro where I often swapped rotary
GC> hard disks in and out: that is, they're less impermanent than
GC> device names like /dev/sda. But UUIDs can change, for reasons
GC> that I don't necessarily understand.

 I'm afraid I can't really help with this neither. I've never seen UUIDs
change on their own, but then I never install multiple systems on the same
machine (once I install Debian somewhere, it just lives there until the
hardware dies -- and sometimes even outlives it by migrating to the next
incarnation of the same physical machine).

GC> The debian installer, for instance, reformats any swap partitions it
GC> finds, resulting in a different UUID. I now think labels should be used
GC> instead: they're less likely to change; any software that incidentally
GC> alters them is more likely to erase them altogether, which may be
GC> inconvenient but is easily seen and fixed; and they're easier to read
GC> and type.

 Labels are definitely more readable, so I think they're preferable just
for this.

GC> This is a single-user system with 'hibernate' and 'suspend' both
GC> inhibited,

 Why would you do this? Both are IMO extremely useful, even for the desktop
machines (how do you preserve your multi-year uptime during power outages
without hibernate?).

GC> so it should be perfectly fine to share a swap partition
GC> across all installed linuces. However, coping with UUID changes is
GC> not as simple as changing /etc/fstab: there's a swap UUID in
GC>   /etc/initramfs-tools/conf.d/resume
GC> which matters at boot time even though I never hibernate or suspend,

 FWIW I use a disk path (/dev/sdaN) in this file. I have no memory about
why do I do this, as Git history of my /etc only starts in 2009 and this
file already existed for quite some time before then.

GC> and setting its contents to 'RESUME=' or 'RESUME=NONE' doesn't work:
GC> apparently it's necessary to insert the updated UUID, and then of
GC> course 'update-initramfs -u'. Questions:
GC> 
GC>  - Does it even make any sense to use swap, on a 32-hyperthread box
GC>      with 64GB of RAM?

 I always use swap for suspend/hibernate anyhow, but if you really don't
want to enable either, then I'm pretty sure you can live without swap. If
something really eats up 64GiB of RAM, I don't think swap will help you
much anyhow.

GC>  - If swap is still useful, wouldn't a swapfile be better than a
GC>      swap partition, given that partitions have fragile UUIDs,
GC>      while a swapfile can be local?

 Many years ago using swap files was significantly slower than using swap
partitions, but this point is probably moot if you're never actually going
to use it anyhow. I still don't see much point in having a swap file
however.

GC> So I'm inclined to suppress swapping altogether. Is that unwise?

 I don't think so. As I said, I do have swap on all my machines, but,
except for some old ones, it's never used (I've just looked at munin swap
in/out graphs and they're basically all flat lines at 0 pages swapped).

GC> At any rate, this box has two SSDs, each of which has a dedicated
GC> swap partition (rationale: it should still work if I remove one of
GC> the drives, or if one gets bricked), and the debian installer tries
GC> to use both; I think I should use one at most, if not zero. It seems
GC> silly enough to use a 4 GB swap partition, but using two for a total
GC> of 8 GB is surely much more trouble than it's worth.

 FWIW on the systems using RAID 1 I typically create swap partition on one
of the disks and the partition where /tmp is mounted on the other, with the
idea that neither swap nor /tmp are really precious enough to use RAID 1
for them and I can save a bit of disk space (which is completely irrelevant
for the spinning disks nowadays, but still is a bit for SSDs) like this.

 Regards,
VZ

pgpzIsz3s5J89.pgp
Description: PGP signature