19 ms·

Linux boot partitions and how to set them up

259 points by throw7 4y ago

dottedmag 4y ago
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.
- CameronNemo 4y ago
  Can you explain what about the boot partition status quo seems hacky, and how this approach "cleans" it?
  - admax88qqq 4y ago
    Issues with the current setup are pretty well laid out in the article.
    - CameronNemo 4y ago
      The article does not characterize the status quo as hacky, and furthermore does not acknowledge the existence of mainstream setups that do not share the pitfalls of the "typical setup". I.E. the article kind of creates a strawman.
      - fuzzfactor 4y ago
        In the article the Linux mount point can be as described regardless of where the Linux boot files & kernels are physically stored in the various partitions & folders. We see this variation in the wild observing the different physical locations among the different distributions. Or you could put key files in places as yet undescribable. That's a worthwhile advantage for Linux, your choices are less limited. With legacy BIOS doing the job, it's always been smooth & straightforward to use the DOS and/or NT boot loaders to choose between multiple Windows and Linux installations on different partitions. Even though only one out of a maximum of 4 primary MBR partitions per HDD are capable of being marked bootable at a time, you can still boot from there to as many logical MBR partitions, as you can GPT volumes under UEFI. Either way HDD space is the only limitation, UEFI offers no advantage here; when Microsoft orignally claimed it did they were obviously lying. As it stands now, the Microsoft UEFI boot loader will still not boot Linux, so it is not yet as advanced as the Microsoft BIOS boot loader was 20 years ago. Therefore to multiboot Windows and Linux by UEFI, you now need to use a Linux boot loader for Windows, when you never needed to do that before, and that basically means Grub2. Too bad Syslinux 6.04 was badly fragmented in its misguided rush to attempt UEFI without deep co-operation with the actual Syslinux Project itself. So the various 6.04's are somewhat of a shitshow even though there are some nice features that hopefully will condense into stability someday when UEFI becomes truly well-handled. One can only hope. Syslinux 6.03 has been highly stable and very feature complete since 2014 and no urgent work should be expected, but that is only for FAT32 BIOS booting not UEFI. Along with Isolinux of course for CD/DVD booting, and Pxelinux for netbooting. Anyway Grub2 has some forks that will read Syslinux config files if desired. This can be good if you want to stick with the tradition of manually creating and editing your own text config file from better documented references the Syslinux and Grub1 way. Compared to the Grub2 approach which highly discourages touching the config file and autogenerates it occasionally instead in a somewhat mysterious way which is much more poorly documented. But the stable Grub2 is just fine with its own kind of config file, and now works great on UEFI for multibooting Windows. Anyway, when Windows 7 first appeared the HDD was still structured with a single NTFS partition spanning the whole HDD, with a boot loader file in the root of the volume along with a BOOT folder containing the BCD, just like Vista. XP has a couple boot files and BOOT.INI in the root with no need for a separate boot folder. So the boot files and folders were in the same drive volume that the Windows folder was installed to up until that point but this was never a required layout. This was recognized by multibooters since additional Windows installations made to different partitions required no additional boot loaders of their own. Further Windows installations to the same PC simply add an additional boot entry to the default bootmenu in the Windows config file (BOOT.INI or BCD), triggering the menu to display upon startup when there is more than one entry. A number of months after the first release of Windows 7, the boot files & folder disappeared from the Windows volume and began to be located in a small (often 100MB) hidden FAT32 first partition preceding the following second NTFS partition spanning the remainder of the HDD. Although OEM layouts often had third or fourth partitions somewhat hidden following the main Windows volume for built-in recovery and/or restoration, when you installed Windows from scratch you would not have these low-GB final partitions unless you took the effort yourself. Or in my case leave some large final partitions for various NTFS, EXTx and FAT32 formatting later. All you ever do then is add entries to an already functional bootmenu in a hidden volume. Plain to see. /s Not enough people saw it, but this was when there was finally way more space on the HDD than Windows needed, leaving plenty for Linux. Or other Windows versions, VMs will only get you so far. Judicious partitioning was as good or better than having a second HDD dedicated to Linux. PC started out with a Windows bootloader/bootmenu and with MBR/BIOS you can just add enties to boot Linuxes which are installed onto their EXTx partitions if you wanted. Or you could switch to Grub on the hidden volume and accomplish the same thing, or Syslinux since it was FAT32. But a regular Windows PC would boot to a Linux partition(s) from its original Windows bootmenu, and you had complete manual control of the config file from Windows (or Linux). Once the UEFI system descended from this structure to depend on a similar but more obscure FAT32 ESP volume containing boot files, preferably the first partition on the HDD, it cemented the sensibilty to continue adding new boot entries to the default structure, rather than restructure, except in very particular situations.
        stoplying1 4y ago
        Well, no, you don't chain-load Windows from grub either because then PCR are wrong and Bit Locker rightly complains. Which is why you... Just use the system boot manager to pick which loader to load. Easy, problem solved. And you can edit the system boot manager entries from Linux and Windows, set bootnext from either one. It's really strictly superior to what you're describing.
  - csdvrx 4y ago
    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
cryptonector 4y ago
Using ZFS makes this all a lot simpler.
- deathanatos 4y ago
  I fail to see how? The ESP partition must be vFAT on GPT, in order for the BIOS to find it. Your BIOS doesn't speak ZFS. The main partition can be whatever, but that's not typically available until after the kernel & initramfs are loaded. (As it is typically initramfs that does the prompt for the password, to decrypt it.)
- 2OEH8eoCRo0 4y ago
  ZFS is the "crypto solves this" of filesystems. Adding out of tree ZFS to the boot mix sounds hella complicated.
  - yjftsjthsd-h 4y ago
    Interestingly, GRUB actually supports ZFS; it has the dubious distinction of being the only extant implementation of ZFS that's GPL licensed, but... probably because of that... it's separate from the main OpenZFS implementation is extremely feature-poor. This results in fun things like Ubuntu's root-on-ZFS layout creating 2 pools; a boot pool (bpool) that GRUB can read, and a root pool (rpool) with the OS. It's not that complicated, but it's not nice.
    - cryptonector 4y ago
      That's because in the mid-oughts Solaris used GRUB for booting. It's really nice because you get to boot from multiple datasets in the same pool so upgrades and downgrades can be very smooth.
    - Volundr 4y ago
      Interesting. I've never really wanted on boot on ZFS, and I definitely don't see the point if I'd need a dedicated pool for it.
AshamedCaptain 4y ago
Even Windows has a separate, NTFS boot partition these days. Fail to see the point of this, and since the main take basically is "put your /boot inside the FAT ESP, or if not possible, make /boot a FAT partition", it's also bound to create a lot of disagreement.
- ChuckNorris89 4y ago
  Does it? On my Windows 11 install, the EFI partition is still FAT32. There are no other partitions than the C and the recovery partition. Am I missing something?
  - CameronNemo 4y ago
    The commenter is saying that there is an NTFS boot partition that is chained after the ESP. So UEFI mounts and execs whatever is in the (vFAT) ESP, and then that ESP bootloader loads data from the (NTFS) boot partition.
    - vetinari 4y ago
      MSR (that another partition) has no role in Windows boot. Windows will work without it being present at all.
  - p_l 4y ago
    Windows has been setting up Reserved partitions with boot code for some time now - even (or especially) on systems without EFI
    - deathanatos 4y ago
      The OP is about a separate boot partition, which is normally where the kernel and associated data (on Linux, an initramfs, obviously Windows would differ a bit). The "Reserved" partition on Windows machines isn't really a boot partition, for any meaningful definition of it. It's just … reserved, and MS being MS. On my machine, it's empty (unformatted, all 0s). It is lightly documented here: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions?view=windows-11#microsoft-reserved-partition-msr https://learn.microsoft.com/en-us/windows-hardware/manufactu... (I'd expect your typical GPT Windows install to have about four partitions: the ESP, the empty "reserved" partition, a recovery partition, and the main NTFS partition.)
