Wrong bootloader name after update from older deployment

[alice-mkh]

Fedora 28 Atomic Workstation, x86_64, EFI bootloader

 ~  rpm-ostree status
State: idle; auto updates disabled
Deployments:
● ostree://fedora-workstation:fedora/28/x86_64/workstation
                   Version:  (2018-04-19 12:28:36)
                BaseCommit: 150e7e6b93bc9e6584d581de74a34252911e1fb0ec838afbfb823d85d74441ef
              GPGSignature: Valid signature by 128CF232A9371991C8A65695E08E7E629DB62FB1
      ReplacedBasePackages: xkeyboard-config 2.23.1-1.fc28 -> 2.23.1-1.fc28_mod
           LayeredPackages: foo2zjs gedit-plugin-drawspaces gnome-music gnome-tweaks mc
                            mesa-libEGL p7zip thunderbird tilix zsh

  ostree://fedora-workstation:fedora/28/x86_64/workstation
                   Version: 19:25)
                BaseCommit: 5344360af3807647a728366dc59ef23aa5100b4b83013316e0f1c9c9d0031103
              GPGSignature: Valid signature by 128CF232A9371991C8A65695E08E7E629DB62FB1
      ReplacedBasePackages: xkeyboard-config 2.23.1-1.fc28 -> 2.23.1-1.fc28_mod
           LayeredPackages: foo2zjs gedit-plugin-drawspaces gnome-music gnome-tweaks mc
                            p7zip thunderbird tilix zsh

I had 28.20180415.n.0 and 28.20180417.n.0 deployments, the latter with layered mesa-libGL and mesa-libEGL packages. I've rebooted into 28.20180415.n.0, did

sudo rpm-ostree uninstall mesa-libGL mesa-libEGL
sudo rpm-ostree upgrade
sudo rpm-ostree install mesa-libEGL

Then rebooted. The newer bootloader entry is still called 28.20180417.n.0, but it loads the new 28.20180419.n.0 deployment correctly.

 ~  sudo ls /boot/loader/entries 
ostree-fedora-workstation-0.conf  ostree-fedora-workstation-1.conf
 ~  sudo cat /boot/loader/entries/ostree-fedora-workstation-0.conf
initrd /ostree/fedora-workstation-cc0d635631eccc1c70919a01208dc16e6b8659d6108cfa8c14b9caa53947ff50/initramfs-4.16.2-300.fc28.x86_64.img
options resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet root=/dev/mapper/fedora-root ostree=/ostree/boot.1/fedora-workstation/cc0d635631eccc1c70919a01208dc16e6b8659d6108cfa8c14b9caa53947ff50/0
title Fedora 28 (Workstation Edition) 28.20180417.n.0 (ostree)
linux /ostree/fedora-workstation-cc0d635631eccc1c70919a01208dc16e6b8659d6108cfa8c14b9caa53947ff50/vmlinuz-4.16.2-300.fc28.x86_64
version 2
 ~  sudo cat /boot/loader/entries/ostree-fedora-workstation-1.conf
initrd /ostree/fedora-workstation-478c5460ce2845609b1d5d2c881ca74eedb327414aa89f38e97d164282143d8c/initramfs-4.16.1-300.fc28.x86_64.img
options resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet root=/dev/mapper/fedora-root ostree=/ostree/boot.1/fedora-workstation/478c5460ce2845609b1d5d2c881ca74eedb327414aa89f38e97d164282143d8c/0
title Fedora 28 (Workstation Edition) 28.20180415.n.0 (ostree)
linux /ostree/fedora-workstation-478c5460ce2845609b1d5d2c881ca74eedb327414aa89f38e97d164282143d8c/vmlinuz-4.16.1-300.fc28.x86_64
version 1

[cgwalters]

My initial worry is that this was some sort of core issue with say the grub rework that partially landed in f28, but I'm not immediately reproducing an issue like this in some local testing at least with FAH.

(Random aside, you don't need to use sudo anymore for workstation by default)

How reproducible is this? If you e.g. rpm-ostree cleanup -pr, and redo those steps does it still happen?

[alice-mkh]

Ok. Redoing the steps after rpm-ostree cleanup -pr from 28.20180415.n.0 deployment.
I couldn't uninstall mesa-libGL or mesa-libEGL, since they are in the base image on this deployment, so both packages are in the updated image as well, so I can't really reproduce this anymore.
After rpm-ostree upgrade the name is correct: 28.20180420.n.0.

I suppose it only happens after updating (without cleanup) and then installing/uninstalling something.

[jlebon]

Thanks for filing this! I've definitely hit it myself before, but never bothered to look deeper into it. This is actually a libostree issue; I submitted a patch: ostreedev/ostree#1556. Though I think it's fine leaving the issue here.