[zfs-discuss] ZFS Root - grub.cfg not updated on kernel updates

Garrett Fields ghfields at gmail.com
Tue Nov 27 15:36:59 EST 2018


Creating the symlink with the following didn't help you?

ln -sf
/dev/disk/by-id/ata-CT1000BX100SSD1_1504F0023DE2-part1
/dev/ata-CT1000BX100SSD1_1504F0023DE2-part1

What did grub-probe return following that command?

On Tue, Nov 27, 2018 at 3:11 PM Gordan Bobic via zfs-discuss <
zfs-discuss at list.zfsonlinux.org> wrote:

> I think it's the fact that the devices pool is created via in
> /dev/disk/by-id/* are not in /dev/ that is confusing grub2-mkconfig. Will
> try to manually create them next time I have a kernel update.
> Thanks for your help so far.
>
> On Tue, Nov 27, 2018 at 7:30 PM Gordan Bobic <gordan.bobic at gmail.com>
> wrote:
>
>> Tried that, and manually exported it in the session in which I ran yum
>> update. Still didn't update /boot/grub2/grub.cfg on non-UEFI CentOS 7. :-/
>>
>> On Tue, Nov 27, 2018 at 7:04 PM Uwe Sauter via zfs-discuss <
>> zfs-discuss at list.zfsonlinux.org> wrote:
>>
>>> I don't have much experience with Ubuntu and especially with the process
>>> updating grub.cfg after a kernel update but you
>>> could try putting ZPOOL_VDEV_NAME_PATH=1 int/etc/default/grub.
>>>
>>>
>>> Am 27.11.18 um 19:45 schrieb Gordan Bobic via zfs-discuss:
>>> > This fixed it for me on the non-UEFI machine:
>>> > ZPOOL_VDEV_NAME_PATH=1
>>> >
>>> > On my UEFI laptop, it worked without it. But updating the kernel still
>>> didn't add it to grub.cfg, even with the change
>>> > to 10_linux file you proposed. :-(
>>> >
>>> > On Tue, Nov 27, 2018 at 6:33 PM Garrett Fields <ghfields at gmail.com
>>> <mailto:ghfields at gmail.com>> wrote:
>>> >
>>> >     "grub2-probe: error: failed to get canonical path of
>>> `/dev/ata-CT1000BX100SSD1_1504F0023DE2-part1'."
>>> >
>>> >     Yea... in the past when running Ubuntu 14.04.  I ended up
>>> dirty-fixing it by running:
>>> >     ln -sf
>>> /dev/disk/by-id/ata-CT1000BX100SSD1_1504F0023DE2-part1 /dev/ata-CT1000BX100SSD1_1504F0023DE2-part1
>>> >     before any grub operations.  There probably is a better fix out
>>> there.  Problem went away when I jumped to 18.04.
>>> >
>>> >     Garrett
>>> >
>>> >     On Tue, Nov 27, 2018 at 10:08 AM Gordan Bobic via zfs-discuss <
>>> zfs-discuss at list.zfsonlinux.org
>>> >     <mailto:zfs-discuss at list.zfsonlinux.org>> wrote:
>>> >
>>> >         I changed the line in this section as you described:
>>> >
>>> >         case x"$GRUB_FS" in
>>> >              xbtrfs)
>>> >                  rootsubvol="`make_system_path_relative_to_its_root /`"
>>> >                  rootsubvol="${rootsubvol#/}"
>>> >                  if [ "x${rootsubvol}" != x ]; then
>>> >
>>> GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"
>>> >                  fi;;
>>> >              xzfs)
>>> >                  rpool=`zdb -l ${GRUB_DEVICE} | grep " name"| grep -o
>>> "'.*'"| sed "s/'//g" 2>/dev/null || true`
>>> >                  bootfs="`make_system_path_relative_to_its_root / |
>>> sed -e "s,@$,,"`"
>>> >                  LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs}"
>>> >                  ;;
>>> >         esac
>>> >
>>> >         Just did yum update to get the latest kernel, and it again
>>> didn't update grub2.cfg, I had to add it manually.
>>> >
>>> >         Are there any other changes required? Troubleshooting steps?
>>> >
>>> >         On Mon, Nov 26, 2018 at 12:03 AM Garrett Fields <
>>> ghfields at gmail.com <mailto:ghfields at gmail.com>> wrote:
>>> >
>>> >             Gordan,
>>> >             I've been tweaking a script that takes Ubuntu 18.04.1 live
>>> cd and creates a bootable encrypted rpool.  Work
>>> >             found at:
>>> https://gist.github.com/ghfields/92660bc9199fee6c78e34b6913531722
>>> >
>>> >             I'm not sure exactly where you current issue lies, but I
>>> was having a problem with grub identifying the pool
>>> >             name (eg. command line was boot=ZFS=/ROOT/ubuntu-1 instead
>>> of boot=ZFS=rpool/ROOT/ubuntu-1)
>>> >
>>> >             In /etc/grub.d/10_linux, I replaced
>>> >             ${grub_probe} --device ${GRUB_DEVICE} --target=fs_label
>>> >             with
>>> >             zdb -l ${GRUB_DEVICE} | grep " name"| grep -o "'.*'"| sed
>>> "s/'//g"
>>> >             with the following command:
>>> >             ======
>>> >             sed -i 's/.*fs_label*/\trpool=\`zdb -l ${GRUB_DEVICE} \|
>>> grep \" name\"\| grep -o \"\x27.*\x27\"\| sed
>>> >             \"s\/\x27\/\/g\"/' /rpool/ROOT/ubuntu-1/etc/grub.d/10_linux
>>> >             ======
>>> >
>>> >             It looks horrid, but works.
>>> >
>>> >             Does "grub-probe /" return "zfs"?  Where is your /boot
>>> located?
>>> >
>>> >
>>> >           /boot is on the rootfs on the same ZFS pool. Only non-ZFS
>>> partition is /boot/efi, which is FAT.
>>> >
>>> >
>>> >         _______________________________________________
>>> >         zfs-discuss mailing list
>>> >         zfs-discuss at list.zfsonlinux.org <mailto:
>>> zfs-discuss at list.zfsonlinux.org>
>>> >
>>> http://list.zfsonlinux.org/cgi-bin/mailman/listinfo/zfs-discuss
>>> >
>>> >
>>> > _______________________________________________
>>> > zfs-discuss mailing list
>>> > zfs-discuss at list.zfsonlinux.org
>>> > http://list.zfsonlinux.org/cgi-bin/mailman/listinfo/zfs-discuss
>>> >
>>> _______________________________________________
>>> zfs-discuss mailing list
>>> zfs-discuss at list.zfsonlinux.org
>>> http://list.zfsonlinux.org/cgi-bin/mailman/listinfo/zfs-discuss
>>>
>> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at list.zfsonlinux.org
> http://list.zfsonlinux.org/cgi-bin/mailman/listinfo/zfs-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20181127/268a293c/attachment.html>


More information about the zfs-discuss mailing list