Public bug reported:
Since a few weeks update-grub was no longer detecting my root-on-zfs
install. This system does not follow the bpool/rpool logic as it got
installed a long time ago.
I was able to pinpoint the issue to this part of the 10_linux_zfs
script:
if [ -n "$(ls ${candidate_path} 2>/dev/null)" ]; then
echo "${candidate_path}"
return
fi
This code seems to identify candidate locations for /boot directories,
and expects them to be empty. ZFS does not require /boot to be empty to
mount the target boot dataset on it (overlay=on), but I assume this way
some other candidate paths can easily be skipped quickly.
So I think I basically ran into this issue:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1881442.
When grubenv gets created on the zfs root dataset during a failed boot
sequence, 10_linux_zfs will skip it from then on, leaving grub.cfg
without valid boot entries.
I was able to reproduce the issue by creating and removing /boot/grub on
my root dataset, and fix it by allowing the 10_linux_zfs script to
continue if only grub exists for candidate_path:
if [ -n "$(ls ${candidate_path} 2>/dev/null)" ] && [ "$(ls
${candidate_path} 2>/dev/null)" != "grub" ]; then
echo "${candidate_path}"
return
fi
Even when the grub-initrd-fallback.service bug gets addressed, I would
allow for /boot/grub to exist on the root dataset. If not, that bug
becomes quite critical so it seems.
** Affects: grub2 (Ubuntu)
Importance: Undecided
Status: New
** Tags: grub zfs
** Description changed:
Since a few weeks update-grub was no longer detecting my root-on-zfs
install. This system does not follow the bpool/rpool logic as it got
installed a long time ago.
I was able to pinpoint the issue to this part of the 10_linux_zfs
script:
- if [ -n "$(ls ${candidate_path} 2>/dev/null)" ]; then
- echo "${candidate_path}"
- return
- fi
+ if [ -n "$(ls ${candidate_path} 2>/dev/null)" ]; then
+ echo "${candidate_path}"
+ return
+ fi
This code seems to identify candidate locations for /boot directories,
and expects them to be empty. ZFS does not require /boot to be empty to
mount the target boot dataset on it (overlay=on), but I assume this way
some other candidate paths can easily be skipped quickly.
So I think I basically ran into this issue:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1881442.
When grubenv gets created on the zfs root dataset during a failed boot
sequence, 10_linux_zfs will skip it from then on, leaving grub.cfg
without valid boot entries.
I was able to reproduce the issue by creating and removing /boot/grub on
my root dataset, and fix it by allowing the 10_linux_zfs script to
continue if only grub exists for candidate_path:
- if [ -n "$(ls ${candidate_path} 2>/dev/null)" ] && [ "$(ls
${candidate_path} 2>/dev/null)" != "grub" ]; then
- echo "${candidate_path}"
- return
- fi
-
- Which fixes it for me.
+ if [ -n "$(ls ${candidate_path} 2>/dev/null)" ] && [ "$(ls
${candidate_path} 2>/dev/null)" != "grub" ]; then
+ echo "${candidate_path}"
+ return
+ fi
Even when the grub-initrd-fallback.service bug gets addressed, I would
allow for /boot/grub to exist on the root dataset. If not, that bug
becomes quite critical so it seems.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1918080
Title:
Suggested fix: 10_linux_zfs will not detect kernels if
/boot/grub/grubenv exists on the root dataset
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1918080/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
