RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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:
Embargoed:

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
View All

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.