Hacker News Reader

Comment by candiddevmike | Hacker News Reader

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)

View on HN

> grub-mkconfig > "/boot/grub/grub.cfg"

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

Why? One more flag to remember whereas redirection works for any program.

It doesn't matter which end of the egg.

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.

Careful, not always -- if they ever work with a pager they need to be able to detect redirection

To my understanding the shell will truncate the redirect target even if the command fails.

Using -o makes failure nondestructive.

Mmm I would argue that using -o may make failures non-destructive at the discretion of the author of the program. I don’t know what the program does. Does it safely and securely create a temporary file, then write the contents to it, then rename the file? This would need to happen on the same file system as the target file for the rename to be atomic and there are few guarantees that my current user has the permissions to write to any file other than this one. It also would certainly fail if the file system is full.

Or the program could start out by deleting my file and starting to line buffer write to it as it executes. Then the failure would be the same as shell redirection. Or it could buffer differently making program failure even more fun.

My point is that I don’t know what the program will do, or even what this particular version will do, without looking at its code.

Shell redirection has predictable semantics. And I can output to a different file, run diff on the two, then rename myself, if this is truly critical. And muscle memory will be faster than looking up the specific option or argument for this specific program.

The symlinking .bat files for initrd ended up completely bricking my Ubuntu installation a few months ago, so... take heed? I am unimpressed by the quality and robustness of that whole stuff, though, but ended up writing essentially this article into my notes for the next Arch installation I make, where I think there's a fair chance that EFI will live in /efi but be symlinked in /boot.

There's a whole other problem, though, of my wanting to use secure boot. Ubuntu was the easy out for that. At the moment, it's just disabled on my machines, which is far from optimal.

Secure boot is super easy when using a UKI.

I have a setup that's almost like what Poettering proposes. Only that I don't use any external bootloader as it seems completely unnecessary.

All you need for secure boot in such a setup is signing the UKI with your keys.

That's the simplest boot setup ever!

It's only one file, so no moving parts. It just works. No LiLo and config, no grub and config, not systemd-boot, no nothing. Just the signed UKI on the EFI partition, and a efibootmgr entry pointing to that single file. That's all needed to boot a modern system.

> This makes two partitions, one for GRUB to inject legacy BIOS boot code into and one for the ESP.

Why do you still need the legacy BIOS boot logic?

For BIOS boot, the BIOS looks at the first couple of blocks on a hard drive for the boot code. This is the first GPT partition that gets created, and the future grub-install code injects the BIOS bootloader there. Thus, to support BIOS and UEFI, you need the BIOS bootloader at the beginning of the drive.

Yes, but why would you want the BIOS boot assuming you have a motherboard made in last 10 years and it has a UEFI implementation which isn't completely broken.

I might understand doing that just in case when preparing a bootable flash drive. Why complicate things for permanent installations where you know your current hardware and your next system after 5 years is unlikely to much worse than current one?

You wouldn't, this is more for cloud/virtual images where some providers support UEFI but most still only support BIOS.

To provide more to the "why", although end-user devices have moved away from BIOS-only boot, there are large number of systems that have no alternative to BIOS, and the hardware cannot be upgraded, only the firmware and software.

Most of the systems I have ran into were in SCADA[0], PMS[1], and BMS[2].

[0]:https://en.wikipedia.org/wiki/SCADA

[1]:https://en.wikipedia.org/wiki/Power_management_system

[2]:https://en.wikipedia.org/wiki/Building_management_system

  parted -s "${diskpath}" mklabel gpt
  parted -s "${diskpath}" mkpart primary 1MiB 2MiB

Isn't "primary" wrong here? It assumes your `mklabel` command used label-type of msdos or dvh. You are using gpt though. In case of gpt "primary" is a label, not a partition type.

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

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

Reply on news.ycombinator.com