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

121–130 of 184 posts

Re: Linux boot partitions and how to set them up

#121

Post by michaelmrose »

2OEH8eoCRo0 wrote: post #9
cryptonector wrote: post #3

Using ZFS makes this all a lot simpler.

ZFS is the "crypto solves this" of filesystems. Adding out of tree ZFS to the boot mix sounds hella complicated.

It isn't really. For instance I have 3 Things installed on my EFI partition.

- Windows

- A Linux kernel with zfs zupport sufficient to boot up and load zfsbootmenu

- rEFInd boot menu

The default target is rEFInd which shows this snazzy menu to choose between Windows and Linux

https://i.redd.it/n51sxvv8xfw61.jpg

If you choose Linux the zfsbootmenu kernel boots up imports available pools and lets you boot your current system or a prior snapshot of same. If you have regular snapshots especially automated ones before upgrades its pretty hard to mess it up.

The whole works is one small partition and is fairly easy to understand

Re: Linux boot partitions and how to set them up

#122

Post by qu4z-2 »

still_grokking wrote: post #99
oxplot wrote: post #92

Earlier quoted context omitted.

uh - you just specify the location of your initramfs in the kernel boot params and that's it, no need for all the above

Having kernel and initrd separate makes things more complicated and brittle. Also a secure boot setup is much more difficult this way. I for my part love the UKI. Never had a simpler boot setup!

> a secure boot setup is much more difficult this way.

Is it? Don't you just sign the bootable kernel image that already has the initrd and command-line built in?

Oh, I guess if you're using Microsoft as a CA I can see why that would be tricky.

Re: Linux boot partitions and how to set them up

#123

Post by krylon »

akira2501 wrote: post #98
krylon wrote: post #88

Earlier quoted context omitted.

> LILO Ah, that stirs memories. That 1,024 something boundary the kernel image had to reside in, hence the need for a separate /boot partition. And every time there was a new kernel available, I had to re-run some command to recreate that map file. Things have become a lot more convenient since then.

Pardon the snark, but I'm old. And more complex at the same time. Now I need to do a silly dance to register a GUID with my BIOS so it can find an executable and run it for me (you did remember to add efivars to your kernel, right?), hold a vFAT partition around specifically for this case (what package has mkvfat again?), and worry about how the system maintainers will decide to "improve" what they think is wrong wit…

You are correct, the good old BIOS was not pretty, but it worked and was simple enough one could understand it and its common failure modes. All the complexity we keep piling up is going to come back and bite us eventually.

I was just speaking of LILO vs grub, though. (I heard that grub is not pretty internally, but as a mere user, it has not given me trouble.)

Re: Linux boot partitions and how to set them up

#124

Post by yrro »

csdvrx wrote: post #93
yrro wrote: post #66

Earlier quoted context omitted.

OTOH it's nice to have access to the boot loader via serial console. The system developers judgement is that it's up to the firmware to provide serial console access if needed. Well I'll just get my chequebook out then... Also it would be nice to be able to interact with the boot loader on a modern laptop display without having to get out a magnifying glass. Another problem that is deigned to be the fault of the firm…

>Also it would be nice to be able to interact with the boot loader on a modern laptop display without having to get out a magnifying glass. Another problem that is deigned to be the fault of the firmware. > I think it's a shame that systemd-boot will cause regression here. If you use grub2, yes you need the magnifying glass. Meanwhile, I just press F12 and use the BIOS (which selects a readable font) and pick the UEF…

Can't edit kernel parameters from the firmware's own boot selector though can you. Or see it on an external monitor (at least on the laptop I'm using right now, which normally lives hidden out of sight attached to a dock).

My recollection was that GRUB when in graphical mode looks readable. Maybe I'm misremembering. The systemd-boot menu was definitely far too small and there was bug that was basically closed with "it's the firmware's job to give us a usable text output protocol".

Effectively, as shitty as the legacy PC-BIOS boot protocol was, it did at least allow open source software to jump in early and work around the gaping deficiencies in the vendor's firmware. UEFI has effectively replaced all that with a proprietary boot process. The vendor is now in complete control; want a usable text console, or to access the firmware via an external monitor? Vendor doesn't give a shit. Want to access the boot loader via the serial console? Oh you must be an enterprise, let me direct you to our sales staff who won't give you the time of day unless you've got £thousands to drop into their pocket.

Don't get me wrong, I'd love to replace GRUB with systemd-boot, but these are very real impediments to me ever doing so.

Re: Linux boot partitions and how to set them up

#125

Post by mrktf »

krzyk wrote: post #106
still_grokking wrote: post #102

Earlier quoted context omitted.

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).

Answering question for ' Why is initrd needed for "real storage support"?' because there always be somebody:

* need to have sshd at initrd stage to enter encryption keys (remote boot)

* need to have recovery tool on hands (going even further: imagine having working graphical browser when storage fails)

* have same crazy storage setup - root on ceph/nfs volume with non trial configuration and etc...

* in case of electricity fault at home - it only system which have exposed connection to internet

My suggestion for booting would be following:

1) having UEFI bootloader which boot some minimal kernel (lets same sort LTS for stability’s sake ) on /boot partition

2) have ability to unlock and read from root filesystem (same as above, rootfs in nfs/ceph/encrypted ir whatever)

