Failed to check file system type of "/boot": No such file or directory

[Rotsor]

I tried running this on Ubuntu 15.10.

This was the error message, looks like it came from the last step in nixos-install.
Now, perhaps I was doomed because I think my system boots using uefi, but the error message would seem to suggest a simple bug or a missing sanity check somewhere. What is responsible for ensuring /boot exists?

finalising the installation...
Failed to check file system type of "/boot": No such file or directory
Traceback (most recent call last):
  File "/nix/store/w3kckp1k7hngiadrcllybnji9nc8di25-systemd-boot-builder.py", line 102, in <module>
    subprocess.check_call(["/nix/store/mnbl0f66cykmwjin47r7rlnwwgiac7ys-systemd-231/bin/bootctl", "--path=/boot", "install"])
  File "/nix/store/ignn33dyacf5vm5hsmwiaj617226x1js-python-2.7.12/lib/python2.7/subprocess.py", line 541, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/nix/store/mnbl0f66cykmwjin47r7rlnwwgiac7ys-systemd-231/bin/bootctl', '--path=/boot', 'install']' returned non-zero exit status 1

[Rotsor]

I made the bootctl command succeed by doing the following immediately after the failing nixos-install:

Outside of chroot:

# mount my uefi system volume (which happened to be already mounted
# to /boot/efi) so it's available in the chroot; /nixos is not a good place for it,
# but it works
mount --bind /boot/efi /nixos/boot-efi

Inside the chroot:

mount -t efivarfs efivarfs /sys/firmware/efi/efivars
# note the different value of --path
/nix/store/mnbl0f66cykmwjin47r7rlnwwgiac7ys-systemd-231/bin/bootctl --path=/nixos/boot-efi install

... which installed systemd boot fine, but I still don't have the nixos entry there. Looking...

[Rotsor]

There was no nixos entry because nixos-install ended up writing uefi stuff to /boot, which was not mounted. I should have mounted my /boot/efi to /boot in the chroot.

[jeaye]

Hey, thanks for looking into this! There hasn't been any uefi support added yet, but it sounds like you've actually made it pretty far. If you feel like adding what you've found to a flag on the script, to enable this, I'd be happy to see the PR.

[Rotsor]

Yeah, I'll think about how to package this up in a way that's not too specific to my system and then get back to you.

[Rotsor]

efi_loader_get_device_part_uuid function in https://github.com/systemd/systemd/blob/master/src/shared/efivars.c is how to discover what partition is the EFI System Partition.
My plan is to re-implement this logic in bash. Please tell me if that sounds crazy.

[jeaye]

Sounds pretty crazy. I'd be sure to check for existing solutions thoroughly first, even if it means using a Python library or something. The less code we need to maintain, the better.

With that said, I don't know much about EFI, which is why it was never implemented to begin with.

[Rotsor]

It's not too complicated if you assume existence of a few standard unix tools (C is pretty verbose and we don't need to be as general):

esp_device="/dev/disk/by-partuuid/$(cat /sys/firmware/efi/efivars/LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f | tail -c +5 | head -c -1 | iconv --from-code=UTF16 | tr '[:upper:]' '[:lower:]')"

That said, I agree we should start with a simpler version.

[jeaye]

That doesn't seem too bad at all.

[Rotsor]

I was wrong: I thought that variable gets populated by bios, but apparently it's systemd-boot that populates it, which means that the system might not have that variable populated. In #32 I implemented an alternative, less robust way of discovering the EFI System Partition using fdisk.

[jeaye]

I would merge the other PR immediately and hang onto this one until I can get a test added to the suite for it. Thanks for your work!