Hide Forgot
Created attachment 1237795 [details] patches grubby to handle root=ZFS style parameters Description of problem: If you set up a system using the ZFS on linux repo and then update a kernel, grubby fails to copy the previous entry due to not handling root=ZFS style root parameters. Version-Release number of selected component (if applicable): grubby-8.28-18.el7.x86_64.rpm How reproducible: every time Steps to Reproduce: 1. set up system with ZFS root 2. run yum update including a new kernel 3. Actual results: new kernel is not added to grub.cfg Expected results: new kernel should get added correctly. Additional info: I've patched grubby to handle this. Patch is attached. On a related note - why is grubby even needed? Why doesn't a kernel update just use grub2-mkconfig again?
Bump
Please acknowledge this bug report. The patch is included and just needs acceptance.
Can someone please address this? It's been nearly 6 weeks since I submitted this and it has not even been acknowledged.
It's now been 11 weeks since I first reported this. Will this please be addressed? I've changed the severity to urgent in the hopes someone will at least respond to this.
I mirror this - if grubby is a must (and I'm not sure why it's necessary) then it should handle this. I've been running a post install scriptlet to trigger grub2-mkconfig for months because of this issue and it's such a small thing to fix.
Any update on this!?
Thanks for the patch, Rick. Much appreciated, this bug has been driving me nuts since forever. There is one thing that it doesn't address, and that is that it also requires a symlink: /ROOT/@ -> / otherwise grubby fails with: DBG: Image entry failed: access to /ROOT/@/boot/vmlinuz-3.10.0-957.el7.x86_64 failed "ROOT" is the name of the fs on the pool.
Additionally, it doesn't handle /boot being on ZFS. It adds the kernel/initrd path as /boot/... instead of /<fsname>@/boot. So this isn't a complete fix.
Just FYI, I'd be a little weary of putting /boot on ZFS because grub's zfs driver doesn't support the latest zfs file system features. Consequently, if you "update" the /boot zfs file system, grub will no longer be able to access the kernel and initramfs and the computer will fail to boot. I think this will always be a potential problem with grub's design -- the file system drivers will always have the possibility of being outdated by an upgrade in such a way that the system may be rendered unbootable after the user updates. A better approach, IMO, is to keep all the boot files, at least up to the initramfs, on a simple file system like vfat. After the initramfs takes over, the /real/ file system driver can take over and it will be guaranteed to work. If you want to mirror /boot. It is small enough that a simple startup script that runs rsync can do the job quite efficiently. My two cents.
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.