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

Linux boot partitions and how to set them up

0pointer.net

Post reply on HN
Print view View original

141–150 of 184 posts

Re: Linux boot partitions and how to set them up

#141

Post by effie »

sneak wrote: post #131
iam-TJ wrote: post #130

Earlier quoted context omitted.

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

As someone who has run /boot on raid1 for years, I think his idea in the article of keeping them synchronised in userspace at update time (ie rsync) is better. There is no reason to need realtime raid1 kernelspace sync when /boot changes only monthly.

One good reason is that mdraid takes care of syncing automatically, no need to set up rsync on every update of /boot.

Re: Linux boot partitions and how to set them up

#142

Post by still_grokking »

Arnavion wrote: post #116
still_grokking wrote: post #82

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

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

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

Re: Linux boot partitions and how to set them up

#143

Post by stoplying1 »

fuzzfactor wrote: post #133
CameronNemo wrote: post #14

Earlier quoted context omitted.

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.

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 legac…

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.

Re: Linux boot partitions and how to set them up

#144

Post by effie »

adrian_b wrote: post #54
Volundr wrote: post #42

Earlier quoted context omitted.

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 ser…

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…

It's amazing what lengths people go to to justify their convictions and not realize the silliness. You've just described a convoluted setup with many drives and computers on network and claim there is no more work.

That is more work for everybody except if they wanted a) completely encrypted main disk and booting from portable guarded USB, or b) set of computers in school or internet cafe with boot process managed/updated efficiently via network.

This system does provide new special capabilities, but it is not for free. Meanwhile, most users are happy with defaults like 1G partition with bootloader and kernel, which allows easy updates without worrying about having the right USB drive, being in the right port, being mounted in the right path, or losing it.

Re: Linux boot partitions and how to set them up

#145

Post by effie »

adrian_b wrote: post #61
cesarb wrote: post #32

Earlier quoted context omitted.

That is risky, since without a partition table, some operating systems and disk management tools will treat the disk as empty, making it easy to accidentally overwrite data. > 100% of the capacity, with no wasted sectors. You will never have that. SSDs have a large amount of reserved space, and even on HDDs, there are some reserved tracks for defect management.

By "some operating systems and disk management tools" you mean MS Windows and Windows tools. Obviously, I do not use unpartitioned SSDs/HDDs with Windows. On the other hand, With Linux and *BSD systems they work perfectly fine, regardless whether they are internal or removable. For interchange with Windows, I use only USB drives or SSDs that are partitioned and formatted as exFAT. On the unpartitioned SSDs/HDDs I use…

Also some dumb firmware may write to such disks, Asrock boards were reported in past to do that.

Efi+boot partitions usually take less than 2G of space, and can be made like 200MBs total, while mainstream disk capacity is hundreds of GBs nowadays.

This "loss of useful space" is immaterial in most cases. Maybe if you have something like a 2GB drive from 1990s that you want to use (why?) then it makes sense to shave off 1G off that. But it is more work, as you have to buy, prepare and manage the USB drive.

Re: Linux boot partitions and how to set them up

#146

Post by effie »

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

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

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

Speaking from my heart. There is a reason we have convoluted big software like GRUB - to have a single familiar software solution supporting wide range of broken hardware/firmware. Fixing all the firmware is theoretically correct and would be great, but hopelessly unrealistic in the present. We need change of culture in HW and FW vendors before we can say "that will be fixed by the firmware guys".

Re: Linux boot partitions and how to set them up

#147

Post by effie »

teo_zero wrote: post #114

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

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.

Re: Linux boot partitions and how to set them up

#148

Post by effie »

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

Re: Linux boot partitions and how to set them up

#149

Post by effie »

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

Re: Linux boot partitions and how to set them up

#150

Post by iam-TJ »

effie wrote: post #140
iam-TJ wrote: post #130

Earlier quoted context omitted.

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

> One downside to storing these images on the (FAT) EFI System Partition is it is not possible to make it part of a software RAID device, so if the device the ESP is on dies suddenly, the boot fails It is possible to make ESP part of MDRAID array of level 1 with metadata v1. True, the boot starts with single disk and only later Linux activates the array. So if your boot fails before that happens, reboot and try the o…

"don't set up MDRAID array for ESP, just have the ESP mirrored on all disks. "

Isn't that the entire point of utilising MD RAID-1 in the first place?

I've done as you suggest in years gone by with either metadata v0.9 or v1.0 (not v1.1 or v1.2) where the metadata is not at the start of the block device and therefore does not confuse a non-MDRAID-aware firmware or other OS.

Post reply on HN