Description of problem: When installing silverblue on btrfs, the installed system has incorrect paths both in BLS entries and grub.cfg, making grub to not find the kernel and initramfs and fail booting. With manually correcting the paths the system boots, but any regenerating of BLS/grub.cfg will put back incorrect entries. These path are generated by `ostree admin instutil grub2-generate`. Version-Release number of selected component (if applicable): Rawhide 2020-07-31 How reproducible: Install silverblue with one of the following partition schemes (using advanced-custom with blivet, using UEFI and GPT partition scheme): sda1 vfat /boot/efi sda2 btrfs / subvolume boot /boot subvolume home /var/home OR: sda1 vfat /boot/efi sda2 btrfs (not-mounted) subvolume root / subvolume boot /boot subvolume home /var/home I.e. no separate boot partition with different filesystem, /boot is a btrfs subvolume. Actual results: After installation finished, the reboot fails. Manually correcting the kernel and initramfs paths will successfully boot the new installation. Expected results: Successful boot, withot manual intervention in grub. Additional info: These are scenarios #5 and #6 described in https://bugzilla.redhat.com/show_bug.cgi?id=1753485 Scenarios #3 and #4 might have the same problem, but currently they fail to install, so it cannot be tested. For that, separate bugreport will be created, will be linked from #1753485.
This is probably a dup of bug 1100940 and not btrfs specific.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
*** This bug has been marked as a duplicate of bug 1862784 ***
No, #1862783 and #1862784 are not duplicates. I've filled both of them, specifically because they are distinct bugs. #1862783 is (rpm?)-ostree failing to generate correct grub configuration, thus grub failing to boot the system. #1862784 is anaconda halting with fatal error when installing into btrfs without separate /boot partition or subvolume. As of Fedora-Silverblue-ostree-x86_64-Rawhide-20201011.n.0, both bugs are still present. So please reopen this bug, the underlying problem was not solved.
Maybe it was a mistake... However, I still think the underlying cause and solution of both bugs is https://github.com/ostreedev/ostree/pull/2149 mentioned in bug 1862784. And as it relates to this bug, I still expect only a subvolume literally named "boot" will work because in that case the bootloader's path is <btrfs top level>/boot the same as when it's mounted in an assembled file system (following startup). The problem arises when the linux environment path /boot is *not* the same as the bootloader's view when the subvolume mounted at /boot isn't named "boot". There has to be a mechanism designed and built to discover that name, and populate the bootloader configuration with the literal subvolume name, not the linux FHS mountpoint it later gets assigned to. The bootloader needs the true name of the subvolume to find it. No one has a design or plan for this yet, it's also not exactly trivial. See also https://bugzilla.redhat.com/show_bug.cgi?id=1862784#c16
Yes, https://github.com/ostreedev/ostree/pull/2149 *should* be the solution to this bug. Wrt. having specific precise naming for the /boot subvolume, I don't have any problem with this. The scenario where this might be a problem is dual/multi-booting several different releases or even distributions from the same btrfs volume; but that is not a problem I would go about solving today. I've just tried Fedora-Silverblue-ostree-x86_64-Rawhide-20201012.n.0; it does contain ostree-2020.06-4.fc34, which should have the PR above applied, and it still does not work correctly, the /boot/loader/entries/* and grub config are still missing the '/boot' part. In bug 1862784, I've shown where is the problem in anaconda. Maybe the biggest mistake was to comment on both bugs interchangeably, (or to comment this bug in bug 1862784, to be more precise) which led to perception that it is the same bug.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. 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 '33'. 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 33 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 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 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.