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

ZFSBootMenu

docs.zfsbootmenu.org

Post reply on HN
Print view View original

21–30 of 56 posts

Re: ZFSBootMenu

#21

Post by hackmiester »

londons_explore wrote: post #20
jeroenhd wrote: post #15

Earlier quoted context omitted.

There's not really a way around it unless you hardcode the bootloader rather than store it on disk. That said, there are only two steps in the modern boot process on a PC: the UEFI firmware loading a basic FAT driver and the kernel mounting the other filesystems. The UEFI bootloader can use the existing FAT driver to load the kernel and the initramfs which will use the same code to mount partitions. You can skip the…

I'd quite like UEFI to be able to pass some kind of argv[0] to the direct-loaded kernel, so the kernel knows exactly which file on which partition of which disk it was loaded from. That would then become the default root filesystem. That effectively removes all config from the process - and means that any disk with a uefi executable kernel can be booted without the mystery step of "lets try to figure out where we're…

This does work inside of rEFInd, which can load a kernel EFI blob directly, and supply it args.

Re: ZFSBootMenu

#22

Post by 65a »

londons_explore wrote: post #13

It seems lame that UEFI firmware needs to 'mount' a filesystem to load a bootloader. That bootloader needs to mount a filesystem to find the kernel. The kernel needs to mount the filesystem to run the system. Each of those mount operations is done with different code, and normally each involves some config or search process to find the right disk/partition. If any of the searches finds the wrong partition or is misco…

This is precisely why UEFI is a heap of garbage, and things like coreboot, u-boot are much more appealing. It is far too complicated, and the complexity of the standard, coupled with half-assed vendor code, mean that not only is the boot process more fragile, it's also much less secure.

Re: ZFSBootMenu

#23

Post by bpye »

londons_explore wrote: post #20
jeroenhd wrote: post #15

Earlier quoted context omitted.

There's not really a way around it unless you hardcode the bootloader rather than store it on disk. That said, there are only two steps in the modern boot process on a PC: the UEFI firmware loading a basic FAT driver and the kernel mounting the other filesystems. The UEFI bootloader can use the existing FAT driver to load the kernel and the initramfs which will use the same code to mount partitions. You can skip the…

I'd quite like UEFI to be able to pass some kind of argv[0] to the direct-loaded kernel, so the kernel knows exactly which file on which partition of which disk it was loaded from. That would then become the default root filesystem. That effectively removes all config from the process - and means that any disk with a uefi executable kernel can be booted without the mystery step of "lets try to figure out where we're…

> I'd quite like UEFI to be able to pass some kind of argv[0] to the direct-loaded kernel, so the kernel knows exactly which file on which partition of which disk it was loaded from. That would then become the default root filesystem.

I think UEFI gives an EFI application (such as the Linux kernel) everything it would need for this already - but I guess Linux doesn't use it.

The EFI application entry point includes a handle to your own image [0], and the EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL_GUID [1] protocol allows you to query the path it was loaded from. It is possible for an image to be loaded without a path, but it looks like EDK2 provides it at least [2].

[0] - https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.h...

[1] - https://uefi.org/specs/UEFI/2.10/09_Protocols_EFI_Loaded_Ima...

[2] - https://github.com/tianocore/edk2/blob/991515a0583f65a64b3a6...

Re: ZFSBootMenu

#24

Post by bpye »

E39M5S62 wrote: post #7
aborsy wrote: post #5

Does ZFSBootMenu allow for entering encryption password remotely on encrypted root?

Yes - both Dracut and mkinitcpio allow you to embed an SSH server in the ZFSBootMenu initramfs (dropbear, or OpenSSH) and connect to it. Once you connect, you can access the main interface and unlock any datasets prior to kexec. https://docs.zfsbootmenu.org/en/v2.2.x/guides/general/remote...

It's an aside - but I wish there was a way to do a kexec and keep the ZFS datasets unlocked. I don't think there's anything that stops it being technically possible, but I'm pretty sure it would require kernel mode changes...

Re: ZFSBootMenu

#25

Post by maxloh »

londons_explore wrote: post #13