3) then scan kernels from /lib/modules/{version}/bzImage (i know there are modules here, but having one additional file would not hurt too much)

4a) kexec kernel with necessary parameters to start system [in this step we do not enter passwords, encryption keys twice!]

4b) or boot without kexec in recovery mode with some GUI (I want ability to have browser in recovery mode)

Re: Linux boot partitions and how to set them up

#127

Post by boomboomsubban »

usr1106 wrote: post #113
boomboomsubban wrote: post #69

So is this the first work Microsoft set Pottering to do? Kinda supports my personal conspiracy theory that Microsoft's aiming to make secure boot only possible with systemd-boot. Or Microsoft is trying to make dual booting easier without using the simplest solution of making a larger ESP the default.

So what's your "conspiracy" here? What is secure boot-only? Secure boot with systemd-boot has been possible for years. Just that the typical setup has not been very secure because the initrd and the kernel command line where already unsigned. I see no problems with secure boot from a freedom perspective as long as the owner of the computer can install their own trusted public keys. There might be industry players tha…

I think they will better integrate systemd-boot with secure boot and eventually revoke access to the current shim signer, in essence forcing major distros to adopt systemd-boot.

I can't exactly figure out how they'd use that level of control over the Linux boot, but I'm not a huge fan of them having it.

Re: Linux boot partitions and how to set them up

#128

Post by schipplock »

candiddevmike wrote: post #6

How to make one boot partition to rule them all (debian, secure boot disabled for UEFI due to weird bug with how files are laid out with removable flag): parted -s "${diskpath}" mklabel gpt parted -s "${diskpath}" mkpart primary 1MiB 2MiB parted -s "${diskpath}" set 1 bios_grub on parted -s "${diskpath}" mkpart primary 2Mib 202MiB parted -s "${diskpath}" set 2 esp on sleep 1 mkfs.fat -F 32 -n "boot" "${diskpath}2" mo…

  parted -s "${diskpath}" mklabel gpt
  parted -s "${diskpath}" mkpart primary 1MiB 2MiB
Isn't "primary" wrong here? It assumes your `mklabel` command used label-type of msdos or dvh. You are using gpt though. In case of gpt "primary" is a label, not a partition type.

You can use a descriptive string here instead of "primary" (e.g. "boot partition", or "esp partition").

https://manpages.debian.org/unstable/parted/parted.8.en.html...

Re: Linux boot partitions and how to set them up

#129

Post by ahesford »

Vogtinator wrote: post #119
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…

You can do the same just without UKI by using the same parts (kernel, initramfs + cmdline) as separate files. There's the kernel's EFI stub and other minimal bootloaders (like systemd-boot) if you need a more complete menu.

ZFSBootMenu can also render itself as an ordinary initramfs image and maintain a separate copy of the kernel it's built against. These can be launched with some intermediate bootloader (e.g., rEFInd, syslinux or systemd-boot) or the kernel's built-in EFI stub can be run from the firmware. However, some Dell firmware seems incapable of properly passing command-line arguments to UEFI executables; a UKI that encodes its command line is needed on affected systems.

Re: Linux boot partitions and how to set them up

#130

Post by iam-TJ »

hyperupcall wrote: post #65

This is excellent! Over the years, I've been pleased to see that more and more distributions are writing their disk images and the like to the ESP. (Previously, dd'd USB images for distro installing _required_ the creation of a /boot partition) The logical next step would be to standardize everything through systemd, and ensure all boot images are autodiscoverable and automatically bootable. It's been somewhat frustr…

One downside to storing these images on the (FAT) EFI System Partition is it is not possible to make it part of a software RAID device, so if the device the ESP is on dies suddenly, the boot fails AND it can take quite some time and effort to recover even if you're technically familiar with the boot process since there are no standardised procedures for duplicating the ESP or its content.

A second issue is that since FAT doesn't have permissions any user ID on the system can potentially mount, read, and possibly write to the ESP.

A separate (possibly encrypted) /boot/ file-system can be hosted on a RAID device or even loaded over the network.

With a 'regular' boot process (UEFI > ESP boot-loader core > LUKS unlock > /boot/ boot-loader 2nd stage > /boot/ kernel+initrd > root-fs) the only thing lost is the boot-loader core, which can quickly be switched for a USB boot, set options appropriately to find and use /boot/, and for the boot process to use alternate RAID device(s) and continue with a degraded boot.

On UEFI most distros now do not use os-prober to populate GRUB's own menu with other bootable OSes (GRUB_DISABLE_OS_PROBER=yes) since it expects those OSes to have added themselves to the UEFI boot menu.

As for replacing the default boot entry, this is caused by efibootmgr not GRUB. GRUB calls efibootmgr with "--create|-c" which adds a new BOOTNUM and puts it at the head of the list.

GRUB could be taught a new option that then does several efibootmgr operations: parsing text output of "efibootmgr" to get current boot order, --delete-bootorder then --bootorder A,B,C,OS to ensure OS is added last.

That is obviously fragile so best approach would be to teach efibootmgr a new option --create-append|-C that adds the new entry to the end of BootOrder and then simply teach GRUB a new variable GRUB_UEFI_BOOTORDER_FIRST=yes|no to use efibootmgr --create-append.

Post reply on HN