Preparing for a merged /usr in Debian
Preparing for a merged /usr in Debian
Posted Jan 18, 2016 0:13 UTC (Mon) by anselm (subscriber, #2796)In reply to: Preparing for a merged /usr in Debian by walex
Parent article: Preparing for a merged /usr in Debian
Can you have GRUB loading its kernel, configuration file and modules from a /boot being a BTRFS filesystem on an encrypted LVM volume on top of an MD RAID1 spanning 2 DRBD volumes?
No, but in your proposed non-GRUB, non-initramfs setup you can't use LILO to get your initial kernel from there, either, so this is an obvious red herring. Try harder.
What is the case for the additional complexity and fragility for having an "initramfs" that is a statically built and customized snapshot of a large subset of / and then "pivot" to a full / or in the latter-day proposal to a full /usr?
An initramfs is reasonably easy to construct and keep current and, if you're providing a Linux distribution, makes it unnecessary to use a kernel that has all sorts of drivers compiled statically to ensure wide hardware coverage, most of which drivers are unnecessary for any particular system (because the hardware isn't there) but can't be removed other than by compiling a new, customised kernel. (Remember that that was a situation we used to have to deal with in the early years of Linux, and now that we no longer need to, pretty much everyone is a lot happier.) This sucks especially if you're running an enterprise-class Linux distribution like RHEL or SLES where tampering with the kernel will mean your system no longer qualifies for vendor support in case of problems.
In addition, an initramfs makes it straightforward to do various things – such as network configuration in case your actual root file system is on a remote iSCSI volume, or obtaining a pass phrase for an encrypted root file system – that the kernel isn't really set up to do. How to do this in user space in an initramfs is quite well understood, and putting the required functionality into the kernel would only add unnecessary complexity and probably bugs.
Posted Jan 18, 2016 23:02 UTC (Mon)
by walex (guest, #69836)
[Link] (7 responses)
« No, but in your proposed non-GRUB, non-initramfs setup you can't use LILO to get your initial kernel from there, either, so this is an obvious red herring. Try harder. That objection is comically stupid, because I have proposed a setup where /usr gets mounted and the second stage kernel (if needed, and it will be rarely needed) gets booted by a full (if minimal) GNU/Linux system hosted inside a first stage / root filesystem, just like it has been done for decades by people who actually understand booting sequences, and that LILO in that setup is equivalent not to the GRUB kernel but to the GRUB bootloader that loads the GRUB kernel from the GRUB root filesystem which is /boot. I think that this is the third time that I have explained this is detail for those who ignore how booting sequences work.
«Preparing for a merged /usr in Debian
Can you have GRUB loading its kernel, configuration file and modules from a /boot being a BTRFS filesystem on an encrypted LVM volume on top of an MD RAID1 spanning 2 DRBD volumes?
»An initramfs is reasonably easy to construct and keep current and, if you're providing a Linux distribution, makes it unnecessary to use a kernel that has all sorts of drivers compiled statically to ensure wide hardware coverage
»sorts of drivers compiled statically
except those needed to mount the first-stage / filesystem from a local storage area, exactly as GRUB does it for boot, but unnecessarily. Having mounted / the stripped down Linux kernel can then load whichever modules and run whichever scripts may be needed to mount the /usr filesystem, or to load a new dynamically selected kernel from any storage medium whatever, with kexec and reboot into it.
«an initramfs makes it straightforward to do various things – such as network configuration in case your actual root file system is on a remote iSCSI volume, or obtaining a pass phrase for an encrypted root file system – that the kernel isn't really set up to do. How to do this in user space in an initramfs is quite well understood
»
People who understand how booting sequences work understand that doing all that with a stripped down UNIX/Linux kernel and a mounted / filesystem is much easier and less fragile than packing up every time a new static "initramfs", and prompting for passwords can be done by a trivial shell script in the mounted / filesystem, and does not need to be done by the UNIX/Linux kernel, and that there is no need to snapshot the / filesystem into an "initramfs" image unless there is a totally storage-less boot situation.
Posted Jan 18, 2016 23:17 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Please, desist from insulting people who actually do the work to make booting reliable and stable.
Posted Jan 18, 2016 23:37 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (3 responses)
Right, so please explain how you load your kernel from your first-stage “/” if that is encrypted. Something must find and decrypt the kernel before it can run. (GRUB can do it but you don't want to use GRUB.)
Nobody disagrees that this is possible in principle. We all did it that way on Linux 1.x, 20 years ago. The main reasons we prefer not to do it that way anymore are that (a) using an initramfs is much less hassle than compiling a new custom kernel for every single machine that we want to run Linux on, and (b) an initramfs lets us do various things in a reasonably straightforward manner that in the traditional setup are very difficult or impossible to achieve at all. In any case, it turns out that the initramfs approach, in actual practice, is a lot less brittle than you seem to assume.
OK, so “/” is encrypted (it would after all be a very bad idea to leave it unencrypted, with all the important stuff that you want to put on it). Now how do you get at that trivial shell script in the mounted “/” file system when the kernel needs the pass phrase to mount “/” in the first place?
Posted Jan 19, 2016 8:42 UTC (Tue)
by walex (guest, #69836)
[Link] (2 responses)
In exactly the same way that currently GRUB gets its modules and scripts and the new kernel in the content of an encrypted "/boot" filesystem, which also contains «important stuff that you want to put on it». :-)
As I wrote several times, disputing that there must be a statically installed bootloader and kernel mounting a simple filesystem at the start of the boot sequence from which to load another kernel, drivers, configuration files and scripts to mount anything else, is just pointless and a really stupid debating trick. Because that's how boot sequences work by necessity (the second stage is necessary because of the flexibility requirements).
The only things that can be disputed is whether mounting in sequence '/boot', "initramfs", '/', '/usr' are all necessary, and if not whether one should drop from that sequence '/boot' and "initramfs" or "/".
Posted Jan 19, 2016 8:57 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link]
The grub configuration and contents of /boot aren't secret and so don't need to be encrypted, so you're proposing copying much of the contents of / into /boot?
Posted Jan 19, 2016 10:05 UTC (Tue)
by anselm (subscriber, #2796)
[Link]
The issue here isn't necessity as much as convenience. As I said earlier, the Linux community used to do initramfs-free boots based on LILO for quite some time in the 1990s. We've come off that idea not because it doesn't work (it does, at least for simple scenarios), but because on the whole it is inconvenient and restrictive.
The initramfs-based approach, even though it looks more complicated at first sight, is vastly more powerful and convenient, and the added complexity is a price that most Linux distributions seem more than happy to pay. After all, Linux distribution makers are not in the business of making their life more complicated just for the sake of making it more complicated; they prefer approaches that work in a wide variety of cases and can be maintained.
If you think you can come up with a method of booting Linux systems that is better than what we have now, feel free to implement it and show it off to distribution makers. If it really is superior to the current approach, they'll be more than happy to take it on. That method worked for systemd in the basic-plumbing arena, after all …
Posted Jan 19, 2016 1:52 UTC (Tue)
by raven667 (subscriber, #5198)
[Link] (1 responses)
We can disagree without being insulting or dismissive here, some of the people here actually build distributions and know more about booting than either of us do combined.
> I think that this is the third time that I have explained this is detail for those who ignore how booting sequences work.
I think we are going to disagree about how clear your ideas have been represented by your writing, the evidence is in how few people seem to have understood your intent. Let me see if I understand what you are proposing as another valid way to boot a system.
If I understand correctly you are thinking that we should go back to a simple LILO or uEFI style boot loader that is capable of loading the kernel and passing parameters from the firmware but to disaggregate what is currently in the initramfs into /boot, presuming that the kernel will have built-in drivers equivalent to what the firmware provides to be able to access the block device that /boot lives on, or that the kernel will use the firmware APIs to read the block device. Once you can reliably access the /boot block device you can run your minimal userspace to do hardware setup and pivot into the "real" system.
> is to have a Linux kernel without needing any sorts of drivers compiled statically except those needed to mount the first-stage / filesystem from a local storage area, exactly as GRUB does it for boot,
I may be wrong I don't think GRUB has block device drivers to access /boot, it relies on the firmware built-in services to access the block device, although it does have its own minimal filesystem driver modules (BIOS or uEFI or whatever), which are loaded LILO-style using static block lists, which has the same problems as LILO but GRUB modules are updated more infrequently than the kernel so is less of a problem in practice.
> plus optional kexec
As mjg59 has said elsewhere, and he has more operational experience with this feature than I do, it is a neat feature and great when it works, it's not something that is so reliable that you'd want to depend on it for the common case of everyday booting. In any event, if you are going to boot a Linux kernel, it might as well be the "real" one.
Posted Jan 19, 2016 7:55 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link]
It does, but they're not typically used in BIOS or UEFI environments. I point this out merely for precise technical accuracy rather than it altering your point in any way!
Preparing for a merged /usr in Debian
I.e. not you?
Preparing for a merged /usr in Debian
That objection is comically stupid, because I have proposed a setup where /usr gets mounted and the second stage kernel (if needed, and it will be rarely needed) gets booted by a full (if minimal) GNU/Linux system hosted inside a first stage / root filesystem
The proposed setup, which is the historical UNIX setup plus optional kexec, is to have a Linux kernel without needing any sorts of drivers compiled statically except those needed to mount the first-stage / filesystem from a local storage area
and prompting for passwords can be done by a trivial shell script in the mounted / filesystem, and does not need to be done by the UNIX/Linux kernel
Preparing for a merged /usr in Debian
Preparing for a merged /usr in Debian
Preparing for a merged /usr in Debian
The only things that can be disputed is whether mounting in sequence '/boot', "initramfs", '/', '/usr' are all necessary, and if not whether one should drop from that sequence '/boot' and "initramfs" or "/".
Preparing for a merged /usr in Debian
Preparing for a merged /usr in Debian