It seems lame that UEFI firmware needs to 'mount' a filesystem to load a bootloader. That bootloader needs to mount a filesystem to find the kernel. The kernel needs to mount the filesystem to run the system. Each of those mount operations is done with different code, and normally each involves some config or search process to find the right disk/partition. If any of the searches finds the wrong partition or is misco…

Is the bootloader itself considered as an operating system?

Does it have a kernel too?

Re: ZFSBootMenu

#26

Post by imiric »

nisa wrote: post #3

Kudos to everyone involved in this! Love everything about this. Using it on my notebook, on dedicated servers rented at Hetzner as well as on Hetzner-Cloud, as well on a bunch of dedicated servers in a rack. Solves almost all problems related to ZFS and Linux. Booting this from SYSLINUX works very well as well as UEFI - it's extensible and you can run it with the ZFS git version if you use the generate-zbm command. S…

Void is my favorite distro, and I'm interested in giving this setup a try. So far I've been reluctant to use ZFS on Linux out of reliability concerns. Have you had any issues with this setup, or have any suggestions?

Re: ZFSBootMenu

#27

Post by imiric »

anotherhue wrote: post #2

I used the FreeBSD version of this, I'm a shill at this point but I find nixos booting to an ephemeral tmpfs to be much better. This wouldn't apply if you needed to have divergent state though, though it's hard to imagine a use case for that unhandled by fs snapshots.

In what way do you find NixOS to be better?

I'm actually thinking of going the other way, from NixOS to Void+ZFS. I've been using NixOS on 2 machines for a few months now, so I'm relatively new to it, but I still struggle with basic things, and don't really grok the Nix language. If ZFS+ZFSBootMenu can give me easy snapshotting and rollback functionality, then I might prefer it over NixOS.

Sure, Nix does many more things besides snapshots, but for my use case it's the main benefit, so I wouldn't be missing much.

Re: ZFSBootMenu

#28

Post by E39M5S62 »

bpye wrote: post #24
E39M5S62 wrote: post #7

Earlier quoted context omitted.

Yes - both Dracut and mkinitcpio allow you to embed an SSH server in the ZFSBootMenu initramfs (dropbear, or OpenSSH) and connect to it. Once you connect, you can access the main interface and unlock any datasets prior to kexec. https://docs.zfsbootmenu.org/en/v2.2.x/guides/general/remote...

It's an aside - but I wish there was a way to do a kexec and keep the ZFS datasets unlocked. I don't think there's anything that stops it being technically possible, but I'm pretty sure it would require kernel mode changes...

I just add the keyfile to the initramfs. It sits under an encryptionroot and is only readable by the root user, so it's largely as safe as native encryption can be.

Re: ZFSBootMenu

#29

Post by CameronNemo »

londons_explore wrote: post #20
jeroenhd wrote: post #15

Earlier quoted context omitted.

There's not really a way around it unless you hardcode the bootloader rather than store it on disk. That said, there are only two steps in the modern boot process on a PC: the UEFI firmware loading a basic FAT driver and the kernel mounting the other filesystems. The UEFI bootloader can use the existing FAT driver to load the kernel and the initramfs which will use the same code to mount partitions. You can skip the…

I'd quite like UEFI to be able to pass some kind of argv[0] to the direct-loaded kernel, so the kernel knows exactly which file on which partition of which disk it was loaded from. That would then become the default root filesystem. That effectively removes all config from the process - and means that any disk with a uefi executable kernel can be booted without the mystery step of "lets try to figure out where we're…

I think discoverable partitions are intended to solve this problem.

https://uapi-group.org/specifications/specs/discoverable_par...

Re: ZFSBootMenu

#30

Post by bsder »

londons_explore wrote: post #13

It seems lame that UEFI firmware needs to 'mount' a filesystem to load a bootloader. That bootloader needs to mount a filesystem to find the kernel. The kernel needs to mount the filesystem to run the system. Each of those mount operations is done with different code, and normally each involves some config or search process to find the right disk/partition. If any of the searches finds the wrong partition or is misco…

More people than just you are starting to feel that way:

"I have come to bury the BIOS, not to open it: The need for holistic systems" https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-...

This also talks about how you need a boot processor to do things like train up the RAM interface just so you can boot the main processor.

Post reply on HN