Description of problem: When a boot subvolume is mounted on /boot, bls_import fails to find /loader/entries. Version-Release number of selected component (if applicable): grub2-2.02-0.3.fc21.x86_64 How reproducible: Always Steps to Reproduce: 1. boot is a Btrfs subvolume and is mounted at /boot 2. http://rpm-ostree.cloud.fedoraproject.org/#/installation 3. bls_import Actual results: error: file '/loader/entries/' not found. Expected results: No error. Hit esc and the menu should now have ostree entries. Additional info: When I create a subvolume at the top level of the fs named loader, and create a directory entries in it, then cp the /boot/loader/entries contents to <FS_TREE>/loader/entries, then this works. So seems like $root is only the device "/loader/entries" is located on, not also the subvolume its located on.
See bug 1101359. I can't even tell where /loader is supposed to go, because neither GRUB2 nor OStree are exactly following the BootLoaderSpec. But if the idea is to use the BLS conf format only, and ignore it when it comes to where the conf files are located, I'd argue they should go in the same location no matter the firmware or file system. For Btrfs, a loader subvolume at the top level of the file system is consistent with how anaconda/blivet create subvolumes for root, var, and home already. And it can just be treated as a regular directory from that top level. If desired, an fstab entry for it could mount it at /boot/loader if that's the standard location OSTree would like to find it at.
To have /loader be a subvolume we'd need some special syntax for grub2 to tell it where to find it, right? What's the advantage of having just /loader being a subvolume over all of /boot ?
(In reply to Colin Walters from comment #2) > To have /loader be a subvolume we'd need some special syntax for > grub2 to tell it where to find it, right? No, it's just another directory as far as GRUB is concerned. Which is why I don't understand why ($ROOT) doesn't work on a Btrfs filesystem, it's simply not resolving /boot/ as the needed prefix. > What's the advantage of having just /loader being a subvolume over > all of /boot ? Good question, needs some qualification. The BLS suggests that it's important for /loader to always be at the root level of the file system, and maybe that's just not true. On Btrfs this could be done with either a subvolume or directory at the file system root. The advantage of it being a subvolume is it can be mounted at /boot/loader using an fstab entry with subvol=loader mount option, unlike a directory since on Fedora the top level of Btrfs volumes aren't mounted.
This is not a Btrfs problem. It's reproducible on a single partition formatted as XFS install as well. Steps to reproduce: 1. Install rawhide, custom partitioning, single partition/mountpoint at / only, formatted XFS. Reboot. 2. Follow install steps http://rpm-ostree.cloud.fedoraproject.org/#/installation 3. Reboot. 4. bls_import Result: error: file '/loader/entries/' not found. The issue is that bls_import is hardcoded on BIOS systems to look for /loader/entries at the root of the file system. It can't be in a /boot/ directory (or subvolume). So at present it can only support systems with a separate boot partition. Strictly speaking this is "not a bug" for GRUB because the BootLoaderSpec requires /loader to be at the root of the file system. So either: - BootLoaderSpec needs modifying, or - GRUB needs to be more tolerant than the spec (and look for additional /loader locations), or - OSTree needs to conditionally manage /boot on a separate partition or a directory, and put /loader in the expected location: /boot/loader on systems with separate boot partitions; or at /loader on systems without separate boot partitions. This is a BIOS variation of bug 1101359, could be seen as a duplicate.
It seems simplest to have GRUB look also for /loader if /boot=/.
Er, I mean /boot/loader.
Workaround is ln -s /boot/loader.1 /loader But then I run into bug 1100940. (In reply to Colin Walters from comment #5) > It seems simplest to have GRUB look also for /boot/loader Well, simplest would be to say ostree only supports separate /boot partition layouts right now. No code needed for that. Optionally put up a warning, optionally mark any bugs like this one as "notabug works as designed for now." Full support of arbitrary layouts is a rat's nest, that's why GRUB2 is practically an operating system. For what it's worth, anaconda and grub2 support arbitrarily named btrfs subvolumes mounted at /boot. So hard coding the additional path isn't a universal fix for this problem. I have boot subvolumes named boot, bootf20, and bootraw. So... that doesn't mean fix it for me, obviously I can make it work in most any case, but it's a matter of defining the scope; for whom will this work and not work? This logic is built into grub2-mkconfig. I wonder if there's a way to strip out some things, or filter its output, to "convert" grub2 grub.cfg's into bls conf files. The one thing I'd keep in the conversion that's not in bls conf files right now is allow a conf file to point to OS's (and their trees) on other devices from the .conf file. Right now bls conf only finds kernels relative to itself, i.e. on the same volume (which means for UEFI if the conf file goes on the ESP, the kernel and initramfs must be on the ESP too, which is just ... vinegar in my eye socket.)
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
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 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.