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

51–56 of 56 posts

Re: ZFSBootMenu

#51

Post by ahesford »

cperciva wrote: post #37
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…

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... Not on FreeBSD. Our bootloader reuses kernel code (because, you know, developing the entire operating system together makes this possible).

ZFSBootMenu "reuses kernel code", too. It actually reuses kernel binaries, because it is nothing more than a collection of init scripts in a small Linux initramfs to enumerate ZFS filesystems and allow you to kexec one of the kernels found within. When using `generate-zbm` to build a custom image, your copy of ZFSBootMenu will use the very same kernel and ZFS driver that your system is running. When using the the prebuilt UEFI or separate kernel/initramfs that we provide as a convenience, the image is built from a Void Linux container using whatever kernel and ZFS driver was current at the time the container image was created.

I'm not sure what the complaints are about mounting filesystems. Unless you want to raw-dump your kernel and other components necessary for booting to some known offset on the disk, you'll always have to walk some filesystem to find the kernel. This even happens in the FreeBSD boot process, where one of the stages has to go looking at the filesystem for a kernel.

Re: ZFSBootMenu

#52

Post by E39M5S62 »

contingencies wrote: post #46

Nice project. In evaluating this for possible use, I have a question about workflow integration with snapshots. On gentoo-esque distros I believe there are two common configurations with ZFS, namely: (1) have a separate package repo (portage tree) ZFS dataset to the system root ZFS dataset and (2) to have them combined on one dataset. In case 2 portage changes are automatically synchronized to system snapshots, but m…

No, the ZFSBootMenu GUI does not do recursive operations on datasets / try to infer dependencies. However, there's a Bash shell that's a key press away with a full set of OpenZFS binaries. You can also do a custom build of ZFSBootMenu and add in whatever additional scripts you'd like so that you can manage snapshot rollback/promotion as you see fit.

Re: ZFSBootMenu

#53

Post by numpad0 »

themoonisachees wrote: post #40
codetrotter wrote: post #14

Earlier quoted context omitted.

When I installed FreeBSD on my Hetzner servers, I did so by booting the servers into the Linux based rescue mode and then I think I used dd to write the mfsBSD media onto one of the hard drives. This way I didn’t have to request KVM access for my servers. Perhaps a similar method can be used in order to install ZFSBootMenu

Nice tip but if you fail your server is toast and that's an interesting support ticket.

rootfs should be network mounted by NIC feature on most clouds, so it should just be the matter of clicking "Force shutdown" and "Reset disk to default install"

Re: ZFSBootMenu

#54

Post by numpad0 »

maxloh wrote: post #25
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?

Can be. A bootloader is just a baremetal application, so called not by architecture but its primary purpose of loading much larger images, jumping to it and not coming back. If the CPU is coming back, it's called a monitor program, if it's going back and forth, it's a supervisor, or a kernel. Old/mainframe folks sometimes call operating system kernel a supervisor program.

Theoretically it should be possible to flash Linux Kernel onto BIOS Flash ROM to directly load and run it from there. But x86 being x86, you also have to have bunch of circus tricks to initialize motherboard and to get out of 16-bit 8086 compatible mode and to load Kernel from disk, in such hypothetical Kernel image. BIOS/UEFI and bootloader each do parts of those.

Re: ZFSBootMenu

#55

Post by contingencies »

E39M5S62 wrote: post #52
contingencies wrote: post #46

Nice project. In evaluating this for possible use, I have a question about workflow integration with snapshots. On gentoo-esque distros I believe there are two common configurations with ZFS, namely: (1) have a separate package repo (portage tree) ZFS dataset to the system root ZFS dataset and (2) to have them combined on one dataset. In case 2 portage changes are automatically synchronized to system snapshots, but m…

No, the ZFSBootMenu GUI does not do recursive operations on datasets / try to infer dependencies. However, there's a Bash shell that's a key press away with a full set of OpenZFS binaries. You can also do a custom build of ZFSBootMenu and add in whatever additional scripts you'd like so that you can manage snapshot rollback/promotion as you see fit.

Thanks, that's what I suspected.

After writing the grandparent comment I realised some people (in particular distro devs, I suspect) may treat kernel module datasets in a similar fashion, which provides a very similar use case.

I wonder if - zfs dataset mountpoints and snapshot timings aside (both of which are already embedded in zfs) - it could be worth considering adding some zfs dataset properties as hints.

One idea (half-baked) are "zfsbootmenu-boot-significant" = "true" for ZFSBootMenu guesses for adding a default inference of latest/greatest combos. Such a binary flag should elegantly cover both kernel module and portage tree type use cases, by indicating to ZFBootMenu that the dataset in question (and snapshots thereof) provide system-integrity critical system state and should be paired with a root dataset selection. ZFSBootMenu could then make appropriate assumptions around default selections / temporally proximal pairings.

A second idea is a ZFS dataset property "zfsbootmenu-last-successful-boot" = "" which combined with snapshot times should provide a useful inference. This could be rolled in to the ZFSBootMenu userland as an rc script updating the property on boot. Additional information such as "zfsbootmenu-last-successful-boot-options" and "zfsbootmenu-last-successful-boot-dataset--snapshot" could then be added. Alternatively or in addition a zfsbootmenu dataset could be added with more detailed log files.

The result should be a cross-distribution (indeed cross-OS) methodology for the autonomous inference and validation of boot configurations involving multiple datasets in all use cases, a plethora of debugging information in a standard location, and even a mechanism to iteratively and autonomously fall back toward a functional boot configuration in the event of problems (which may be further improved using watchdog drivers, ie. if boot does not complete in X minutes, reboot and try another configuration).

Re: ZFSBootMenu

#56

Post by vermaden »

dizhn wrote: post #36
vermaden wrote: post #18

Which Linux distribution provides this out of the box in its installer like FreeBSD does? ... along with optional LUKS encryption as FreeBSD offers optional GELI encryption. I will wait ...

OpenSuse Tumbleweed has btrfs+snapper and the installer sets it up automatically. I guess they could (technically) boot other operating systems but their focus is to boot into read only snapshots of the same OS. The same setup is possible on all Linux distros but the user has to set it up.

Can BTRFS snapshots on OpenSUSE Tumbleweed (btrfs+snapper) provide same functionality as ZFS Boot Environments?

Nope.

Cite from System Recovery and Snapshot Management with Snapper for OpenSUSE Linux.

● Limitations

A complete system rollback, restoring the complete system to the identical state as it was in when a snapshot was taken, is not possible.

With ZFS Boot Environments you are bulletproof.

With btrfs+snapper you are crossing fingers if it will work the way you need.

Not the same thing.

Post reply on HN