Bug 1410591 - grubby does not handle root=ZFS
Summary: grubby does not handle root=ZFS
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: grubby
Version: 7.3
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: rc
: ---
Assignee: Javier Martinez Canillas
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-05 20:14 UTC by Rick Warner
Modified: 2021-01-15 07:29 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-01-15 07:29:53 UTC
Target Upstream Version:


Attachments (Terms of Use)
patches grubby to handle root=ZFS style parameters (534 bytes, patch)
2017-01-05 20:14 UTC, Rick Warner
no flags Details | Diff

Description Rick Warner 2017-01-05 20:14:20 UTC
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?

Comment 2 Rick Warner 2017-01-13 23:47:04 UTC
Bump

Comment 3 Rick Warner 2017-01-23 18:24:47 UTC
Please acknowledge this bug report.  The patch is included and just needs acceptance.

Comment 4 Rick Warner 2017-02-14 15:58:26 UTC
Can someone please address this?  It's been nearly 6 weeks since I submitted this and it has not even been acknowledged.

Comment 5 Rick Warner 2017-03-23 15:57:54 UTC
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.

Comment 6 Dominic Robinson 2017-07-19 21:19:58 UTC
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.

Comment 7 Dominic Robinson 2018-01-03 19:36:41 UTC
Any update on this!?

Comment 8 Gordan Bobic 2018-12-09 21:14:49 UTC
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.

Comment 9 Gordan Bobic 2018-12-11 10:38:22 UTC
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.

Comment 10 Gregory Lee Bartholomew 2020-01-27 18:05:54 UTC
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.

Comment 12 RHEL Program Management 2021-01-15 07:29:53 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.