Re: [gentoo-user] Re: How to set up drive with many Linux distros?
On Friday, 8 March 2024 23:24:02 GMT Grant Edwards wrote: > On 2024-02-22, Grant Edwards wrote: > > For many years, I've used a hard drive on which I have 8-10 Linux > > distros installed -- each in a separate (single) partition. > > > > [...] > > > > Is there an easier way to do this? > > After some additional studying of UEFI and boot managers like rEFInd, > I decided that my current approach was still the easiest method. I did > switch from DOS to GPT disklabel (I bricked my old drive tring to > update the firmware, so I had to start over anyway). > > In case anybody is interested in the gory details, I documented my > scheme and the helper shell scripts at > > https://github.com/GrantEdwards/Linux-Multiboot Thank you Grant for taking time to share your clear and well structured write up, what with helpful scripts and all! Its easy to follow and should help others, hopefully before they discover belatedly many distro installers can mess up a multiboot scheme, if they don't step in to keep things in check. Perhaps I'm picking up on semantics, but shouldn't this sentence: "... The gap between the DOS disklabel and the first partition" read: "The gap between the MBR and the first partition"? I'm saying this because the MBR in sector 0 contains the bootstrap code (446 bytes), the partition table (a.k.a. DOS disklabel 4x16 bytes) and the boot sector signature (2 bytes). On MBR partitioned disks the core.img is stored after the MBR, in sector 1 onward. Your next paragraph pointed out something which I hadn't considered at any length. Namely, the installation of GRUB's boot.img in a MBR or VBR also hardcodes in a block list format the location of the first sector where the core.img is stored and more importantly, the physical position of this sector can be altered both by COW fs (and by the wear levelling firmware of flash storage devices). I had assumed both the COW fs and/or the flash controller will in both cases translate any physical data position to the logical layer and presented this to inquiring software. Have you actually tried using btrfs as a distro's root fs to see if the VBR installed GRUB boot.img will ever lose access to the core.img? signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: How to set up drive with many Linux distros?
On Tuesday, 27 February 2024 00:12:07 GMT Mark Knecht wrote: > I have no experience beyond three operating systems on a single machine > but if you grabbed just 2 or 3 USB flash drives then I would think you > could test it pretty easily. I believe the UEFI boot procedures are > storing a unique ID for the disk or the partition you are requesting. If you > have a unique ID that's different for each flash drive it would (hopefully) > find the one you're looking for which should be relatively simple. > > I would suggest you use the boot ordering feature and make the > system hard drive last in the list. If no USB devices are plugged in > it would default to your system drive. If a flash drive is plugged in > it should find its ID and boot that first. > > I do not know if, for instance, you had 20 different drives listed in > your BIOS whether it would be a lot slower to boot but you could > test that yourself. My experience is that the BIOS will discard any boot devices that are not present at the time of booting. I don't know whether that's typical or just what I've found. -- Regards, Peter.
Re: [gentoo-user] Re: How to set up drive with many Linux distros?
On Mon, Feb 26, 2024 at 4:45 PM Grant Edwards wrote: > > On 2024-02-26, Wol wrote: > > On 26/02/2024 20:51, Grant Edwards wrote: > > > >> The simple answer is to quit wasting time trying to multi-boot like > >> that and just buy a dozen USB flash drives. > >> > > And then, if USB isn't the default boot media, he might as well sort out > > UEFI boot, and multi-boot that way. > > Except that every time I've found a write-up about multibooting a lot > of Linux distros with UEFI, it turns out that it doesn't actually work > very well and is more work to maintain than what I'm doing now. > > -- > Grant I have no experience beyond three operating systems on a single machine but if you grabbed just 2 or 3 USB flash drives then I would think you could test it pretty easily. I believe the UEFI boot procedures are storing a unique ID for the disk or the partition you are requesting. If you have a unique ID that's different for each flash drive it would (hopefully) find the one you're looking for which should be relatively simple. I would suggest you use the boot ordering feature and make the system hard drive last in the list. If no USB devices are plugged in it would default to your system drive. If a flash drive is plugged in it should find its ID and boot that first. I do not know if, for instance, you had 20 different drives listed in your BIOS whether it would be a lot slower to boot but you could test that yourself. Good luck, Mark
Re: [gentoo-user] Re: How to set up drive with many Linux distros?
On 26/02/2024 20:51, Grant Edwards wrote: On 2024-02-26, eric wrote: I agree, using the custom.cfg file would not work if needing to boot different kernels of the same OS and those kernels were being updated. The simple answer is to quit wasting time trying to multi-boot like that and just buy a dozen USB flash drives. And then, if USB isn't the default boot media, he might as well sort out UEFI boot, and multi-boot that way. Cheers, Wol
Re: [gentoo-user] Re: How to set up drive with many Linux distros?
On 2/26/24 11:01, Grant Edwards wrote: On 2024-02-26, eric wrote: On 2/26/24 04:57, gentoo-u...@krasauskas.dev wrote: You could also write a script that keeps all the distros up to date from within whichever one you're currently booted by mounting subvolumes to /mnt or wherever, chrooting in and running the update. To avoid grub not being able to point to a newly updated kernel on one of the OS's installed, I use a "custom.cfg" file in all my /boot/grub/ directories for each OS where the "linix" and "initrd" point to the symbolic links of the kernel and init files which point to the newly updated files on most major distributions like ubuntu, arch, suse, and debian. The name of the symbolic links stay the same over upgrades. It works great when using UUID to identify the partition that has root and I can always boot into any of the OS's installed no matter which one hijacked the MBR. Except I generally have multiple kernels installed for each of the distros, and need to be able to choose which kernel to boot. There are also various other boot options (e.g. "safe mode") offered by some distros that I occasionally need to use. I agree, using the custom.cfg file would not work if needing to boot different kernels of the same OS and those kernels were being updated. Regards, Eric
Re: [gentoo-user] Re: How to set up drive with many Linux distros?
On Fri, Feb 23, 2024 at 12:52 PM Grant Edwards wrote: > > On 2024-02-23, Mark Knecht wrote: > > On Fri, Feb 23, 2024 at 11:59 AM Grant Edwards < grant.b.edwa...@gmail.com> > > wrote: > >> > >> The simple solution is to give up on multi-booting a dozen different > >> distros on a single disk and buy a pocketful of USB 3 thumb drives. > >> > > > > Given performance does drop a bit and there can be issues with allocating > > hardware, why not use Virtualbox which allows you to run both your base > > distro and then as many of the others as your hardware can handle as VMs? > > The machine is used for testing PCI and PCI-express boards and their > drivers. I don't really trust PCI passthrough (especially when it > comes to interrupt handling) enought to do such testing in a > VM. IFAICT, it's very rare for customers to use VMs. If customers do > start to use VMs, then we'll have to test with VMs also. > In that specific use case I completely agree. The only other idea I had was to install to a different disk and then use something like Clonezilla to move it to the partition you want it in on your system. While I suspect you were being sarcastic I do not think any solution that involves a 'pocketful of USB 3 thumb drives' will be satisfying. Wishing you luck, Mark
Re: [gentoo-user] Re: How to set up drive with many Linux distros?
On Fri, Feb 23, 2024 at 11:59 AM Grant Edwards wrote: > > > The simple solution is to give up on multi-booting a dozen different > distros on a single disk and buy a pocketful of USB 3 thumb drives. > Given performance does drop a bit and there can be issues with allocating hardware, why not use Virtualbox which allows you to run both your base distro and then as many of the others as your hardware can handle as VMs? This is how I go about investigating a new distro before committing to it.
Re: [gentoo-user] Re: How to set up drive with many Linux distros?
On 23/02/2024 00:28, Grant Edwards wrote: In my experience, 's bootloader does not boot other installations by calling other bootloaders. It does so by rummaging through all of the other partitions looking for kernel images, intird files, grub.cfg files, etc. It then adds menu entries to the config file for 's bootloader which, when selected, directly load the kernel image and initrd from those other partitions. Sometimes, it works -- at least until those other installations get updated without the knowlege of the distro that currently "owns" the MBR's bootloader config. Then it stops working until you tell that bootloader to re-do it's rummaging about routine. IME distros that try that (SUSE, anyone!) generally get confused as to which kernel belongs to which root partition. Hence needing to boot with a live distro to edit the resulting mess and get the system to actually come up without crashing ... Cheers, Wol
Re: [gentoo-user] Re: How to set up drive with many Linux distros?
On Friday, 23 February 2024 00:28:59 GMT Grant Edwards wrote: > On 2024-02-22, Wol wrote: > > On 22/02/2024 21:45, Grant Edwards wrote: > >> I've been reading up on UEFI, and it doesn't seem to be any > >> better. People complain about distro's stomping on each other's files > >> in the ESP partiton and multiple distro's using the same name in the > >> boot slots stored in NVM. And then the boot choice order changes > >> (though it may not be apparent to the naked eye) when one of the > >> distros decides to update/reinstall its boot stuff. > > > > At least if you use UEFI *as* your bootloader, then that won't > > happen. That assumes you're using UEFI, though! > > According to what I've read UEFI isn't a bootloader. It's a boot > manager which can load and run EFI bootloaders (of which there can be > multiple installed). The UEFI firmware of the MoBo contains its own bootloader and a boot manager with its own boot menu, initialised and running from the MoBo's EEPROM. Unlike conventional/legacy bootloaders stored in the first sector of a disk (MBR), the UEFI firmware is stored in the MoBo's EEPROM, a larger equivalent to the old CMOS. However, this comes with the caveat the UEFI 'bootloader' can only load .efi executables which have already been placed in the FAT32 formatted EFI System Partition (ESP). Unlike GRUB's MBR Stage 1 bootloader code, the UEFI firmware is large enough to contain its own fs driver to be able to read the ESP fs content and identify and run all .efi applications. Kernel images which have been built with the EFI stub and therefore masquerade as .efi compatible files can be loaded directly by the UEFI firmware without the need of an additional bootloader. > > In which case, 's bootloader doesn't get a look-in. > > Yes, AFAICT, it does (sometimes?). When you install under > UEFI it installs EFI bootloader files (either kernels wrapped in EFI > bootloader executables or the grub EFI bootloader) in the EFI Systgem > Partition (ESP), and then adds one or more entries in the EFI NVM that > points to those files (or something like that). The Linux UEFI > systems I have all still use grub2 (which gets written to the ESP). Legacy GRUB on an MBR partitioned disk, writes its Stage 1 bootloader code in the first sector and Stage 1.5 with the fs drivers in sector 34, before the first partition. GRUB2 on a UEFI system installs the file /efi//grubx64.efi in the ESP, an equivalent of the Stage 1 and Stage 1.5 of legacy GRUB. The Stage 2 /boot/ grub/ files can be installed either in the ESP, or on a different partition. > It's entirely possible for one distro to overwrite files in the ESP > that belong to other distros. I've read multiple complaints about > exactly that when trying to do multi-boot with UEFI. In practice it's > just like the fight over who owns the MBR and the DOS disklable gap. It doesn't really matter if the grubx64.efi executable is overwritten, as long as the OS_PROBER is not disabled in /etc/default/grub. Re-running grub- mkconfig will re-scan the ESP and any drive/partitions, pick up any OS kernel images known by GRUB and add them to GRUB's boot menu. The problem starts if/when kernel images are overwritten by successive Linux OS distros. This is likely when derivatives of the same main distros e.g. Ubuntu all create a directory called /EFI/ubuntu/ in the ESP and drop their kernels & initrd images in there potentially overwriting other distro's files. > One recipe I read about for doing what I wanted to do with UEFI > involved installing a Linux distro (didn't really matter which), then > installing rEFInd. After that, some manual renaming and deleting of > the files in the ESP was required. Then he started installing various > distros. After each distro installation, the author had to re-install > rEFInd, and after many of them he had to manually remove or rename > files in the ESP (or adjust the rEFInd config file). > > And in the end, he ended up with multiple menu entries (for different > installations) that had identical names. The concept of one bootloader/manager ruling them all is broadly the same whether you use rEFInd or GRUB, as are the hoops you have to jump through to accommodate distros' automated/hardcoded installation scripts. When using a distro's installer menu on a legacy BIOS MoBo you can select a partition (PBR) to install GRUB, but GRUB will complain and suggest you could use blocklists but it is unreliable. Last time I received an error like this, I installed grub in a PBR manually with the '--force' option, without using the installer GUI. After that, whenever I updated GRUB it complained again about blocklists, but it worked fine. > It was more complicated and difficult than my current scheme. > > > As for "'s obviously superior bootloader", well > > is using the exact same boot-loader, and when IT installs, how is it > > going to be able to boot if it can't call 's boot > > loader because it's
Re: [gentoo-user] Re: How to set up drive with many Linux distros?
Hello! I guess most (all) of the distro's you are talking about use GRUB (or at least they allow to do it). If that's true, I'm pretty sure you can happily let them overwrite the GRUB in MBR as many times as they want, since it's the same (or just probably minor version differences) bootloader. Just make a copy of /boot/grub/grub.cfg and make sure it's the same on every partition. Or, even better, if that's possible right now, make a common /boot partition and after installing the new distro just merge the (probably new) /boot/grub/grub.cfg with your old one. I really think that *should* work! Take care, ks. Wojciech Kuzyszyn pgp2uRUfi6EGx.pgp Description: Podpis cyfrowy OpenPGP
Re: [gentoo-user] Re: How to set up drive with many Linux distros?
On 22/02/2024 21:45, Grant Edwards wrote: I've been reading up on UEFI, and it doesn't seem to be any better. People complain about distro's stomping on each other's files in the ESP partiton and multiple distro's using the same name in the boot slots stored in NVM. And then the boot choice order changes (though it may not be apparent to the naked eye) when one of the distros decides to update/reinstall its boot stuff. At least if you use UEFI *as* your bootloader, then that won't happen. That assumes you're using UEFI, though! In which case, 's bootloader doesn't get a look-in. As for "'s obviously superior bootloader", well is using the exact same boot-loader, and when IT installs, how is it going to be able to boot if it can't call 's boot loader because it's just trashed it by overwriting it? To me, you seem to be describing the *default* installer setup, that's been there for ever. Last I installed SUSE, iirc I had to specify "advanced bootloader installation", most of who's options I didn't even understand!, but it did do what I told it to (apart from not recognising my weird disk stack!). If you can find, and understand!, that advanced options, I think you'll find you can do what you want. Cheers, Wol
