Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux boot partitions and how to set them up

0pointer.net

Post reply on HN
Print view View original

101–110 of 184 posts

Re: Linux boot partitions and how to set them up

#101

Post by davet91 »

still_grokking wrote: post #82

Almost everything makes sense, imho. I have actually almost such a setup since some time. The only thing I don't understand: Why add something like `systemd-boot` to the setup? It's completely unnecessary! All you need is an UKI on the EFI partition. UEFI has a perfectly sufficient bootloader already. I never found out what additional advantages `systemd-boot` would offer. Maybe someone could clarify?

I set a 10 second timeout for systemd-boot so I don't need to button mash to hit the narrow window of the UEFI bootloader.

Another useful feature would be editing kernel parameters for troubleshooting. Not sure if systemd-boot can do that but GRUB can.

Re: Linux boot partitions and how to set them up

#102

Post by still_grokking »

Kwpolska wrote: post #39

I don’t really see the point in using the ESP for anything serious. Many of the arguments are also super weak, like the one about /boot/efi/ being nested (in how many cases is this actually important to anyone and anything?). The ESP size issue successfully prevents the real world adoption of this, since Linux kernels are 50-100 MB each, which means you could maybe fit one on your average ESP, and good luck convincin…

The "stub" would be in this case a (striped down) Linux kernel and an initrd… (Because that's needed for proper storage support)

Than this "init Linux" would boot the bootloader, which in turn would load another kernel and initrd?

This looks way to complicated.

How does secure boot work in this setup?

It's much simpler to just "glue together" a kernel and initrd, put it on the EFI partition, and boot that UKI directly by the built in EFI boot-manager.

The EFI partition needs in this setup also be only mounted when updating / adding a UKI. Otherwise it never needs to show up in the running system as it's only used by the EFI boot-manager. Preparing a UKI can be done on the root FS (in its local /boot dir).

Re: Linux boot partitions and how to set them up

#103

Post by still_grokking »

E39M5S62 wrote: post #97

I'm a huge fan of UKI - it's part of the underlying 'magic' of ZFSBootMenu ( https://github.com/zbm-dev/zfsbootmenu/ ). We ship a single EFI file that is a full Linux kernel, a semi-custom initramfs and an embedded command line. With that, we can fully support root-on-ZFS because we don't have to re-implement a complex filesystem in a bootloader ... like GRUB. Because we're not trying to re-implement ZFS (or any othe…

UEFI as such is horrible. (Just have a look at the spec; 2.5 k pages of stuff that looks like copy&paste of Windows APIs)

But its boot mechanic, and the added crypto stuff (secure / attested boot) is really nice.

Using UKIs is like boot should have worked since the beginning: You just copy a (signed) boot image onto the (firmware managed) boot partition. Done.

Re: Linux boot partitions and how to set them up

#104

Post by IgorPartola »

i80and wrote: post #96
IgorPartola wrote: post #55

Earlier quoted context omitted.

Why? One more flag to remember whereas redirection works for any program.

To my understanding the shell will truncate the redirect target even if the command fails. Using -o makes failure nondestructive.

Mmm I would argue that using -o may make failures non-destructive at the discretion of the author of the program. I don’t know what the program does. Does it safely and securely create a temporary file, then write the contents to it, then rename the file? This would need to happen on the same file system as the target file for the rename to be atomic and there are few guarantees that my current user has the permissions to write to any file other than this one. It also would certainly fail if the file system is full.

Or the program could start out by deleting my file and starting to line buffer write to it as it executes. Then the failure would be the same as shell redirection. Or it could buffer differently making program failure even more fun.

My point is that I don’t know what the program will do, or even what this particular version will do, without looking at its code.

Shell redirection has predictable semantics. And I can output to a different file, run diff on the two, then rename myself, if this is truly critical. And muscle memory will be faster than looking up the specific option or argument for this specific program.

Re: Linux boot partitions and how to set them up

#106

Post by krzyk »

still_grokking wrote: post #102
Kwpolska wrote: post #39

I don’t really see the point in using the ESP for anything serious. Many of the arguments are also super weak, like the one about /boot/efi/ being nested (in how many cases is this actually important to anyone and anything?). The ESP size issue successfully prevents the real world adoption of this, since Linux kernels are 50-100 MB each, which means you could maybe fit one on your average ESP, and good luck convincin…

The "stub" would be in this case a (striped down) Linux kernel and an initrd… (Because that's needed for proper storage support) Than this "init Linux" would boot the bootloader, which in turn would load another kernel and initrd? This looks way to complicated. How does secure boot work in this setup? It's much simpler to just "glue together" a kernel and initrd, put it on the EFI partition, and boot that UKI directl…

Why is initrd needed for "real storage support"?

I usually have my storage drivers compiled into kernel, not as modules (because why have them as modules if you need them always).

Re: Linux boot partitions and how to set them up

#107

Post by saghm »

dottedmag wrote: post #81
saghm wrote: post #77

Earlier quoted context omitted.

Out of curiosity, how recent is this? I haven't owned my own macbook since the pre-touchbar era (I think the last model I had was the early 2015 Pro), and I had heard that Linux had gotten harder to boot since then due to newer firmware (I remember hearing for a time the newer models were yet to get wifi support on Linux, although I don't know how long that lasted), but at least up until then I was able to use a fair…

There is no UEFI on M1 macs. However boot protocol there is completely different and complicated.

Oh wow, that is a big change! Even though I know Microsoft influenced and pushed the UEFI standard, my first macbook was my first introduction to EFI booting (since I had used legacy BIOS on my PCs up until college), so I've always associated it with Apple hardware.

Re: Linux boot partitions and how to set them up

#108

Post by oynqr »

CameronNemo wrote: post #7

"The Boot partition will also have to carry an emtpy "efi" directory that can be used as the inner mount point, and serves no other purpose." You could substitute Boot for Root in this sentence and flip it around on Poettering.

I prefer to think that Poettering doesn't know mkdir exists. Eagerly awaiting systemd-make-directory-automatic@.path.
Post reply on HN