EFI boot entries for integrated custom filesystem modules about efifs HOT 5 CLOSED

Is it even possible if the system root is a non-default subvolume?

No idea. That depends on how the GRUB btrfs driver is set.

Does this module automatically load all sub-volumes as directories?

No idea. Please understand that the efifs drivers I produce are just an UEFI version of the GRUB drivers. Short of a very simple set that confirms I can access an "Hello World" application, I haven't analysed what each one of these actually behaves and you will need to test that by yourself.

Can I use efibootmgr to create an efi boot entry for this?

This question is not related to efifs. The only elements I am interested in the issue tracker is whether the file system driver works as expected, or if it has an issue that requires fixing. Anything that deals with how you can use the file system driver for system setup is better asked on dedicated forums.

from efifs.

You don't have to 'load' subvolumes, they are part of the regular heirarchy, the only difference is in how the data is stored, and GRUB's driver handles this fine. All you need to do is pass the full path from the root of the filesystem, instead of relative to the subvolume, and you can get to anything. The GRUB drivers (and by extension the efifs ones) are fully read-only, but that also means you may not see up to the last 30 seconds of writes with them after an unclean shutdown.

As far as a boot entry, probably not. UEFI is heavily built on the concept of partitions, and most UEFI implementations won't even try to boot a disk if it doesn't have a valid GPT, and quite a few will still refuse to boot without an ESP. The approach I took on a similar setup (two disks in BTRFS raid1 mode) is pretty simple, and probably your best option:

1. Set up both disks with a small ESP, and the rest of the disk being for BTRFS. If you can actually get the driver to work for the firmware, this doesn't have to be FAT, but it will probably need to be carefully created.
2. Use GRUB to boot (trust me, you almost certainly want a real boot loader, most EFI boot managers are absolutely horrible, and having GRUB makes it easier to recover when something goes wrong).
3. Store everything but the bare minimum for GRUB to work on the BTRFS array, not the ESP.
4. During system shutdown, re-install all the files for GRUB on both ESP's, thus ensuring that you have a valid copy (not really needed if you manage to get the firmware working with a BTRFS ESP).

from efifs.

Thanks you for the answers.

@pbatard

Sorry for using this issue tracker for this topic but it seemed to be the best place.

Making it clear how these drivers work essentially the same way as Grub answered some possible questions.

I thought efibootmgr might be of general interest because I assumed the main purpose of these drivers was to make booting from these filesystems possible.

@Ferroin

Having two RAID-1 Btrfs filesystems (one on an ESP and one on the rest of the disks as a second partition) sounds like a nice compromise. (I keep forgetting GPT itself is duplicated on the disk and it's also check-summed, thus protected against random sector-level corruption, so it's not a liability like MBR.)

I always disliked partitions in general. I always seek a way to avoid them or prefer to use the absolute minimal number of them (might as well just use a single partition per disk). I think it's silly to chop the space up into discrete, static sized slices, unless it's explicitly desired for some good reason (much better reason than "just because" or "we always do that"). (The worst part is when you realize you could not predict the future [duh...] and you want to manipulate [resize/rearrange/etc] those partitions while keeping all the data in all the filesystems intact. -> Well, don't forget to cross your fingers and pray...!)

Surprise: I never really liked bootloaders either. :)
Sometimes they can help you recovering from small errors fasts and easily (like a kernel upgrade which didn't go as planned). But they are also a liability. For example, you can just as easily break the functionality of the bootloader during a system upgrade or configuration change as you would with the kernel (even if it's less likely in usual practice due to some other, likely factors) but you have one more thing to keep in mind and worry about. And they usually reside in disk space as "raw" (leftover gaps along partitions, in boot partitions withouth filesystems, or may be in "dumb" filesystems like FAT, so... it's usually far from ideal). Of course, the motherboard firmware can also break (or the whole hardware can burn down, etc) but still one less thing to worry about when you make changes or try to debug a problem if you don't have bootloader on disk(s).

Having that said about partitions, an ESP with Btrfs housing the bootloader/efistubkernel sounds better than putting it into "raw" space or into a FAT filesystem. That makes everything pretty solid in theory (including the configuration of the firmware boot option if you can give it a partition). The only "unstable magic" lays in the firmware modification (I plan to upgrade the motherboard soon, so I have no idea if the new one might cooperate and load modified code or not).

from efifs.

As far as GPT: The duplication and verification are actually part of why I use it on all my systems, not just EFI ones (it's possible to get it working reliably on BIOS based systems too)

As far as partitions: It's worth understanding the reasons why partitioning was done originally. One of the primary reasons was setting different flags on different filesystems (for example, having nodev on /usr, noexec on /var, mounting root read-only most of the time, etc). The other big reason is that fsck runs faster on smaller filesystems. For most people though, you need at most 4 partitions (/, /boot, /home, and swap), splitting /boot out makes sense for security reasons (keep it unmounted most of the time), and /home being split makes it easier to do a reinstall without losing data. Most systems I put together though have at most 3 (ESP/BIOS Boot Partition, /boot, and an LVM PV) on the boot disk, and I use LVM to let me split things out further and still allow for easy reconfiguration.

As far as bootloaders: The boot sectors can be removed as a point of failure by just installing to every disk in the system (on my home server, I have an ESP and boot partition on every drive in the system, and the firmware will let me boot from any arbitrary one, so I just have to keep them in sync manually, which is not hard since I only need to update once every few weeks at most). I also keep an EFI shell handy on every system I manage too, and in most cases, I can fix whatever issues arise with the bootloader from that.

from efifs.

The board accepted the modified firmware without any problems or extra workarounds and it could boot from a Btrfs ESP just fine. (I inserted it as a new one rather than overwriting the fat module.)

Although, the board does not want to automatically recognize and boot /efi/boot/bootx64.efi (even though UEFI boards usually recognize Windows bootloaders in that location, however the Windows default is usually partition 2) on SATA drives and efibootmgr can only add partition, not disks entries (trying to specify --part 0 or -part "" resulted in error and the default is 1 rather than [none]).

Partitions: Yeah, but just because something could be a valuable tool (in the right hands, for certain problems, in certain scenarios [...]) you should not universally force everyone to always carry around and use those tools like they are fundamentally essential and life on Earth could not exist without them.
ZFS wisely decided to try and "deprecate" the concept (even if the zpool command will often create partitions by default on certain platforms, the "dataset" concept is there) and Btrfs carried the good idea forward (and made it easy, even somewhat of a suggestion to really forget about partitions, unless you have a valid reason or explicitly wish to use them).

Bootloaders: redundant copies might make the recovery much easier but it's not so much of a help on headless machines which give you no remote control over their firmware. If the whole disk is "lost" that's "fine" but a slightly corrupted bootloader probably causes a crash which just hangs there indefinitely.

from efifs.