Bug 1100940
Summary: | conf contains incorrect paths when /boot is a directory or subvolume, instead of a separate partition | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chris Murphy <bugzilla> | ||||||||||
Component: | ostree | Assignee: | Colin Walters <walters> | ||||||||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||
Priority: | unspecified | ||||||||||||
Version: | 22 | CC: | ljozsa, walters | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | Unspecified | ||||||||||||
OS: | Unspecified | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2016-07-19 11:33:28 UTC | Type: | Bug | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Bug Depends On: | |||||||||||||
Bug Blocks: | 1147383 | ||||||||||||
Attachments: |
|
Description
Chris Murphy
2014-05-24 05:16:45 UTC
Created attachment 898839 [details]
grub boot error screenshot
Created attachment 898840 [details]
grub.cfg
Produced by grub2-mkconfig.
Created attachment 898841 [details]
ostree.conf
Created attachment 898842 [details]
ostree conf as it appears in grub edit window
After I saw this, I thought maybe this isn't an ostree bug but rather an import bug with grub2's blscfg.mod. It's adding ($root) prefix on import, and isn't handling the boot subvolume as part of $root. But I don't know whether grub is even aware of btrfs subvolumes. It's always treated them as directories. So I don't know whether this is an ostree or grub2 bug.
(In reply to Chris Murphy from comment #4) Starting with that edit window, if I replace ($root) with /boot for both linux and initrd lines, grub does find and load both the kernel and initramfs. So in any case there is a bug here, I just don't know if it's the creation of the conf file or the bls_import interpretation/execution of it. This is not a Btrfs subvolume problem. I can reproduce it with a single partition formatted XFS. First I run into bug 1100938 because GRUB can't find /boot/loader/entries; if I fix that with a symlink to point to /boot/loader.1, I still get this bug because the ostree generated conf file points to kernel + initramfs in /ostree/fedora-atomic-xxxx/ rather than /boot/ostree/fedora-atomic.... So I don't know what the blscfg.mod $root variable is supposed to do, if it should include a /boot/ directory if it exists or if it's just a device or what. Historically, grub2 and grub legacy conf files (on which BLS conf files are based) are directly responsible for using the full path name to the kernel. So on separate /boot partitions, the path name excludes /boot/, and on a unified file system where /boot is just a directory the path includes /boot/. So it seems like this is probably ostree's responsibility. There may be a hint for a way to do this automagically in grub2-mkconfig because somehow it manages to figure this out correctly, even for btrfs subvolumes (even for nested subvolumes); I'm gonna guess it looks at fstab for /boot and figures out from the subvol= line what the prefix ought to be for grub to find the kernel & initramfs; and then grub2-install must be doing this also because its core.img manages to find the grub.cfg even when it's buried in nested subvolumes. This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 Some changes to better support this landed in upstream OSTree should be in 2015.11 at least, worth retrying now. Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |