Description of problem: When /boot is backed by a btrfs subvolume, ostree produces flawed .conf files. The paths lack any awareness that they are on a Btrfs subvolume, and therefore do not work. Version-Release number of selected component (if applicable): ostree-2014.4.23.gfc11c86-2.fc21.x86_64 How reproducible: Always Steps to Reproduce: 1. Btrfs subvolumes boot, root, var, home. 2. http://rpm-ostree.cloud.fedoraproject.org/#/installation 3. work around in bug 1100938 to get grub to find /loader/entries 4. Choose an os tree entry Actual results: See screen shot, but the vmlinuz is not found because it's looking in the wrong location. The conf file omits /boot/ in its path for both the kernel and initrd. Expected results: Ostree needs to be aware of btrfs subvolumes and correctly produce the conf file so the entries are usable. Additional info: grub2-install and grub2-mkconfig figure this all out correctly for some time. The core.img on this system uses prefix (hd0,gpt3)/boot/grub2/ where boot is a btrfs subvolume treated by grub as a directory. The grub2-mkconfig produce grub.cfg figures this out as well, using linux16 /boot/vmlinuz... initrd16 /boot/initramfs...
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
https://mail.gnome.org/archives/ostree-list/2015-July/msg00015.html
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.