Ubuntu
grub2 package

10_linux_zfs: empty bootmenu if POSIXLY_CORRECT

Bug #1897785 reported by Jens Elkner on 2020-09-29

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	grub2 (Ubuntu)	Triaged	Low	Unassigned

Bug Description

If one has POSIXLY_CORRECT env var set (which is the case for all our admin/operator accounts) and one calls /usr/sbin/update-grub or grub-mkconfig ... it produces a /boot/grub/grub.cfg with a single entry 'UEFI Firmware Settings' (fwsetup). So the after a reboot the OS is not bootable anymore unless one is able to remember, which kernel exactly got installed (because Ubuntu does not link the kernel/ram image to generic names like vmlinuz , initrd) and which of the dozens of hds and partitions actually contain the kernel/ram image to boot.

The root cause for this is /etc/grub.d/10_linux_zfs and its mount usage:

Since Linux mount requires arguments given in a posixly incorrect "order", a script should always unset POSIXLY_CORRECT, when it is going to call mount. Otherwise mount errors out, and because the script has 'set -e', the script gets aborted immediately.

NOTE: 'zfs mount ...' also calls 'mount', so same requirement applies to 'zfs {mount|create} ...'

Env:
Distributor ID: Ubuntu
Description: Ubuntu 20.04.1 LTS
Release: 20.04
Codename: focal

Linux box 5.4.0-48-generic #52-Ubuntu SMP Thu Sep 10 10:58:49 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
with latest updates installed.

Revision history for this message

Julian Andres Klode (juliank) wrote on 2020-10-05:

I think I disagree here, scripts should not unset POSIXLY_CORRECT. Accounts should not set POSIXLY_CORRECT, it's going to wreak havoc in a lot of places. Having to accomodate for such unusual end user configurations in every shell scripts seems out of scope.

Changed in grub2 (Ubuntu):
importance:	Undecided → Low
status:	New → Triaged

Revision history for this message

Dimitri John Ledkov (xnox) wrote on 2020-10-05:

Want's zfs mount, fixed in https://github.com/openzfs/zfs/issues/4222 & https://github.com/openzfs/zfs/commit/d93b45aefc74b9c345ba3cdf3a227ee979a990cd ?

Is there anything missing in your description? Which calls to mount are wrong?

Revision history for this message

Dimitri John Ledkov (xnox) wrote on 2020-10-05:

Note it seems you may encounter incorrect behaviour when using mount.nfs sshfs too, because those too expect non-posixly argument order.

Revision history for this message

Julian Andres Klode (juliank) wrote on 2020-10-05:

Yeah, this seems to be up to the individual mount helpers to fix, hence like zfsutils package.

Revision history for this message

Jens Elkner (jelmd) wrote on 2020-10-05:

juliank: unset right before and restore after the call. It would not screw up anything. The user does not know, what the script does (and IIRC it didn't call zfs.mount in pre-focal versions). So the script has to take care of what it does.

xnox: I do not think, that this fixed the problem. Just export POSIXLY_CORRECT=1 and run a zfs create command - it will fail to mount the new fs for the same reason.

IIRC linux mount (used by zfs mount last time I digged the code) requires arguments to be in a non-posix compatible order. So ZFS can't do anything about it, except to unset POSIXLY_CORRECT or to rewrite the mount code to avoids the linux-mount invocation ...

Revision history for this message

Jens Elkner (jelmd) wrote on 2021-10-14:

FWIW: /usr/sbin/grub-probe is also posixly incorrect, e.g.:

# export POSIXLY_CORRECT=1
# /usr/sbin/grub-probe --device /dev/sda2 --target=partmap
/usr/sbin/grub-probe: error: cannot find a GRUB drive for /dev/sda2. Check your device.map.

# unset POSIXLY_CORRECT
# /usr/sbin/grub-probe --device /dev/sda2 --target=partmap
gpt

So e.g. if one has POSIXLY_CORRECT set, but not GRUB_TERMINAL (the default in /etc/default/grub), /etc/grub.d/00_header assumes gfxterm and therefore indirectly calls /usr/share/grub/grub-mkconfig_lib:prepare_grub_to_access_device() - which in turn fails, because it calls /usr/sbin/grub-probe w/o unsetting POSIXLY_CORRECT before. Since this aborts grub.cfg generation, a disaster recovery is needed on the next reboot if there is not already an old grub.cfg which is able to boot a kernel ...

If one sets GRUB_TERMINAL=console , mkconfig_lib:prepare_grub_to_access_device() doesn't get invoked and update-grub and in turn grub-mkconfig -o /boot/grub/grub.cfg generates a valid/usable config.

Revision history for this message

Julian Andres Klode (juliank) wrote on 2021-10-14:

Don't set that variable, then. Nobody tests that thing, so you can't reasonably expect it to just work.

Revision history for this message

Jens Elkner (jelmd) wrote on 2021-10-15:

So you suggest to break several hundred scripts written on/for standard conforming platforms (i.e. not only for Linux) within the last 30 years just because of bogus grub scripts? IMHO not a smart idea.