candiddevmike 4y ago
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" mount "/dev/disk/by-label/boot" "/boot" grub-install --target=i386-pc "${diskpath}" grub-install --target=x86_64-efi --efi-directory=/boot --removable --no-uefi-secure-boot grub-mkconfig > "/boot/grub/grub.cfg" This makes two partitions, one for GRUB to inject legacy BIOS boot code into and one for the ESP. ESP gets mounted to /boot, grub gets setup to support both. Only bug is Debian complains about symlinking .bak files for initrd, no biggie. (This is part of a larger Debian imaging script I made)
- yjftsjthsd-h 4y ago
  > grub-mkconfig > "/boot/grub/grub.cfg" Shell redirection is fine, but you could just use `grub-mkconfig -o` to set the output file.
  - IgorPartola 4y ago
    Why? One more flag to remember whereas redirection works for any program.
    - gnu8 4y ago
      It doesn't matter which end of the egg.
      - craftkiller 4y ago
        It does when one is a standard convention compatible with all programs whereas -o does different things for different programs. For example, grep -o foo will print only the parts of the input stream that match "foo" but grep > foo will write to the file foo. Some commands don't even have a -o flag like "cat" but output redirection is still always an option.
CameronNemo 4y ago
"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.
- freedinosaur 4y ago
  The root partition already contains a set of empty directories, and Lennart has been working on reducing those where possible (see usr-merge).
  - CameronNemo 4y ago
    It just feels like such a small thing that is not even worth mentioning or taking into account.
- oynqr 4y ago
  I prefer to think that Poettering doesn't know mkdir exists. Eagerly awaiting systemd-make-directory-automatic@.path.
CameronNemo 4y ago
As growing the size of an existing ESP is problematic (for example, because there’s no space available immediately after the ESP, or because some low-quality firmware reacts badly to the ESP changing size) Code quality of the firmware in typical systems is known to not always be great. When relying on the file system driver included in the firmware it’s hence a good idea to limit use to operations that have a better chance to be correctly implemented. Remind me again why I should cater to people who insist on writing and running terrible code.
- yjftsjthsd-h 4y ago
  Because that's everyone? What computer are you using that has really high quality firmware?
  - CameronNemo 4y ago
    I guess that is fair. Most of my non-Android computers use U-Boot. One is some UEFI implementation. I don't know how it copes with growing the ESP. I don't see why it would freak, though.
    - yrro 4y ago
      Many of us have been burned by making the assumption that UEFI implementations behave sensibly. Most of the pain points have been ironed out by now, yes, but the lesson I've taken away is: don't assume.
