/etc/grub.d/10_linux_zfs doesn't skip non-linux zpools

[Benjamin Gentil]

# 1. Symptoms: `update-grub` fails when trying to access an os-release file

    root@x250:/home/benjamin# update-grub
    Sourcing file `/etc/default/grub'
    Sourcing file `/etc/default/grub.d/init-select.cfg'
    Generating grub configuration file ...
    /etc/grub.d/10_linux_zfs: 338: .: Can't open /tmp/zfsmnt.Ejuktn/etc/os-release
    done

# 2. Cause: 10_linux_zfs is trying to access /etc/os-release in all zpool, even when the system is not Linux based
    + machine_id=rpool/ROOT/openindiana
    + . /tmp/zfsmnt.AC9sAy/etc/os-release
    /etc/grub.d/10_linux_zfs: 339: .: Can't open /tmp/zfsmnt.AC9sAy/etc/os-release
    + pretty_name=
    + boot_list=\n
    + boot_list=
    + on_exit
    + zpool export rpool
    + mountpoint -q /tmp/zfsmnt.AC9sAy
    + true
    + rmdir /tmp/zfsmnt.AC9sAy
    + rm -rf /tmp/zfstmp.lEMWy3
    + exit 0
    done

# 3. Quick fix (for /etc/os-release)

    in /etc/grub.d/10_linux_zfs:321, replace:
        if [ -z "${etc_dir}" ]; then
    by:
        if [ -z "${etc_dir}" ] || [ ! -f "${etc_dir}/os-release" ]; then

    then when the file is not found, the zpool is skipped
        root@x250:/home/benjamin# update-grub
        Sourcing file `/etc/default/grub'
        Sourcing file `/etc/default/grub.d/init-select.cfg'
        Generating grub configuration file ...
        Warning: Ignoring rpool/ROOT/openindiana
        Warning: Ignoring rpool/ROOT/openindiana-1
        Warning: Ignoring rpool/ROOT/openindiana-1@install
        Warning: Ignoring rpool/ROOT/openindiana-1@2018-08-24-23:15:22
        Found linux image: vmlinuz-5.0.0-32-generic in x250/ROOT/ubuntu
        Found initrd image: initrd.img-5.0.0-32-generic in x250/ROOT/ubuntu
        Found linux image: vmlinuz-5.3.0-19-generic in x250/ROOT/ubuntu
        Found initrd image: initrd.img-5.3.0-19-generic in x250/ROOT/ubuntu
        Found linux image: vmlinuz-5.0.0-32-generic in x250/ROOT/ubuntu@install
        Found initrd image: initrd.img-5.0.0-32-generic in x250/ROOT/ubuntu@install
        Found linux image: vmlinuz-5.3.0-19-generic in x250/ROOT/ubuntu@install
        Found initrd image: initrd.img-5.3.0-19-generic in x250/ROOT/ubuntu@install
        done

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: grub-common 2.04-1ubuntu12
ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
Uname: Linux 5.3.0-19-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu8
Architecture: amd64
CurrentDesktop: XFCE
Date: Sun Oct 27 00:30:31 2019
SourcePackage: grub2
UpgradeStatus: Upgraded to eoan on 2019-10-26 (0 days ago)
modified.conffile..etc.grub.d.10_linux_zfs: [modified]
mtime.conffile..etc.grub.d.10_linux_zfs: 2019-10-27T00:09:53.228144

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Lee (basicinc)]

This bug affects me too, but the 'quick fix' suggested doesn't work either for some reason.

I tried lots of ways to work around this by modifying the 10_linux_zfs file, but they all failed. I don't have the coding skills apparently!

I could do with a fix for this as I'm relying on it to rebuild an OS which was broken by updates, so at the moment my zpool is only accessible booting from a flash drive; which is more than inconvenient.

Regards,

[Kyle Ambroff-Kao (ambroff)]

I ran into this issue too after setting up dual boot with FreeBSD on my system. An unattended upgrade wiped out my grub menu since it mistook the "etc" dataset in the FreeBSD zfs pool as a signal that it contained an Ubuntu install.

The hack described by Benjamin worked for me, although it definitely doesn't seem like a very sound solution.

```
ubuntu@ubuntu:~$ diff -u /etc/grub.d/10_linux_zfs /mnt/etc/grub.d/10_linux_zfs
--- /etc/grub.d/10_linux_zfs 2020-09-08 10:24:35.000000000 +0000
+++ /mnt/etc/grub.d/10_linux_zfs 2020-10-13 00:10:59.644606544 +0000
@@ -383,7 +384,8 @@
     # read machine-id/os-release from /etc
     etc_dir=$(get_system_directory "${dataset}" "etc" "true" "${mntdir}" "")
- if [ -z "${etc_dir}" ]; then
+ # KWA: Temporary hack from https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1850003
+ if [ -z "${etc_dir}" ] || [ ! -f "${etc_dir}/os-release" ]; then
         grub_warn "Ignoring ${dataset}"
         mountpoint -q "${mntdir}/etc" && umount "${mntdir}/etc" || true
         umount "${mntdir}"
```

Rather than inspecting the contents of the dataset, it might be better to just set a property on the dataset tagging it as part of an Ubuntu install. I'm not sure at the moment whether it's possible to just set arbitrary custom properties on a dataset.

[Kyle Ambroff-Kao (ambroff)]

I had time to revisit this. I think the user property thing is the way to go. The installer would just mark the entire pool as a pool that is considered bootable.

kyle@optional:~$ zfs get zsys:bootable rpool
NAME PROPERTY VALUE SOURCE
rpool zsys:bootable - -
kyle@optional:~$ sudo zfs set zsys:bootable=YES rpool
[sudo] password for kyle:
kyle@optional:~$ zfs get zsys:bootable rpool
NAME PROPERTY VALUE SOURCE
rpool zsys:bootable YES local
kyle@optional:~$

So then the grub update script could just check for that property instead of looking for a child dataset that matches some expectation.