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

91–100 of 184 posts

Re: Linux boot partitions and how to set them up

#91

Post by csdvrx »

CameronNemo wrote: post #5
dottedmag wrote: post #2

Great to see Lennart back working on what systemd does best: streamlining and cleaning existing grubby (pun intended) parts of Linux. /boot (and ESP) management always feels hacky at best.

Can you explain what about the boot partition status quo seems hacky, and how this approach "cleans" it?

If you create an efi payload, you remove the need for the /boot partition and for grub2, killing 2 birds with 1 stone.

The payload can be managed by your UEFI bios and efibootmgr, allowing more advanced thigs like signing your payloads with your own keys for a true secureboot instead of the hackish "MOK" that's just using unprotected UEFI variables

Re: Linux boot partitions and how to set them up

#92

Post by oxplot »

csdvrx wrote: post #90
oxplot wrote: post #84

My humble boot installer, no explicit bootloader, straight to the kernel: #!/bin/bash set -ueo pipefail # Remount EFI partition read/write and restore to readonly when done trap 'mount /sys/firmware/efi/efivars/ -o ro,remount &>/dev/null || true' EXIT mount /sys/firmware/efi/efivars/ -o rw,remount &>/dev/null || true # Remove all existing Arch Linux entries efibootmgr | grep 'Arch Linux' | grep -Po 'Boot\K\d+' | whil…

If you want to add an initrd, create an EFI payload: https://wiki.archlinux.org/title/Unified_kernel_image#Manual... $ stub_line=$(objdump -h "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" | tail -2 | head -1) $ stub_size=0x$(echo "$stub_line" | awk '{print $3}') $ stub_offs=0x$(echo "$stub_line" | awk '{print $4}') $ osrel_offs=$((stub_size + stub_offs)) $ cmdline_offs=$((osrel_offs + $(stat -c%s "/usr/lib/os-release…

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

Re: Linux boot partitions and how to set them up

#93

Post by csdvrx »

yrro wrote: post #66
rektide wrote: post #36

AFAIK Debian still doesnt have any integration available for handling thee integration of systemd-boot & kernel packages: there's nothing to maintain the loader/entries files that systemd-boot expects! It's really a shame because systemd-boot is 10x simpler and 100x more plesant to work with than grub & it's multiple overlapping but different obtuse config handling shell scripts. Bootctl is excellent & understandable…

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 UEFI entry I want.

Re: Linux boot partitions and how to set them up

#94

Post by csdvrx »

oxplot wrote: post #92
csdvrx wrote: post #90

Earlier quoted context omitted.

If you want to add an initrd, create an EFI payload: https://wiki.archlinux.org/title/Unified_kernel_image#Manual... $ stub_line=$(objdump -h "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" | tail -2 | head -1) $ stub_size=0x$(echo "$stub_line" | awk '{print $3}') $ stub_offs=0x$(echo "$stub_line" | awk '{print $4}') $ osrel_offs=$((stub_size + stub_offs)) $ cmdline_offs=$((osrel_offs + $(stat -c%s "/usr/lib/os-release…

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

You hadn't specified it at first, so I thought it might be helpful to provide a more complete example with different parts (like the initrd) and offsets, with a gummiboot stub

Re: Linux boot partitions and how to set them up

#96

Post by i80and »

IgorPartola wrote: post #55
yjftsjthsd-h wrote: post #23

Earlier quoted context omitted.

> grub-mkconfig > "/boot/grub/grub.cfg" Shell redirection is fine, but you could just use `grub-mkconfig -o` to set the output file.

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.

Re: Linux boot partitions and how to set them up

#97

Post by E39M5S62 »

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 other modern/complex filesystem), we can ALWAYS be current. If a new version of ZFS is released, all we have to do is build a new EFI executable with that baked in to the embedded initramfs.

There are serious concerns with SecureBoot and being able to unlock your own bootloader - but UEFI itself is a nice universal base to target in 2022.

Re: Linux boot partitions and how to set them up

#98

Post by akira2501 »

krylon wrote: post #88
cesarb wrote: post #26

> For example, it’s probably worth mentioning that some distributions decided to put kernels onto the root file system of the OS itself. For this setup to work the boot loader itself [sic!] must implement a non-trivial part of the storage stack. IIRC, older bootloaders like LILO used a simpler approach: after each kernel update, a userspace program asked the kernel for the list of sectors which contained the kernel f…

> 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 with this hierarchy.

Previously.. the BIOS would find a particular sector on what I told it was the "boot drive" and run it without too much concern over what, if anything, happened next.

And for this change, do I get a BIOS that's more helpful when there's a frustrating boot misconfiguration? A log to show me what precisely went wrong? The ability to save debug information in any relevant format? I could, but zero vendors in the consumer space are going to do that.

Now.. essentially, I just don't have to specify a "boot drive" anymore. Other than that, if you're bringing a system up from scratch, EFI has just as much "janky magic" in it that the old boot sector method did.

Re: Linux boot partitions and how to set them up

#99

Post by still_grokking »

oxplot wrote: post #92
csdvrx wrote: post #90

Earlier quoted context omitted.

If you want to add an initrd, create an EFI payload: https://wiki.archlinux.org/title/Unified_kernel_image#Manual... $ stub_line=$(objdump -h "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" | tail -2 | head -1) $ stub_size=0x$(echo "$stub_line" | awk '{print $3}') $ stub_offs=0x$(echo "$stub_line" | awk '{print $4}') $ osrel_offs=$((stub_size + stub_offs)) $ cmdline_offs=$((osrel_offs + $(stat -c%s "/usr/lib/os-release…

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!

Post reply on HN