adrian_b 4y ago
There are many years since I no longer create partitions on any SSD or HDD, because I believe that this serves no useful purpose and it just wastes a part of the SSD/HDD. I format directly the raw unpartitioned SSD/HDD with a file system that uses 100% of the capacity, with no wasted sectors. At least on Linux and FreeBSD, there is no need of partitions. For booting the computers, I either boot them from Ethernet or I boot them from a small USB memory that uses a FAT file system for storing the OS kernel, either in the format required by UEFI booting, or, when booting Linux in legacy BIOS mode, together with syslinux, which loads the kernel.
- candiddevmike 4y ago
  You're talking about saving _at most_ 200MBish. That's a lot of work to maintain for little gain...
  - adrian_b 4y ago
    There is less work, not more work.
    - Volundr 4y ago
      This sounds like work to me > For booting the computers, I either boot them from Ethernet or I boot them from a small USB memory that uses a FAT file system for storing the OS kernel, either in the format required by UEFI booting, or, when booting Linux in legacy BIOS mode, together with syslinux, which loads the kernel. Creating boot USB drives (which I think need partitions don't they?) or setting up a PXE boot server would take me a lot more effort than an extra minute with gdisk to create partitions before formatting the disk.
      - adrian_b 4y ago
        If the USB drives were bought formatted as FAT, which is always true for those smaller than 32 GB, they already have the required partition. For booting with UEFI, you just need to create the directories with the names expected by the firmware. For legacy booting, you just need to install syslinux, which takes a second. Then the USB drive can be used to boot any computer, without any other work, for many years. When you change the kernel, you just mount the USB drive (which is not mounted otherwise), then you copy the new kernel to the USB drive (possibly together with an initrd file), renaming it during the copy, you unmount the USB drive and that is all. You can keep around a few USB drives with different kernel versions, and if an update does not go well, you just replace the USB drive with one having an older version. Configuring a DHCP/TFTP server for Ethernet booting is done only once. Adding extra computers may need a directory copy in the directory of the TFTP server only when the new computers have a different hardware that requires different OS kernels. Updating a kernel requires just a file copy towards the directory of the TFTP server, replacing the old kernel. None of these operations requires more work than when using a boot partition on the root device. There is less work because you make booting USB drives or a DHCP/TFTP server only once for many years or even decades, while you need to partition the SSD/HDD whenever you buy a new one that will be used as the root device.
freedinosaur 4y ago
> Consider removing any mention of ESP/XBOOTLDR from /etc/fstab, and just let systemd-gpt-auto-generator do its thing. TIL! My NixOS configuration just got a little bit simpler, and more uniform between machines.
cesarb 4y ago
> 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 file, and wrote the list to a map file; the bootloader then read that map file (its sector hardcoded into the bootloader by the same userspace program), and loaded the kernel by reading the sectors directly. Neither the bootloader nor its userspace installer needed to know anything about filesystems or other parts of the storage stack, and it worked perfectly with RAID 1.
- yjftsjthsd-h 4y ago
  That only works with simple filesystems, though; it'll fall apart if your root filesystem uses, say, compression, encryption, or possibly any RAID except mirroring (depending on the details and what the bootloader can handle).
- krylon 4y ago
  > 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.
  - akira2501 4y ago
    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.
yjftsjthsd-h 4y ago
I'm not sold on using automount to reduce the time spent with the filesystems mounted. Unless I've missed something, having a filesystem mounted doesn't make it any more susceptible to damage; being "mounted" just means that the kernel populates its data structures in memory and adds it to the VFS, it doesn't incur any ongoing r/w access. What risks corruption is writing data... which this doesn't stop, because the moment anything tries to access it the OS will helpfully mount the filesystem again.
- jcranmer 4y ago
  If things were set up to only mount the filesystems while they're being modified to update the kernel, I can see the value in that. I'm guessing that's not being proposed here, though, because it's too much friction to change the current boot system scripts, and automount doesn't incur the same friction?
  - yjftsjthsd-h 4y ago
    Even then, what would it change? The only time those filesystems are being written to is for a new kernel, a new bootloader, or a bootloader config change. In every one of those cases, the filesystem still has to be mounted, so I'm not seeing what the benefit is of keeping things unmounted right up until you're going to write something. (Basically, I can't seem to see any version of this that reduces the actual total writes to the filesystem.)
- AshamedCaptain 4y ago
  In fact, I was bitten once by corruption because the _unmount_ operation was interrupted mid-write. Not that surprising considering it's a much less tested scenario on fs code.
  - yjftsjthsd-h 4y ago
    Okay, that hadn't occurred to me. I did wonder if mounting was a problem, if VFAT has "last mounted time" or other metadata that gets written per-mount.
rektide 4y ago
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, the entries are human readable/authorable. I've been on systemd-boot for a long while now. For a while I was just hand maintaining vmlinuzs & loader entries, copying & editing stuff on /boot/efi. Easy but inelegant & I'd forget the very simple steps. I've been copy pasting (well, its in my ansible now) /etc/kernel/postinst.d/ hooks from stackoverflow, which writes these files, & that greatly simplified life. It's a jank hurdle & I wish my os would actually support this wonderful easy to use tool. Systemd-boot is so much less obtuse, such a breath or fresh air, after years of grub (and many of uboot as well, but that's a different sector). I made the jump ~two years ago to a single partition, just the ESP partition. Theres a warning abiut not being able to set permissions properly but its worked fine & been so much more pleasant to operate. Very strongly recommend. It just worked for me on Debian, no real fiddling. https://github.com/filakhtov/kernel-postinst-d/blob/master/93-bootctl-entry https://github.com/filakhtov/kernel-postinst-d/blob/master/9...
- yrro 4y ago
  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 firmware. One of the great things about open source operating systems is that people step up to provide these sorts of improvements and I think it's a shame that systemd-boot will cause regression here.
  - csdvrx 4y ago
    >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.
Kwpolska 4y ago
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 convincing real users to reinstall Windows just to make some Linux guys happy. Instead, I would prefer a different approach. An approach that can be seen in Windows and macOS, that is: no user serviceable parts inside. It would work like this: * Keep two partitions. * ESP contains a simple program (let’s call it stub), whose only job is to call the real boot loader on /boot. * The stub is simple (minimum user interaction) and doesn’t need updating very often. It has drivers/support software for storage media and some reasonable file systems (VFAT, Ext4). It may also support some simple form of disk encryption if desired. * The real bootloader (as well as any kernels) live on the separate /boot partition. The bootloader can do all the fancy things it wants, it can display a fancy wallpaper, support mouse input, and so on. * The ESP is not auto-mounted, might not even be listed in /etc/fstab. * Whenever the stub is updated (which would happen rarely, since it’s meant to be simple and minimum), some post-install scripts would mount ESP in any location they please (be it /run/{uuid.uuid4()}), copy over the new stub, and immediately unmount it. Simpler, safer, will make it harder for rogue software or `rm -rf /*` to mess up the booting of the system, and will not require any changes to existing partition tables.
- xearl 4y ago
  Your "different approach" sounds almost exactly like the approach proposed in the fine article for the "ESP too small" case (a case which you assume as a given).
- still_grokking 4y ago
  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).
sagarun 4y ago
Meanwhile the apple firmware cannot read vFAT ESP. Apple wants ESP to be HFS.
- mixmastamyk 4y ago
  Interesting, when did that start? Our ancient iMac (2009?) with Ubuntu Mate on has a vfat ESP.
- saghm 4y ago
  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 fairly typical Linux setup dual booted alongside MacOS. I remember using a blogpost I found as a reference, but I think the order of the steps I used were turning off FileVault, shrinking the main MacOS partition by the amount I wanted to use for Linux, doing the Linux install the way I normally do (one FAT ESP partition with refind installed, then the rest as a LUKS volume with LVM root and swap), turn off SIP by booting the macbook into recovery, booting into MacOS and running the `bless` command to set the refind partition to boot by default, rebooting back into recovery to turn SIP back on, and then finally booting back into MacOS and turning FileVault back on. Essentially, by temporarily turning off SIP and FileVault, I was able to get Linux booted by default with my usual LUKS/LVM setup but also have the option to select MacOS from my refind menu and have that booted with the usual FileVault/SIP protections. Based on what I'd read about the efforts to support Linux on the new ARM macbooks and Apple seemingly not going out of their way to block this, I would have thought that this method would still work, although maybe there's something I'm missing.
  - dottedmag 4y ago
    There is no UEFI on M1 macs. However boot protocol there is completely different and complicated.
    - 4y ago
hyperupcall 4y ago
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 frustrating for distributions to install GRUB, hijacking the previous prioritized boot PE, and have entries for other installed Linux distributions missing.
- amarshall 4y ago
  > through systemd, and ensure all boot images are autodiscoverable and automatically bootable. See systemd-boot and BootLoaderSpec, both mentioned in OP. https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/ https://www.freedesktop.org/wiki/Software/systemd/systemd-bo... https://systemd.io/BOOT_LOADER_SPECIFICATION/ https://systemd.io/BOOT_LOADER_SPECIFICATION/
  - hyperupcall 4y ago
    yes - not all Linux distros do this
- csdvrx 4y ago
  > 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) Same. The boot partition is a relic of the past, and you can easily do without it when you remove other relics like grub2: simply make EFI payloads the Arch way: https://wiki.archlinux.org/title/Unified_kernel_image#Manually https://wiki.archlinux.org/title/Unified_kernel_image#Manual... > The logical next step would be to standardize everything through systemd, and ensure all boot images are autodiscoverable and automatically bootable. As much as I like systemd, I think it's not necessary here: I have a EFISP that's about 16G: it also contains a few .ISO that can be loaded in case system maintenance or a full reinstall is needed. GrubFM and others like Ventoy let you boot directly on say Windows11-22H2.ISO, Ubuntu22-10.iso etc. When I buy a new drive or computer, I just copy this partition: it's much faster than playing with thumbdrives or PXE Boot.
boomboomsubban 4y ago
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.
- usr1106 4y ago
  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 that would like to remove that possibility. But why Poettering's work would make that easier I fail to see. Do you think once a real secure Linux boot is possible they will remove machine owner rights and you have to buy a signed Linux from Microsoft? Or from a Microsoft/IBM/? consortium super monopoly?
  - Vogtinator 4y ago
    > Secure boot with systemd-boot has been possible for years. It was not, ironically because of Microsoft. Shim is by policy effectively only allowed to boot grub2. So systemd-boot can't be used OOTB on secure boot enabled systems, you'd have to enroll your own key.
    - usr1106 4y ago
      > It was not, It has been possible for years. I have used it for 4 years myself and I was not the first adopter. > Shim is by policy I am not talking about shim, you don't have to use it. Here's how to do it: 1. You erase the whole key database from UEFI (That possibility was some agreement between antitrust authorities and Intel and/or Microsoft that such possibility must be provided because Wintel was in a a dominating marketing position. On Arm devices it is often not possible, Windows / ARM is not in a dominating position and antitrust was not relevant.) 2. You generate your own key pairs. 3. The public ones you install into the secure boot database of UEFI. 4. You sign your UEFI application with your private key. I have done that with `systemd-boot` and with the Linux kernel (containing the UEFI stub). Works in both cases. I used the instructions from https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Inst... 4 years ago and still do it the same way today.
einpoklum 4y ago
This blog post talks about systemd a lot. Why would I want to use systemd to set up boot partitions? I don't even have it installed on Linux distribution.
- effie 4y ago
  It's a P.R. effort to prepare the "community" for more bad and harmful solutions from Mr. Poettering and his employer Microsoft. It does not solve any real problem users have.
still_grokking 4y ago
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?
- davet91 4y ago
  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.
  - chronogram 4y ago
    The keyboard shortcuts are here: https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/ https://www.freedesktop.org/wiki/Software/systemd/systemd-bo...
- Arnavion 4y ago
  >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. It gives you a UI to choose what to boot and edit the kernel bootline. You don't need it if your UEFI firmware makes it easy for you to do that, or if you have edk2-shell available, but those are not true of all systems.
  - still_grokking 4y ago
    Sure you get a boot menu. But the UEFI bootloader also shows a boot menu if requested. I think this feature is universal. Editing the kernel command line on the other hand is something you never need except for debugging or recovery. For that you would have anyway an extra UKI installed, with a recovery system in the initrd. But in normal operation you never ever even see the boot menu. I still miss to see what vital advantages `systemd-boot` would offer. (And this has nothing to do with systemd as such. I use most of its modules. I just didn't find any compelling reason to use the boot module also. Some very simple hook script that triggers efibootmgr when needed is imho perfectly sufficient).
mixmastamyk 4y ago
As they say the more things change, the more they stay the same. Back in the day Netware would boot off a small DOS partition located at the front of the boot disk, and was started from autoexec.bat. Blew my mind at the time.
oxplot 4y ago
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+' | while read -r bn; do efibootmgr --delete-bootnum -b "$bn" &> /dev/null done || true # Install boot entry efibootmgr --verbose \ --create --disk /dev/disk/by-id/nvme-abcdef --part 1 --label "Arch Linux" \ --loader /vmlinuz-${_linux} \ --unicode "initrd=\\intel-ucode.img initrd=\\initramfs-linux.img OTHER-KERNEL-BOOT-PARAMS" EDIT: added initrd boot params
- csdvrx 4y ago
  If you want to add an initrd, create an EFI payload: https://wiki.archlinux.org/title/Unified_kernel_image#Manually 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"))) $ splash_offs=$((cmdline_offs + $(stat -c%s "/etc/kernel/cmdline"))) $ linux_offs=$((splash_offs + $(stat -c%s "/usr/share/systemd/bootctl/splash-arch.bmp"))) $ initrd_offs=$((linux_offs + $(stat -c%s "vmlinuz-file"))) $ objcopy \ --add-section .osrel="/usr/lib/os-release" --change-section-vma .osrel=$(printf 0x%x $osrel_offs) \ --add-section .cmdline="/etc/kernel/cmdline" \ --change-section-vma .cmdline=$(printf 0x%x $cmdline_offs) \ --add-section .splash="/usr/share/systemd/bootctl/splash-arch.bmp" \ --change-section-vma .splash=$(printf 0x%x $splash_offs) \ --add-section .linux="vmlinuz-file" \ --change-section-vma .linux=$(printf 0x%x $linux_offs) \ --add-section .initrd="initrd-file" \ --change-section-vma .initrd=$(printf 0x%x $initrd_offs) \ "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" "linux.efi" The resulting linux.efi" can be added directly with efibootmgr, and contains the kernel boot parameters (cmdline)
  - oxplot 4y ago
    uh - you just specify the location of your initramfs in the kernel boot params and that's it, no need for all the above
E39M5S62 4y ago
I'm a huge fan of UKI - it's part of the underlying 'magic' of ZFSBootMenu (https://github.com/zbm-dev/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.
- still_grokking 4y ago
  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.
  - phendrenad2 4y ago
    Most of the things in the UEFI spec are wishful thinking and completely unused by real-world hardware.
- Vogtinator 4y ago
  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.
  - ahesford 4y ago
    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.
superkuh 4y ago
I still use MBR. No need for extra boot partitions or all that bloated UEFI jazz. MBR on GPT disks works just fine in compatibility mode.
- effie 4y ago
  Indeed. UEFI brings "solutions" to problems we don't have, but corporations would like those solutions for some reason.
tinglymintyfrsh 4y ago
No mention of zfs, btrfs, xfs, lvm, or fde volumes from the makers of excessive-complexity cancers of systemd and pulseaudio.
- effie 4y ago
  Didn't you read the article, we're supposed to use vfat only and prepare for firmware checking our disks and revoking our boot rights on keyring and denylist updates.(LOL)
pabs3 4y ago
Hmm, I wonder what to do if you want to be able to boot the same system via both BIOS and UEFI.
- ianschmitz 4y ago
  I’m curious why that would be useful?
  - pabs3 4y ago
    Live images. Also if you still use BIOS-era hardware you found in the trash because you can't afford to buy hardware, and if someone gave you a UEFI device you can't afford the additional storage devices needed to migrate data and or because you don't want to have to deal with migrating a system or reinstalling it.
    - fuzzfactor 4y ago
      >what to do if you want to be able to boot the same system via both BIOS and UEFI. UEFI is simply supposed to find an EFI folder containing boot files, on a FAT32 partition. A proper UEFI firmware will find the EFI folder regardless of whether the layout is for MBR or if it is GPT. So you just use conventional MBR layout, format with FAT32 and throw on a (carefully crafted) EFI folder. This is how Windows live (startup) media is normally done, so you can boot to either type and install Windows to the PC. On recent Windows versions the install.wim file has crept up in size beyond what FAT32 will support, so NTFS is needed for them. Linux live distros do real well booting from FAT32 using Syslinux (ntfs is also an advanced option), just like the monolithic ISO's do using Isolinux. But to install the distro on the HDD I want an additional EXTx partition to hold the Linux, and still boot to it from the FAT32 boot volume.
- zaarn 4y ago
  you can have both MBR and GPT on the same disk. GRUB explicitly supports it too, if it finds a EE00 partition type, it will parse the disk again as GPT and boot normally to boot a second stage of the ESP. A UEFI system will ignore the MBR and use the GPT table to boot directly into the ESP. The Gentoo wiki has a description how to set this up.
teo_zero 4y ago
EFI must be a separate partition, right. But why should /boot? Mine is just a directory in the root filesystem.
- effie 4y ago
  It does not always have to, especially if your rootfs is simple. But if your rootfs is on LVM on MDRAID... then it's best to have separate simple boot fs.
Scarlxd 4y ago
I'm saving this for future
effie 4y ago
> I personally believe that making use of features in the boot file systems that the firmware environment cannot really make sense of is very clearly not advisable. The UEFI file system APIs know no symlinks, and what is SELinux to UEFI anyway? Moreover, putting more than the absolute minimum of simple data files into such file systems immediately raises questions about how to authenticate them comprehensively (including all fancy metadata) cryptographically on use It makes all the sense if you want the firmware to load your bootloader binary and then get lost. Firmware is not to be trusted to read, write, interpret, analyze or send your boot file system elsewhere. It's a closed proprietary part of your hardware ffs and unless that changes, it should be kept in dark. When there is hardware with free software firmware we can fix, then we can talk about accomodating firmware vendor needs.
effie 4y ago
> In a trusted boot world, the two file systems for the ESP and the /boot/ partition should be considered untrusted: any code or essential data read from them must be authenticated cryptographically before use. In the real world, my ESP and boot partition are trusted, since I've installed them and control them and can check them for malware, and the firmware is not trusted since there is no possibility of control, it's vendor blobs. Mr. Poettering is clearly arguing for interests of the secure boot/DRM complex, not competent owners/users.
- theandrewbailey 4y ago
  How often do you check your unauthenticated ESP and /boot for malware? Only when you suspect malware is already there? If so, it's too late. Locking them down as suggested helps to prevent the issue altogether. Yes, firmware should not be trusted, but reducing attack surfaces is a good thing. As far as your last point, the vast majority of people aren't competent computer owners or users. They don't know what to do on a technical level with malware in their boot process.
  - effie 4y ago
    > How often do you check your unauthenticated ESP and /boot for malware? I don't, because it's not something I so far cared about. But if I started caring about these sorts of attacks, I would not rely on board firmware to check software on my disks:) > vast majority of people aren't competent computer owners or users. Vast majority of people don't read HN and are not interested in the boot process. Those that do are more relevant, and I suspect many of them don't welcome Mr. Poettering's agenda. > They don't know what to do on a technical level with malware in their boot process. I'm not suggesting they should. But Mr. Poettering does not discuss origins and possible ways to solve this problem, e.g. using free software from reliable sources only and auditing software and hardware we use. He presents his (an the secure boot complex's) preferred solution to a problem that is complex and probably will try to "gently push it" on distributions like he did with systemd (his words).
bitofhope 4y ago
I yearn for a world where hard disk partitions are a memory of primitive times past confined to the minds of retrocomputing enthusiasts. I want my system board to have a firmware that can detect common variants of volume management including LVM and zpools, perhaps that thing Windows has that's kinda like software RAID for people into that kind of thing, perhaps even stuff like OpenBSD's softraid stuff. 1. Find physical disks that may be a part of a managed volume group/pool 2. Find logical volumes and file systems on the volume pools 3. Mount a filesystem by some configurable logic 4. Load and execute a kernel from the filesystem Having to allocate the first "blocks" on the imaginary "sectors" of my SSD (or even worse, a virtual disk drive) for some arbitrary amount of space formatted in possibly the most barebones filesystem still in mainstream use feels quaint and irritating and limits my ability to use that disk in a larger storage pool. UEFI is an overcomplicated specification with lots of wintel baggage, but most of it doesn't personally offend me. What does is that UEFI had the chance to abolish disk partitioning, but instead enshrined it. And added mandatory FAT32 to add insult to injury. My main laptop and desktop each have a separate disk for the EFI system partition. The former uses systemd-boot and the latter ZFSBootMenu. This way I have a maximum of one partition per disk. It's not ideal, but I like it better than the usual solution. The disks in my zpool show up as having partitions 1 and 9, but I consider that an implementation detail since I never need to treat the disks as anything other than entire disks in a pool

259 points by throw7 4y ago

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.

CameronNemo 4y ago
Can you explain what about the boot partition status quo seems hacky, and how this approach "cleans" it?
- admax88qqq 4y ago
  Issues with the current setup are pretty well laid out in the article.
  - CameronNemo 4y ago
    The article does not characterize the status quo as hacky, and furthermore does not acknowledge the existence of mainstream setups that do not share the pitfalls of the "typical setup". I.E. the article kind of creates a strawman.
    - fuzzfactor 4y ago
      In the article the Linux mount point can be as described regardless of where the Linux boot files & kernels are physically stored in the various partitions & folders. We see this variation in the wild observing the different physical locations among the different distributions. Or you could put key files in places as yet undescribable. That's a worthwhile advantage for Linux, your choices are less limited. With legacy BIOS doing the job, it's always been smooth & straightforward to use the DOS and/or NT boot loaders to choose between multiple Windows and Linux installations on different partitions. Even though only one out of a maximum of 4 primary MBR partitions per HDD are capable of being marked bootable at a time, you can still boot from there to as many logical MBR partitions, as you can GPT volumes under UEFI. Either way HDD space is the only limitation, UEFI offers no advantage here; when Microsoft orignally claimed it did they were obviously lying. As it stands now, the Microsoft UEFI boot loader will still not boot Linux, so it is not yet as advanced as the Microsoft BIOS boot loader was 20 years ago. Therefore to multiboot Windows and Linux by UEFI, you now need to use a Linux boot loader for Windows, when you never needed to do that before, and that basically means Grub2. Too bad Syslinux 6.04 was badly fragmented in its misguided rush to attempt UEFI without deep co-operation with the actual Syslinux Project itself. So the various 6.04's are somewhat of a shitshow even though there are some nice features that hopefully will condense into stability someday when UEFI becomes truly well-handled. One can only hope. Syslinux 6.03 has been highly stable and very feature complete since 2014 and no urgent work should be expected, but that is only for FAT32 BIOS booting not UEFI. Along with Isolinux of course for CD/DVD booting, and Pxelinux for netbooting. Anyway Grub2 has some forks that will read Syslinux config files if desired. This can be good if you want to stick with the tradition of manually creating and editing your own text config file from better documented references the Syslinux and Grub1 way. Compared to the Grub2 approach which highly discourages touching the config file and autogenerates it occasionally instead in a somewhat mysterious way which is much more poorly documented. But the stable Grub2 is just fine with its own kind of config file, and now works great on UEFI for multibooting Windows. Anyway, when Windows 7 first appeared the HDD was still structured with a single NTFS partition spanning the whole HDD, with a boot loader file in the root of the volume along with a BOOT folder containing the BCD, just like Vista. XP has a couple boot files and BOOT.INI in the root with no need for a separate boot folder. So the boot files and folders were in the same drive volume that the Windows folder was installed to up until that point but this was never a required layout. This was recognized by multibooters since additional Windows installations made to different partitions required no additional boot loaders of their own. Further Windows installations to the same PC simply add an additional boot entry to the default bootmenu in the Windows config file (BOOT.INI or BCD), triggering the menu to display upon startup when there is more than one entry. A number of months after the first release of Windows 7, the boot files & folder disappeared from the Windows volume and began to be located in a small (often 100MB) hidden FAT32 first partition preceding the following second NTFS partition spanning the remainder of the HDD. Although OEM layouts often had third or fourth partitions somewhat hidden following the main Windows volume for built-in recovery and/or restoration, when you installed Windows from scratch you would not have these low-GB final partitions unless you took the effort yourself. Or in my case leave some large final partitions for various NTFS, EXTx and FAT32 formatting later. All you ever do then is add entries to an already functional bootmenu in a hidden volume. Plain to see. /s Not enough people saw it, but this was when there was finally way more space on the HDD than Windows needed, leaving plenty for Linux. Or other Windows versions, VMs will only get you so far. Judicious partitioning was as good or better than having a second HDD dedicated to Linux. PC started out with a Windows bootloader/bootmenu and with MBR/BIOS you can just add enties to boot Linuxes which are installed onto their EXTx partitions if you wanted. Or you could switch to Grub on the hidden volume and accomplish the same thing, or Syslinux since it was FAT32. But a regular Windows PC would boot to a Linux partition(s) from its original Windows bootmenu, and you had complete manual control of the config file from Windows (or Linux). Once the UEFI system descended from this structure to depend on a similar but more obscure FAT32 ESP volume containing boot files, preferably the first partition on the HDD, it cemented the sensibilty to continue adding new boot entries to the default structure, rather than restructure, except in very particular situations.
      - stoplying1 4y ago
        Well, no, you don't chain-load Windows from grub either because then PCR are wrong and Bit Locker rightly complains. Which is why you... Just use the system boot manager to pick which loader to load. Easy, problem solved. And you can edit the system boot manager entries from Linux and Windows, set bootnext from either one. It's really strictly superior to what you're describing.
- csdvrx 4y ago
  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

cryptonector 4y ago

Using ZFS makes this all a lot simpler.

deathanatos 4y ago
I fail to see how? The ESP partition must be vFAT on GPT, in order for the BIOS to find it. Your BIOS doesn't speak ZFS. The main partition can be whatever, but that's not typically available until after the kernel & initramfs are loaded. (As it is typically initramfs that does the prompt for the password, to decrypt it.)
2OEH8eoCRo0 4y ago
ZFS is the "crypto solves this" of filesystems. Adding out of tree ZFS to the boot mix sounds hella complicated.
- yjftsjthsd-h 4y ago
  Interestingly, GRUB actually supports ZFS; it has the dubious distinction of being the only extant implementation of ZFS that's GPL licensed, but... probably because of that... it's separate from the main OpenZFS implementation is extremely feature-poor. This results in fun things like Ubuntu's root-on-ZFS layout creating 2 pools; a boot pool (bpool) that GRUB can read, and a root pool (rpool) with the OS. It's not that complicated, but it's not nice.
  - cryptonector 4y ago
    That's because in the mid-oughts Solaris used GRUB for booting. It's really nice because you get to boot from multiple datasets in the same pool so upgrades and downgrades can be very smooth.
  - Volundr 4y ago
    Interesting. I've never really wanted on boot on ZFS, and I definitely don't see the point if I'd need a dedicated pool for it.

AshamedCaptain 4y ago

Even Windows has a separate, NTFS boot partition these days. Fail to see the point of this, and since the main take basically is "put your /boot inside the FAT ESP, or if not possible, make /boot a FAT partition", it's also bound to create a lot of disagreement.

ChuckNorris89 4y ago
Does it? On my Windows 11 install, the EFI partition is still FAT32. There are no other partitions than the C and the recovery partition. Am I missing something?
- CameronNemo 4y ago
  The commenter is saying that there is an NTFS boot partition that is chained after the ESP. So UEFI mounts and execs whatever is in the (vFAT) ESP, and then that ESP bootloader loads data from the (NTFS) boot partition.
  - vetinari 4y ago
    MSR (that another partition) has no role in Windows boot. Windows will work without it being present at all.
- p_l 4y ago
  Windows has been setting up Reserved partitions with boot code for some time now - even (or especially) on systems without EFI
  - deathanatos 4y ago
    The OP is about a separate boot partition, which is normally where the kernel and associated data (on Linux, an initramfs, obviously Windows would differ a bit). The "Reserved" partition on Windows machines isn't really a boot partition, for any meaningful definition of it. It's just … reserved, and MS being MS. On my machine, it's empty (unformatted, all 0s). It is lightly documented here: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions?view=windows-11#microsoft-reserved-partition-msr https://learn.microsoft.com/en-us/windows-hardware/manufactu... (I'd expect your typical GPT Windows install to have about four partitions: the ESP, the empty "reserved" partition, a recovery partition, and the main NTFS partition.)

candiddevmike 4y ago

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" mount "/dev/disk/by-label/boot" "/boot" grub-install --target=i386-pc "${diskpath}" grub-install --target=x86_64-efi --efi-directory=/boot --removable --no-uefi-secure-boot grub-mkconfig > "/boot/grub/grub.cfg" This makes two partitions, one for GRUB to inject legacy BIOS boot code into and one for the ESP. ESP gets mounted to /boot, grub gets setup to support both. Only bug is Debian complains about symlinking .bak files for initrd, no biggie. (This is part of a larger Debian imaging script I made)

yjftsjthsd-h 4y ago
> grub-mkconfig > "/boot/grub/grub.cfg" Shell redirection is fine, but you could just use `grub-mkconfig -o` to set the output file.
- IgorPartola 4y ago
  Why? One more flag to remember whereas redirection works for any program.
  - gnu8 4y ago
    It doesn't matter which end of the egg.
    - craftkiller 4y ago
      It does when one is a standard convention compatible with all programs whereas -o does different things for different programs. For example, grep -o foo will print only the parts of the input stream that match "foo" but grep > foo will write to the file foo. Some commands don't even have a -o flag like "cat" but output redirection is still always an option.

CameronNemo 4y ago

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

freedinosaur 4y ago
The root partition already contains a set of empty directories, and Lennart has been working on reducing those where possible (see usr-merge).
- CameronNemo 4y ago
  It just feels like such a small thing that is not even worth mentioning or taking into account.
oynqr 4y ago
I prefer to think that Poettering doesn't know mkdir exists. Eagerly awaiting systemd-make-directory-automatic@.path.

CameronNemo 4y ago

As growing the size of an existing ESP is problematic (for example, because there’s no space available immediately after the ESP, or because some low-quality firmware reacts badly to the ESP changing size) Code quality of the firmware in typical systems is known to not always be great. When relying on the file system driver included in the firmware it’s hence a good idea to limit use to operations that have a better chance to be correctly implemented. Remind me again why I should cater to people who insist on writing and running terrible code.

yjftsjthsd-h 4y ago
Because that's everyone? What computer are you using that has really high quality firmware?
- CameronNemo 4y ago
  I guess that is fair. Most of my non-Android computers use U-Boot. One is some UEFI implementation. I don't know how it copes with growing the ESP. I don't see why it would freak, though.
  - yrro 4y ago
    Many of us have been burned by making the assumption that UEFI implementations behave sensibly. Most of the pain points have been ironed out by now, yes, but the lesson I've taken away is: don't assume.

adrian_b 4y ago

There are many years since I no longer create partitions on any SSD or HDD, because I believe that this serves no useful purpose and it just wastes a part of the SSD/HDD. I format directly the raw unpartitioned SSD/HDD with a file system that uses 100% of the capacity, with no wasted sectors. At least on Linux and FreeBSD, there is no need of partitions. For booting the computers, I either boot them from Ethernet or I boot them from a small USB memory that uses a FAT file system for storing the OS kernel, either in the format required by UEFI booting, or, when booting Linux in legacy BIOS mode, together with syslinux, which loads the kernel.

candiddevmike 4y ago
You're talking about saving _at most_ 200MBish. That's a lot of work to maintain for little gain...
- adrian_b 4y ago
  There is less work, not more work.
  - Volundr 4y ago
    This sounds like work to me > For booting the computers, I either boot them from Ethernet or I boot them from a small USB memory that uses a FAT file system for storing the OS kernel, either in the format required by UEFI booting, or, when booting Linux in legacy BIOS mode, together with syslinux, which loads the kernel. Creating boot USB drives (which I think need partitions don't they?) or setting up a PXE boot server would take me a lot more effort than an extra minute with gdisk to create partitions before formatting the disk.
    - adrian_b 4y ago
      If the USB drives were bought formatted as FAT, which is always true for those smaller than 32 GB, they already have the required partition. For booting with UEFI, you just need to create the directories with the names expected by the firmware. For legacy booting, you just need to install syslinux, which takes a second. Then the USB drive can be used to boot any computer, without any other work, for many years. When you change the kernel, you just mount the USB drive (which is not mounted otherwise), then you copy the new kernel to the USB drive (possibly together with an initrd file), renaming it during the copy, you unmount the USB drive and that is all. You can keep around a few USB drives with different kernel versions, and if an update does not go well, you just replace the USB drive with one having an older version. Configuring a DHCP/TFTP server for Ethernet booting is done only once. Adding extra computers may need a directory copy in the directory of the TFTP server only when the new computers have a different hardware that requires different OS kernels. Updating a kernel requires just a file copy towards the directory of the TFTP server, replacing the old kernel. None of these operations requires more work than when using a boot partition on the root device. There is less work because you make booting USB drives or a DHCP/TFTP server only once for many years or even decades, while you need to partition the SSD/HDD whenever you buy a new one that will be used as the root device.

freedinosaur 4y ago

> Consider removing any mention of ESP/XBOOTLDR from /etc/fstab, and just let systemd-gpt-auto-generator do its thing. TIL! My NixOS configuration just got a little bit simpler, and more uniform between machines.

cesarb 4y ago

> 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 file, and wrote the list to a map file; the bootloader then read that map file (its sector hardcoded into the bootloader by the same userspace program), and loaded the kernel by reading the sectors directly. Neither the bootloader nor its userspace installer needed to know anything about filesystems or other parts of the storage stack, and it worked perfectly with RAID 1.

yjftsjthsd-h 4y ago
That only works with simple filesystems, though; it'll fall apart if your root filesystem uses, say, compression, encryption, or possibly any RAID except mirroring (depending on the details and what the bootloader can handle).
krylon 4y ago
> 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.
- akira2501 4y ago
  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.

yjftsjthsd-h 4y ago

I'm not sold on using automount to reduce the time spent with the filesystems mounted. Unless I've missed something, having a filesystem mounted doesn't make it any more susceptible to damage; being "mounted" just means that the kernel populates its data structures in memory and adds it to the VFS, it doesn't incur any ongoing r/w access. What risks corruption is writing data... which this doesn't stop, because the moment anything tries to access it the OS will helpfully mount the filesystem again.

jcranmer 4y ago
If things were set up to only mount the filesystems while they're being modified to update the kernel, I can see the value in that. I'm guessing that's not being proposed here, though, because it's too much friction to change the current boot system scripts, and automount doesn't incur the same friction?
- yjftsjthsd-h 4y ago
  Even then, what would it change? The only time those filesystems are being written to is for a new kernel, a new bootloader, or a bootloader config change. In every one of those cases, the filesystem still has to be mounted, so I'm not seeing what the benefit is of keeping things unmounted right up until you're going to write something. (Basically, I can't seem to see any version of this that reduces the actual total writes to the filesystem.)
AshamedCaptain 4y ago
In fact, I was bitten once by corruption because the _unmount_ operation was interrupted mid-write. Not that surprising considering it's a much less tested scenario on fs code.
- yjftsjthsd-h 4y ago
  Okay, that hadn't occurred to me. I did wonder if mounting was a problem, if VFAT has "last mounted time" or other metadata that gets written per-mount.

rektide 4y ago

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, the entries are human readable/authorable. I've been on systemd-boot for a long while now. For a while I was just hand maintaining vmlinuzs & loader entries, copying & editing stuff on /boot/efi. Easy but inelegant & I'd forget the very simple steps. I've been copy pasting (well, its in my ansible now) /etc/kernel/postinst.d/ hooks from stackoverflow, which writes these files, & that greatly simplified life. It's a jank hurdle & I wish my os would actually support this wonderful easy to use tool. Systemd-boot is so much less obtuse, such a breath or fresh air, after years of grub (and many of uboot as well, but that's a different sector). I made the jump ~two years ago to a single partition, just the ESP partition. Theres a warning abiut not being able to set permissions properly but its worked fine & been so much more pleasant to operate. Very strongly recommend. It just worked for me on Debian, no real fiddling. https://github.com/filakhtov/kernel-postinst-d/blob/master/93-bootctl-entry https://github.com/filakhtov/kernel-postinst-d/blob/master/9...

yrro 4y ago
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 firmware. One of the great things about open source operating systems is that people step up to provide these sorts of improvements and I think it's a shame that systemd-boot will cause regression here.
- csdvrx 4y ago
  >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.

Kwpolska 4y ago

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 convincing real users to reinstall Windows just to make some Linux guys happy. Instead, I would prefer a different approach. An approach that can be seen in Windows and macOS, that is: no user serviceable parts inside. It would work like this: * Keep two partitions. * ESP contains a simple program (let’s call it stub), whose only job is to call the real boot loader on /boot. * The stub is simple (minimum user interaction) and doesn’t need updating very often. It has drivers/support software for storage media and some reasonable file systems (VFAT, Ext4). It may also support some simple form of disk encryption if desired. * The real bootloader (as well as any kernels) live on the separate /boot partition. The bootloader can do all the fancy things it wants, it can display a fancy wallpaper, support mouse input, and so on. * The ESP is not auto-mounted, might not even be listed in /etc/fstab. * Whenever the stub is updated (which would happen rarely, since it’s meant to be simple and minimum), some post-install scripts would mount ESP in any location they please (be it /run/{uuid.uuid4()}), copy over the new stub, and immediately unmount it. Simpler, safer, will make it harder for rogue software or `rm -rf /*` to mess up the booting of the system, and will not require any changes to existing partition tables.

xearl 4y ago
Your "different approach" sounds almost exactly like the approach proposed in the fine article for the "ESP too small" case (a case which you assume as a given).
still_grokking 4y ago
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).

sagarun 4y ago

Meanwhile the apple firmware cannot read vFAT ESP. Apple wants ESP to be HFS.

mixmastamyk 4y ago
Interesting, when did that start? Our ancient iMac (2009?) with Ubuntu Mate on has a vfat ESP.
saghm 4y ago
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 fairly typical Linux setup dual booted alongside MacOS. I remember using a blogpost I found as a reference, but I think the order of the steps I used were turning off FileVault, shrinking the main MacOS partition by the amount I wanted to use for Linux, doing the Linux install the way I normally do (one FAT ESP partition with refind installed, then the rest as a LUKS volume with LVM root and swap), turn off SIP by booting the macbook into recovery, booting into MacOS and running the `bless` command to set the refind partition to boot by default, rebooting back into recovery to turn SIP back on, and then finally booting back into MacOS and turning FileVault back on. Essentially, by temporarily turning off SIP and FileVault, I was able to get Linux booted by default with my usual LUKS/LVM setup but also have the option to select MacOS from my refind menu and have that booted with the usual FileVault/SIP protections. Based on what I'd read about the efforts to support Linux on the new ARM macbooks and Apple seemingly not going out of their way to block this, I would have thought that this method would still work, although maybe there's something I'm missing.
- dottedmag 4y ago
  There is no UEFI on M1 macs. However boot protocol there is completely different and complicated.
  - 4y ago

hyperupcall 4y ago

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 frustrating for distributions to install GRUB, hijacking the previous prioritized boot PE, and have entries for other installed Linux distributions missing.

amarshall 4y ago
> through systemd, and ensure all boot images are autodiscoverable and automatically bootable. See systemd-boot and BootLoaderSpec, both mentioned in OP. https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/ https://www.freedesktop.org/wiki/Software/systemd/systemd-bo... https://systemd.io/BOOT_LOADER_SPECIFICATION/ https://systemd.io/BOOT_LOADER_SPECIFICATION/
- hyperupcall 4y ago
  yes - not all Linux distros do this
csdvrx 4y ago
> 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) Same. The boot partition is a relic of the past, and you can easily do without it when you remove other relics like grub2: simply make EFI payloads the Arch way: https://wiki.archlinux.org/title/Unified_kernel_image#Manually https://wiki.archlinux.org/title/Unified_kernel_image#Manual... > The logical next step would be to standardize everything through systemd, and ensure all boot images are autodiscoverable and automatically bootable. As much as I like systemd, I think it's not necessary here: I have a EFISP that's about 16G: it also contains a few .ISO that can be loaded in case system maintenance or a full reinstall is needed. GrubFM and others like Ventoy let you boot directly on say Windows11-22H2.ISO, Ubuntu22-10.iso etc. When I buy a new drive or computer, I just copy this partition: it's much faster than playing with thumbdrives or PXE Boot.

boomboomsubban 4y ago

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.

usr1106 4y ago
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 that would like to remove that possibility. But why Poettering's work would make that easier I fail to see. Do you think once a real secure Linux boot is possible they will remove machine owner rights and you have to buy a signed Linux from Microsoft? Or from a Microsoft/IBM/? consortium super monopoly?
- Vogtinator 4y ago
  > Secure boot with systemd-boot has been possible for years. It was not, ironically because of Microsoft. Shim is by policy effectively only allowed to boot grub2. So systemd-boot can't be used OOTB on secure boot enabled systems, you'd have to enroll your own key.
  - usr1106 4y ago
    > It was not, It has been possible for years. I have used it for 4 years myself and I was not the first adopter. > Shim is by policy I am not talking about shim, you don't have to use it. Here's how to do it: 1. You erase the whole key database from UEFI (That possibility was some agreement between antitrust authorities and Intel and/or Microsoft that such possibility must be provided because Wintel was in a a dominating marketing position. On Arm devices it is often not possible, Windows / ARM is not in a dominating position and antitrust was not relevant.) 2. You generate your own key pairs. 3. The public ones you install into the secure boot database of UEFI. 4. You sign your UEFI application with your private key. I have done that with `systemd-boot` and with the Linux kernel (containing the UEFI stub). Works in both cases. I used the instructions from https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Inst... 4 years ago and still do it the same way today.

einpoklum 4y ago

This blog post talks about systemd a lot. Why would I want to use systemd to set up boot partitions? I don't even have it installed on Linux distribution.

effie 4y ago
It's a P.R. effort to prepare the "community" for more bad and harmful solutions from Mr. Poettering and his employer Microsoft. It does not solve any real problem users have.

still_grokking 4y ago

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?

davet91 4y ago
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.
- chronogram 4y ago
  The keyboard shortcuts are here: https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/ https://www.freedesktop.org/wiki/Software/systemd/systemd-bo...
Arnavion 4y ago
>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. It gives you a UI to choose what to boot and edit the kernel bootline. You don't need it if your UEFI firmware makes it easy for you to do that, or if you have edk2-shell available, but those are not true of all systems.
- still_grokking 4y ago
  Sure you get a boot menu. But the UEFI bootloader also shows a boot menu if requested. I think this feature is universal. Editing the kernel command line on the other hand is something you never need except for debugging or recovery. For that you would have anyway an extra UKI installed, with a recovery system in the initrd. But in normal operation you never ever even see the boot menu. I still miss to see what vital advantages `systemd-boot` would offer. (And this has nothing to do with systemd as such. I use most of its modules. I just didn't find any compelling reason to use the boot module also. Some very simple hook script that triggers efibootmgr when needed is imho perfectly sufficient).

mixmastamyk 4y ago

As they say the more things change, the more they stay the same. Back in the day Netware would boot off a small DOS partition located at the front of the boot disk, and was started from autoexec.bat. Blew my mind at the time.

oxplot 4y ago

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+' | while read -r bn; do efibootmgr --delete-bootnum -b "$bn" &> /dev/null done || true # Install boot entry efibootmgr --verbose \ --create --disk /dev/disk/by-id/nvme-abcdef --part 1 --label "Arch Linux" \ --loader /vmlinuz-${_linux} \ --unicode "initrd=\\intel-ucode.img initrd=\\initramfs-linux.img OTHER-KERNEL-BOOT-PARAMS" EDIT: added initrd boot params

csdvrx 4y ago
If you want to add an initrd, create an EFI payload: https://wiki.archlinux.org/title/Unified_kernel_image#Manually 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"))) $ splash_offs=$((cmdline_offs + $(stat -c%s "/etc/kernel/cmdline"))) $ linux_offs=$((splash_offs + $(stat -c%s "/usr/share/systemd/bootctl/splash-arch.bmp"))) $ initrd_offs=$((linux_offs + $(stat -c%s "vmlinuz-file"))) $ objcopy \ --add-section .osrel="/usr/lib/os-release" --change-section-vma .osrel=$(printf 0x%x $osrel_offs) \ --add-section .cmdline="/etc/kernel/cmdline" \ --change-section-vma .cmdline=$(printf 0x%x $cmdline_offs) \ --add-section .splash="/usr/share/systemd/bootctl/splash-arch.bmp" \ --change-section-vma .splash=$(printf 0x%x $splash_offs) \ --add-section .linux="vmlinuz-file" \ --change-section-vma .linux=$(printf 0x%x $linux_offs) \ --add-section .initrd="initrd-file" \ --change-section-vma .initrd=$(printf 0x%x $initrd_offs) \ "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" "linux.efi" The resulting linux.efi" can be added directly with efibootmgr, and contains the kernel boot parameters (cmdline)
- oxplot 4y ago
  uh - you just specify the location of your initramfs in the kernel boot params and that's it, no need for all the above

E39M5S62 4y ago

I'm a huge fan of UKI - it's part of the underlying 'magic' of ZFSBootMenu (https://github.com/zbm-dev/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.

still_grokking 4y ago
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.
- phendrenad2 4y ago
  Most of the things in the UEFI spec are wishful thinking and completely unused by real-world hardware.
Vogtinator 4y ago
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.
- ahesford 4y ago
  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.

superkuh 4y ago

I still use MBR. No need for extra boot partitions or all that bloated UEFI jazz. MBR on GPT disks works just fine in compatibility mode.

effie 4y ago
Indeed. UEFI brings "solutions" to problems we don't have, but corporations would like those solutions for some reason.

tinglymintyfrsh 4y ago

No mention of zfs, btrfs, xfs, lvm, or fde volumes from the makers of excessive-complexity cancers of systemd and pulseaudio.

effie 4y ago
Didn't you read the article, we're supposed to use vfat only and prepare for firmware checking our disks and revoking our boot rights on keyring and denylist updates.(LOL)

pabs3 4y ago

Hmm, I wonder what to do if you want to be able to boot the same system via both BIOS and UEFI.

ianschmitz 4y ago
I’m curious why that would be useful?
- pabs3 4y ago
  Live images. Also if you still use BIOS-era hardware you found in the trash because you can't afford to buy hardware, and if someone gave you a UEFI device you can't afford the additional storage devices needed to migrate data and or because you don't want to have to deal with migrating a system or reinstalling it.
  - fuzzfactor 4y ago
    >what to do if you want to be able to boot the same system via both BIOS and UEFI. UEFI is simply supposed to find an EFI folder containing boot files, on a FAT32 partition. A proper UEFI firmware will find the EFI folder regardless of whether the layout is for MBR or if it is GPT. So you just use conventional MBR layout, format with FAT32 and throw on a (carefully crafted) EFI folder. This is how Windows live (startup) media is normally done, so you can boot to either type and install Windows to the PC. On recent Windows versions the install.wim file has crept up in size beyond what FAT32 will support, so NTFS is needed for them. Linux live distros do real well booting from FAT32 using Syslinux (ntfs is also an advanced option), just like the monolithic ISO's do using Isolinux. But to install the distro on the HDD I want an additional EXTx partition to hold the Linux, and still boot to it from the FAT32 boot volume.
zaarn 4y ago
you can have both MBR and GPT on the same disk. GRUB explicitly supports it too, if it finds a EE00 partition type, it will parse the disk again as GPT and boot normally to boot a second stage of the ESP. A UEFI system will ignore the MBR and use the GPT table to boot directly into the ESP. The Gentoo wiki has a description how to set this up.

teo_zero 4y ago

EFI must be a separate partition, right. But why should /boot? Mine is just a directory in the root filesystem.

effie 4y ago
It does not always have to, especially if your rootfs is simple. But if your rootfs is on LVM on MDRAID... then it's best to have separate simple boot fs.

Scarlxd 4y ago

I'm saving this for future

effie 4y ago

> I personally believe that making use of features in the boot file systems that the firmware environment cannot really make sense of is very clearly not advisable. The UEFI file system APIs know no symlinks, and what is SELinux to UEFI anyway? Moreover, putting more than the absolute minimum of simple data files into such file systems immediately raises questions about how to authenticate them comprehensively (including all fancy metadata) cryptographically on use It makes all the sense if you want the firmware to load your bootloader binary and then get lost. Firmware is not to be trusted to read, write, interpret, analyze or send your boot file system elsewhere. It's a closed proprietary part of your hardware ffs and unless that changes, it should be kept in dark. When there is hardware with free software firmware we can fix, then we can talk about accomodating firmware vendor needs.

effie 4y ago

> In a trusted boot world, the two file systems for the ESP and the /boot/ partition should be considered untrusted: any code or essential data read from them must be authenticated cryptographically before use. In the real world, my ESP and boot partition are trusted, since I've installed them and control them and can check them for malware, and the firmware is not trusted since there is no possibility of control, it's vendor blobs. Mr. Poettering is clearly arguing for interests of the secure boot/DRM complex, not competent owners/users.

theandrewbailey 4y ago
How often do you check your unauthenticated ESP and /boot for malware? Only when you suspect malware is already there? If so, it's too late. Locking them down as suggested helps to prevent the issue altogether. Yes, firmware should not be trusted, but reducing attack surfaces is a good thing. As far as your last point, the vast majority of people aren't competent computer owners or users. They don't know what to do on a technical level with malware in their boot process.
- effie 4y ago
  > How often do you check your unauthenticated ESP and /boot for malware? I don't, because it's not something I so far cared about. But if I started caring about these sorts of attacks, I would not rely on board firmware to check software on my disks:) > vast majority of people aren't competent computer owners or users. Vast majority of people don't read HN and are not interested in the boot process. Those that do are more relevant, and I suspect many of them don't welcome Mr. Poettering's agenda. > They don't know what to do on a technical level with malware in their boot process. I'm not suggesting they should. But Mr. Poettering does not discuss origins and possible ways to solve this problem, e.g. using free software from reliable sources only and auditing software and hardware we use. He presents his (an the secure boot complex's) preferred solution to a problem that is complex and probably will try to "gently push it" on distributions like he did with systemd (his words).

bitofhope 4y ago

I yearn for a world where hard disk partitions are a memory of primitive times past confined to the minds of retrocomputing enthusiasts. I want my system board to have a firmware that can detect common variants of volume management including LVM and zpools, perhaps that thing Windows has that's kinda like software RAID for people into that kind of thing, perhaps even stuff like OpenBSD's softraid stuff. 1. Find physical disks that may be a part of a managed volume group/pool 2. Find logical volumes and file systems on the volume pools 3. Mount a filesystem by some configurable logic 4. Load and execute a kernel from the filesystem Having to allocate the first "blocks" on the imaginary "sectors" of my SSD (or even worse, a virtual disk drive) for some arbitrary amount of space formatted in possibly the most barebones filesystem still in mainstream use feels quaint and irritating and limits my ability to use that disk in a larger storage pool. UEFI is an overcomplicated specification with lots of wintel baggage, but most of it doesn't personally offend me. What does is that UEFI had the chance to abolish disk partitioning, but instead enshrined it. And added mandatory FAT32 to add insult to injury. My main laptop and desktop each have a separate disk for the EFI system partition. The former uses systemd-boot and the latter ZFSBootMenu. This way I have a maximum of one partition per disk. It's not ideal, but I like it better than the usual solution. The disks in my zpool show up as having partitions 1 and 9, but I consider that an implementation detail since I never need to treat the disks as anything other than entire disks in a pool