Live data from Hacker News

Linux boot partitions and how to set them up

0pointer.net

161–170 of 184 posts

Re: Linux boot partitions and how to set them up

#161

Earlier quoted context omitted.

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

>But the UEFI bootloader also shows a boot menu if requested. I think this feature is universal.

There is no "the UEFI bootloader" and there is no "universal" boot menu. The firmware only has to boot EFI applications according to the EFI vars.

Re: Linux boot partitions and how to set them up

#162
post #159
post #154

Earlier quoted context omitted.

> I've done as you suggest in years gone by with either metadata v0.9 or v1.0 Then why did you wrote > it is not possible to make it part of a software RAID device You are saying it is both not possible and that you've done it.

It is NOT possible to have the UEFI access the RAID device so that if one of the mirrors is broken it can continue to boot in degraded mode. It requires manual intervention of a knowledgable person to boot a UEFI system into the default OS if the ESP is broken or missing.

OK now I get what you mean. In that case, one can reboot and select the other non-broken disk and the system will boot, with some hiccups due to degraded array, but it will boot.

Re: Linux boot partitions and how to set them up

#163

Earlier quoted context omitted.

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

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

On some Lenovo machines (x86) deleting the key database can brick the machine. So while you can technically do it in practice you can't.

Re: Linux boot partitions and how to set them up

#164
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…

When I install a new OS I typically just use the guided installer which makes the partitions automatically. This is usually the default too. I would actually have to go out of my way to set it up so that the drive is a single partition then on top of that create a USB drive that I'd need to always have on hand which sounds like a tremendous PITA with a laptop.

If it it works for you great but that is a LOT of extra work to regain less than 1% of the storage on a drive.

Re: Linux boot partitions and how to set them up

#165

Earlier quoted context omitted.

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

On some Lenovo machines (x86) deleting the key database can brick the machine. So while you can technically do it in practice you can't.

This sounds worrisome. Could you explain more? How can this brick a machine?

Re: Linux boot partitions and how to set them up

#166
post #107

Earlier quoted context omitted.

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

M1 Macs have more in common with iPhones than with Intel Macs. See https://github.com/AsahiLinux/docs/wiki/SW%3ABoot for example.

Some snarky people would even say that modern Macs are in fact iPhones, just with a different form factor.

The unification of the operating systems for both devices continues with every macOS release. (And that's not only about the unification of the naming scheme…)

Re: Linux boot partitions and how to set them up

#167

Earlier quoted context omitted.

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…

>But the UEFI bootloader also shows a boot menu if requested. I think this feature is universal. There is no " the UEFI bootloader" and there is no "universal" boot menu. The firmware only has to boot EFI applications according to the EFI vars.

I've never seen a PC without a UEFI boot menu. That's why I've assumed that this is universal.

Who builds PCs without that feature?

Edit: I've had a look at the spec. Indeed a boot menu isn't mandatory (except when it is, for network boot options, see `PXE_BOOT_MENU`).

> UEFI specifies only the NVRAM variables used in selecting boot options. UEFI leaves the implementation of the menu system as value added implementation space.

But it seems to be common to implement this, as the spec also says:

> If the boot via Boot#### returns with a status of EFI_SUCCESS, platform firmware supports boot manager menu, and if firmware is configured to boot in an interactive mode, the boot manager will stop processing the BootOrder variable and present a boot manager menu to the user.

There are at least a dozen more references to a boot menu in the spec.

Re: Linux boot partitions and how to set them up

#168
post #145

Earlier quoted context omitted.

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

There are more reasons to set it up more or less like that.

Think of an expensive, super fast but considerably small SSD, and some cheap big mass storage (maybe even on spinning rust) along that.

You'll likely try to use the expensive SSD as efficiently as possible. Every GB counts if you have "only", say, 0.5 TB.

A boot partition on such expensive and small (but fast) media is pure wastage.

Also this kind of setup seems not so uncommon, as I can claim that I've done something similar. :-)

There are even more reasons. It makes things even more simple and less error prone:

The argument that you can swap disks more easy was mentioned already. But that's not everything one gains.

SSDs are very prone to get worn out much quicker and loose at least half of their performance when you mess up the data alignment on them. In case of FDE with partitions (maybe on top of LVM even) the alignment issues isn't trivial. It's quite easy to mess up the alignment by mistake. You can read a lot of docs, try to find out details about the chips on your SSD, do calculations, yada yada, or you just encrypt the raw device and use the whole disk without partitions. That's considerably simpler, nothing can go wrong.

Re: Linux boot partitions and how to set them up

#169

Earlier quoted context omitted.

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

On some Lenovo machines (x86) deleting the key database can brick the machine. So while you can technically do it in practice you can't.

Do you have a reference?

Deleting the key database can not be done programmatically (unless UEFI has a bug). In all machines I have looked it's an option in the BIOS. So that should be clear case of warranty repair. Which of course does not help you if you do it after warranty has ended.

Re: Linux boot partitions and how to set them up

#170

Earlier quoted context omitted.

On some Lenovo machines (x86) deleting the key database can brick the machine. So while you can technically do it in practice you can't.

Do you have a reference? Deleting the key database can not be done programmatically (unless UEFI has a bug). In all machines I have looked it's an option in the BIOS. So that should be clear case of warranty repair. Which of course does not help you if you do it after warranty has ended.

https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T-...

It's an option in the UEFI.

Post reply on HN