After installing one update, I got four options in the bootloader - two with pin 0 and two with pin 1. Why I got two lines in bootloader if only one update is installed?
The documentation on rpm-ostree says that I can use the rpm-ostree cleanup command, but before I need to detach the pins from the deployment, what i want to delete. How?
I was grateful for the explanation of what 2 loader entries mean (after installing one update) and how I can to remove old deployments.
I also see the same thing. I haven’t been able to figure it out. I know for me the bottom 2 options don’t work (fails to boot), only the top 2 will boot.
Okay, so I may have figured it out, but I’m not sure if the fix is the correct way to deal with this.
I looked at /boot/loader/grub.cfg and noticed that the entries for the last 2 options (3 for me, since I have 1 manually pinned deployment) were listed under the section called “15_ostree”:
### BEGIN /etc/grub.d/15_ostree ###
menuentry 'Fedora Linux 35.20211019.n.0 (Kinoite) (ostree:0)' --class gnu-linux --class gnu --class os --unrestricted 'ostree-0-7e43d023-b728-420d-9dfa-ec0498cbef2d' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 7e43d023-b728-420d-9dfa-ec0498cbef2d
linux16 /ostree/fedora-a9bebaa1458b6218288a64b67b53546131ab5334b6d6abaccc99dbd11dab9174/vmlinuz-5.14.10-300.fc35.x86_64 rhgb quiet root=UUID=c9abf553-35aa-4590-b0d0-de337c28bddd rootflags=subvol=root ostree=/ostree/boot.0/fedora/a9bebaa1458b6218288a64b67b53546131ab5334b6d6abaccc99dbd11dab9174/0
initrd16 /ostree/fedora-a9bebaa1458b6218288a64b67b53546131ab5334b6d6abaccc99dbd11dab9174/initramfs-5.14.10-300.fc35.x86_64.img
}
menuentry 'Fedora Linux 35.20211018.n.0 (Kinoite) (ostree:1)' --class gnu-linux --class gnu --class os --unrestricted 'ostree-1-7e43d023-b728-420d-9dfa-ec0498cbef2d' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 7e43d023-b728-420d-9dfa-ec0498cbef2d
linux16 /ostree/fedora-29d242eebdca913252b7f1d79c158849a483c586cf2c044df13b92b2e4fd57b2/vmlinuz-5.14.10-300.fc35.x86_64 rhgb quiet root=UUID=c9abf553-35aa-4590-b0d0-de337c28bddd rootflags=subvol=root ostree=/ostree/boot.0/fedora/29d242eebdca913252b7f1d79c158849a483c586cf2c044df13b92b2e4fd57b2/0
initrd16 /ostree/fedora-29d242eebdca913252b7f1d79c158849a483c586cf2c044df13b92b2e4fd57b2/initramfs-5.14.10-300.fc35.x86_64.img
}
menuentry 'Fedora 34.20210917.0 (Silverblue) (ostree:2)' --class gnu-linux --class gnu --class os --unrestricted 'ostree-2-7e43d023-b728-420d-9dfa-ec0498cbef2d' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 7e43d023-b728-420d-9dfa-ec0498cbef2d
linux16 /ostree/fedora-d9c5adc097c82b39b6b0592fd140785586c8d56d2b099c4642c7753276880ea3/vmlinuz-5.13.16-200.fc34.x86_64 rhgb quiet root=UUID=c9abf553-35aa-4590-b0d0-de337c28bddd rootflags=subvol=root ostree=/ostree/boot.0/fedora/d9c5adc097c82b39b6b0592fd140785586c8d56d2b099c4642c7753276880ea3/0
initrd16 /ostree/fedora-d9c5adc097c82b39b6b0592fd140785586c8d56d2b099c4642c7753276880ea3/initramfs-5.13.16-200.fc34.x86_64.img
}
### END /etc/grub.d/15_ostree ###
So looking I looked into /etc/grub.d/15_ostree, and figured this was inserting the grub entries for some reason. In there I found this:
# Gracefully exit if the grub2 configuration has BLS enabled,
# and the installed version has support for the blscfg module.
# Since there is no need to create menu entries for that case.
# See: https://src.fedoraproject.org/rpms/grub2/c/7c2bab5e98d
. /etc/default/grub
if test -f /boot/grub2/.grub2-blscfg-supported && \
test "${GRUB_ENABLE_BLSCFG}" = "true"; then
exit 0
fi
I see in /etc/defaults/grub, that $GRUB_ENABLE_BLSCFG=true is set. However, there isn’t a corresponding hidden file that the script above is looking for.
tldr;
So I just did a # touch /boot/grub2/.grub2-blscfg-supported followed by # grub2-mkconfig -o /boot/loader/grub.cfg
I don’t know if that’s the correct way to handle this, but the end result is that those broken menu items are gone.
I executed today the rpm-ostree cleanup --rollback command.
My previous deployments by this operation were deleted, 1.7 GB were released. At the same time, there are still two identical items in the menu. I checked - both of them work the same way.
That entry in 15_ostree is the second record. It shouldn’t be there - it should be a blank section. The actual boot entry should be populated by section 10_linux using the blscfg command. 15_ostree should not be populated if blscfg works. For some reason the logic to put the invisible file .grub2-blscfg-supported file didn’t trigger and thus 15_ostree was also populating the grub menu.
First make sure to see if the following file exists: /run/ostree-booted and that the following directory exists: /sys/firmware/efi/efivars/
If those two things exist, then execute both the following with sudo:
touch /boot/grub2/.grub2-blscfg-supported followed by grub2-mkconfig -o /boot/loader/grub.cfg
After that, you can check your grub.cfg and you should see that the 15_ostree section is now empty.
The /sys/firmware/efi/efivars/ directory does not exist and the reason is clear here - I am using an old computer that contains an old BIOS and does not support UEFI at all. This is also probably the reason for the юgrub-blscfg-supported file placement error and the bootloader entries getting into 15_ ostree.
Artificially create a directory /sys/firmware/efi/efivars/ and its contents probably makes no sense.
Somewhere you can read about the structure of grub.cfg in Fedora Silverblue?
You can pin deployments manually using the command ostree admin pin <#>, where the <#> is the 0-indexed number of the deployment (i.e. - run rpm-ostree status, and the first listed deployment would be 0, the next one down is 1, and so on).
To unpin a deployment, run ostree admin pin --unpin <#>. You’ll need sudo to run ostree commands.
You can check if a deployment is pinned using rpm-ostree status, there should be a “Pinned” indicator:
