LWN: Comments on "LPC: Booting and systemd"

DJB

tialaramex — Fri, 23 Sep 2011 15:03:37 +0000

It occurred to me today that we should at least thank Bernstein for Bernstein vs United States. Taking the US government to court is the sort of task which more or less requires one to be stubborn beyond reason, and there can be no doubt that, at least at first, this case was a factor in the relaxation of US laws controlling cryptography.

But I still don't want to run his software.

LPC: Booting and systemd

Wol — Thu, 22 Sep 2011 22:29:06 +0000

Does Grub2 do USB?

Many mobos do not do proper USB->PS2 emulation (some don't do it at all) so if all you have is a usb keyboard, you're stuffed. You can't tell grub which option you want so you get the choice of default, default or default. Tough luck if your upgrade broke but you made that the default in order to test it ...

For example, my mobo is broken some of the time - kernel upgrades are a pain because I never know whether my keyboard is going to work with grub or not :-(

Cheers,
Wol

LPC: Booting and systemd

mathstuf — Tue, 20 Sep 2011 16:06:09 +0000

When I had my 4GB SSD netbook, I did something like a 70MB ext2 /boot, 2GB /, 512MB of swap, and the rest for /home. If everything were /, I would have to format anyways for an upgrade (not enough space for the RPMs to upgrade with[1]). I also remember doing lvresize and other fun things to go from a 2GB /home to a 2GB / instead. Haven't used LVM since.

[1]I actually did do a yum upgrade (from F10 to F11 IIRC) on the machine. The RPMs fit, but not with the upgrade going. I ended up having to SIGSTOP yum, delete cached RPMs that had finished installing for disk space, and the SIGCONT yum again. Not something I plan on doing again. Especially during class.

LPC: Booting and systemd

Cato — Tue, 20 Sep 2011 09:56:34 +0000

If your only disk is a 4GB SSD on a notebook, don't use a separate /boot - just use ext3. You probably won't need LVM either.

LPC: Booting and systemd

Aissen — Mon, 19 Sep 2011 21:33:03 +0000

Indeed, it has a lot of manpages. But since it's trying to take over a lot of software, I have the feeling it might not be enough.
Example: https://bugzilla.redhat.com/show_bug.cgi?id=677962#c4

LPC: Booting and systemd

raven667 — Mon, 19 Sep 2011 18:26:02 +0000

I'm not quite sure it's that bad, i've never had a server failure where LVM was a factor but I've had many times where LVM has saved my bacon with the ability to live upsize filesystems. I could see that on a desktop without battery backed write cache that LVM is probably not useful and trying to shrink live filesystems is fraught with peril but in the server use case it is very useful.

LPC: Booting and systemd

epa — Mon, 19 Sep 2011 09:33:24 +0000

The difficulty is in having a separate /boot at all. You must allocate a fixed amount of space which is either too little or too much. With a 500 gigabyte disk it doesn't matter but on a netbook with a four gigabyte SSD it is painful to lose 10% of it to /boot.

Earlier Fedora releases gave about a hundred megs to /boot but then cannot be upgraded to the latest Fedora version, since the upgrade process needs to put a disk image in there too. (There is a way to download the disk image over the network but for me it always hangs.)

LPC: Booting and systemd

raven667 — Mon, 19 Sep 2011 03:44:15 +0000

As long as it has the information and _can_ load a kernel with options and _can_ present a UI I don't think the actual UI needs to be standard. I would expect it to be branded by the hardware vendor for example. As long as there is a standard place to put kernel images and a standard way to add/remove labeled boot entries and if you can manually boot custom options using the EFI shell then I think that would solve the problem. I don't think the actual UI needs to be standardized beyond that.

LPC: Booting and systemd

mjg59 — Sun, 18 Sep 2011 21:39:48 +0000

There's no problem in configuring EFI to boot a kernel. The problem is in the UI that the firmware will expose to let you choose which kernel to boot or which boot arguments to pass. That's entirely non-standard, requires different keypresses on different hardware, looks different depending on a variety of circumstances and may not actually exist in any UI.

LPC: Booting and systemd

raven667 — Sun, 18 Sep 2011 20:36:17 +0000

At the risk of backseat designing, it seems that all that is really necessary is the ability to provide a list of labels and not specify how they are displayed. One would think that by default it would just load whatever is set to be the default with minimal prompting unless a key is hit. This is similar to how GRUB is usually set up and how I think Mac's work right now.

While it may be do-able to load modules for common filesystem types, as GRUB already does, so you can load kernels off them it seems more productive to be able to EFI boot the kernel directly and have the current and previous kernel images live on the EFI system partition. Basically make the EFI system partition replace the /boot directory.

LPC: Booting and systemd

mjg59 — Sun, 18 Sep 2011 20:15:05 +0000

The spec isn't intended to provide UI, since that's something that's intended to integrate with the platform vendor's design. You could imagine some vendors being happy with a text-based menu with various boot options, but it doesn't seem plausible that, say, Sony would go for that over some sort of graphical UI.

In any case, EFI doesn't require that the firmware be able to read arbitrary filesystems. If you want to boot a kernel off LVM or btrfs or even ext2, you need a bootloader sitting in the EFI system partition.

LPC: Booting and systemd

raven667 — Sun, 18 Sep 2011 20:11:50 +0000

That's something that goes back to my original point of encouraging more participation in vendor committees and whatnot by not just concerned vendors who use and fund linux but also independent groups like the Linux Foundation. EFI already seems pretty capable so getting the rest of the small number of additional features in the spec that would be needed to fully replace something like GRUB might be do-able if you can talk to the right people.

LPC: Booting and systemd

raven667 — Sun, 18 Sep 2011 20:06:05 +0000

That seems like a perfectly reasonable trade-off. As a practical matter, how often does the kernel interface have incompatible changes such that forces the need for a new bootloader. EFI and GRUB can already just load an arbitrary boot sector if you want a layered approach but from what little experience I have with EFI (just started working with it last week) it seems nearly capable enough.

Interestingly enough, elsewhere in LWN was a report of progress in making a linux kernel image that is directly bootable from EFI.

LPC: Booting and systemd

mjg59 — Sun, 18 Sep 2011 18:40:26 +0000

Right now the kernel isn't an EFI executable, so an additional bootloader is required in order to relocate it, set up the boot parameters structure, load an initrd if necessary and then jump to the kernel's entry point. There's ongoing work to make it possible to execute the kernel directly from EFI, with the command line arguments being provided directly. That's fine for the trivial case, but we'll still require a bootloader of some description if only to provide the user with their boot choices. While the EFI spec does support providing multiple boot choices that the user can select between, there's no specification for what the UI should look like. That's less than ideal.

LPC: Booting and systemd

giraffedata — Sun, 18 Sep 2011 18:26:02 +0000

But there's a reason for all the layers involved in bringing up a system. Each one has a different tradeoff of simplicity and stability versus flexibility, each one has a separate dependence on other components of the system, and so on.

One could squeeze the GRUB and EFI layers into one, but look what you'd lose: Today, if I want to start determining kernel parameters in a new way, I can just update GRUB on my boot disk. If I mess it up so the system won't boot, that's OK - I can just tell EFI to boot from my backup boot disk (maybe a rescue CD) and fix it. But if all that parameter stuff was in EFI, I would have to flash a new EFI onto the motherboard, which isn't as easy. And if I screw it up, I might have a brick.

We can argue forever on how many layers are optimal, and what should go in each one (I'm hearing more and more opinions that GRUB2 has features that would better reside at the Linux kernel layer), but it's clear that having lots of bootstrap layers can be useful.

LPC: Booting and systemd

raven667 — Sun, 18 Sep 2011 17:14:00 +0000

I suppose EFI systems don't have a way to pass parameters to the kernel, otherwise on newer systems there would seem to be less need for a separate bootloader at all. Presuming that EFI can't pass parameters (or an initrd) that seems like a missed opportunity for the Linux community to get native booting into the standard. Sometimes it seems like linux kernel developers don't participate in the right vendor clubs to influence the design of hardware and standards and end up needing to conform after the fact.

I'm just kind of talking out of my rear end here so maybe it's not like that at all but that's the sense that I get sometimes.

I wonder if grub EFI is an EFI loadable module or a more traditional x86 bootloader, something like that could have just been specified in the standard such that EFI could natively boot Win*, Linux, *BSD, etc. on common filesystems without any further installs or intermediaries. That would probably require compromise on the design which is always hard to get.

LPC: Booting and systemd

nix — Sun, 18 Sep 2011 13:27:49 +0000

Did I need sarcasm tags? I was trying to say 'any claims that systemd has no documentation must cater for the fact that sysvinit has dramatically less'.

LPC: Booting and systemd

giraffedata — Sat, 17 Sep 2011 00:20:46 +0000

Maybe we should just go back to LILO. Why boot an intermediate kernel with some added complexity if you can just boot the real one, instead.

Because you'd like to have a choice at boot time of kernels and kernel parameters. Hence the intermediate program, be it LILO, GRUB, or Linux.

If you really don't want that boot-time choice, then you should step back beyond LILO to the system that simply loads the first N blocks from the disk and branches to it. That can be your Linux boot image, with built-in parameters.

Even LILO is dependent on Linux filesystem design more than is desirable. It assumes a file is simply the content of a sequence of blocks, and that that sequence is static. A modern filesystem should not be bound to that.

LPC: Booting and systemd

jwakely — Fri, 16 Sep 2011 18:25:51 +0000

I always disable LVM on my own systems, I don't feel as though I'm missing out.

LPC: Booting and systemd

jrn — Fri, 16 Sep 2011 17:34:20 +0000

> GRUB2 requires running an installer after any change, such as installing a newly built kernel. Forget that step and kaboom!

Forget that step and you have to type the name of the kernel by hand, you mean, right?

LPC: Booting and systemd

jmorris42 — Fri, 16 Sep 2011 17:19:51 +0000

> If you've never seen a system with a blank screen except for
> "LI" then you've not been using Linux very long!

Well what is old is now new again. GRUB2 requires running an installer after any change, such as installing a newly built kernel. Forget that step and kaboom! Well you get the old config with no mention of the newly installed kernel if you weren't so unwise as to get rid of the current running kernel before rebooting but we still went backward with GRUB2.

LPC: Booting and systemd

mezcalero — Fri, 16 Sep 2011 17:10:32 +0000

systemd is not all PID 1. In fact we are very modular and ship 40 separate binaries or so.

LPC: Booting and systemd

jeremiah — Fri, 16 Sep 2011 16:39:29 +0000

As long as there is enough documentation to fix/diagnose problems when you're somewhere without an internet connection.

LPC: Booting and systemd

rahulsundaram — Fri, 16 Sep 2011 15:26:40 +0000

Nonsense. Blog posts *are* documentation and man pages are reference documentation. systemd has both.

LPC: Booting and systemd

Cato — Fri, 16 Sep 2011 14:44:01 +0000

LVM is not an unalloyed win, to say the least, and requires some skill to set up correctly. See http://serverfault.com/questions/279571/lvm-dangers-and-c... for some issues.

LPC: Booting and systemd

Cato — Fri, 16 Sep 2011 14:38:26 +0000

GRUB2 does support LVM, but I prefer to always use a non-LVM /boot partition. In fact, if everyone used boring filesystems such as ext3 for /boot, there would be no need for exotic filesystems in GRUB at all. Since /boot is small, slow changing and rarely needs resizing, I can't see the point of anything beyond ext3.

LPC: Booting and systemd

bronson — Fri, 16 Sep 2011 14:35:36 +0000

Completely the opposite! After getting burned bad by that corruption bug a few years ago, and trying to untangle spaghetti PVs scattered needlessly by lazy sysadmins, I avoid LVM when I can. For most Linux installs it's needless complexity and a bad temptation.

Yes, I'll still use it for a server that needs it. But with fast SSDs and contiguous 3TB for $120, I haven't needed it for 4 or 5 years.

LPC: Booting and systemd

jond — Fri, 16 Sep 2011 13:19:53 +0000

This sub-thread amazes me somewhat, because I thought everyone long ago moved to use LVM in nearly all situations.

LPC: Booting and systemd

jond — Fri, 16 Sep 2011 13:15:19 +0000

F15 puts X on 1.

LPC: Booting and systemd

AndreE — Fri, 16 Sep 2011 03:39:08 +0000

I like this approach.

Documentation comprehensiveness being directly related to software bloat would give me a compelling argument to give to my boss when asks me to provide thorough documentation for my code

LPC: Booting and systemd

bronson — Thu, 15 Sep 2011 22:24:09 +0000

I highly doubt that. systemd is big but it's all in one process. No single human on this planet understands all of modern sysvinit.

LPC: Booting and systemd

JEFFREY — Thu, 15 Sep 2011 18:17:31 +0000

IMHO Blog posts don't count as documentation. They are far too transient. Documentation should not require the use of web.archive.org.

AFAIK it's not documentation, if it's not distributed with the source.

Accurate man pages, and anything that `make install` (or whatever packaging system you use) puts in /usr{,/local}/share/doc *is* documentation.

LPC: Booting and systemd

dlang — Thu, 15 Sep 2011 18:06:44 +0000

I much prefer fixing and troubleshooting lilo boot problems compared to grub boot problems

yes, it's easier to trigger lilo problems, but when grub doesn't just 'do the right thing', figuring out how to fix it seems to be much harder.

LPC: Booting and systemd

rfunk — Thu, 15 Sep 2011 15:12:04 +0000

GRUB does have a limited command line allowing some level of file browsing, as I recall.

LPC: Booting and systemd

rfunk — Thu, 15 Sep 2011 15:09:43 +0000

In my experience X is normally on 7 or 8. But then I've been using Ubuntu (and before that Debian) for quite a while now, so I'm not sure how the others do it these days.

LPC: Booting and systemd

faramir — Thu, 15 Sep 2011 15:06:16 +0000

There is also kexec-loader

http://www.solemnwarning.net/kexec-loader/

which will fit on a floppy and can more or less read GRUB1 config files.

LPC: Booting and systemd

epa — Thu, 15 Sep 2011 15:02:25 +0000

Even GRUB isn't as friendly as it could be; I have often longed for a simple file browser with 'cd' and 'ls' commands to find the kernel and initrd to boot. Part of what makes it awkward is LVM, which isn't very discoverable (there's no command to 'list available LVM devices and ask me which ones to mount', least of all from the GRUB command line), so it will be great when LVM goes away.

A simple command interpreter built into the kernel would also be a great help, e.g. when it can't find the root filesystem or /sbin/init.

LPC: Booting and systemd

bcl — Thu, 15 Sep 2011 14:24:04 +0000

As of F16 new installs use GPT. The future is now!

UEFI boots from a vfat partition so yes, there is enough space (we already support EFI) but it isn't stored in the MBR.

LPC: Booting and systemd

wfp5p — Thu, 15 Sep 2011 13:54:35 +0000

I expected systemd to be tremendous PITA at first. However, it's not been a hassle for me at all. At least, not as it's implemented in Fedora 15. I don't have 100s of machines running it, but I have far more than 3.

LPC: Booting and systemd

dan_a — Thu, 15 Sep 2011 13:20:09 +0000

> Maybe we should just go back to LILO. Why boot an intermediate kernel with some added complexity if you can just boot the real one, instead.

I quite enjoy doing kernel upgrades with GRUB. If you've never seen a system with a blank screen except for "LI" then you've not been using Linux very long!