Questions: - Does rpm-ostree keep an upgrade log of what it did during the upgrade? If so where is it? - Is there a config file to permit it to keep more than two trees at a time? - Is there a way to correlate ostree tree hashes and their release versions? The problem: I have a Fedora-Cloud_Atomic-x86_64-23.iso with a btrfs root and ext4 boot, in an otherwise conventional (flat, no subvolumes) layout. After today's 'rpm-ostree upgrade' the new tree isn't in the /boot/efi/EFI/fedora/grub.cfg. The old tree is still there, but the path to that old tree has changed so even trying to boot that old tree fails. I'm still in the middle of the autopsy but what appears to be the case: 1. The /boot/loader.0/grub.cfg contains the 23.29 and 23.34 trees. 2. This is a UEFI system which doesn't use that grub.cfg, it uses the one at /boot/efi/EFI/fedora/grub.cfg 3. That ESP grub.cfg wasn't updated, it's stale. I don't know why it wasn't updated. It contains the 23.29 and 23 tree entries, both of which look for ostree=/ostree/boot.1 4. The next problem is on rootfs there is no /ostree/boot.1, it's /ostree/boot.0 which is a symlink to /ostree/boot.0.1. And hence the double fail. So there are in effect two fails: A. The EFI System partition grub.cfg was not updated at all. B. The /ostree path changed in such a way that made it impossible for a stale grub.cfg to boot the old working tree that's still present. I think there's a bug here somewhere, even if it might be user induced (exposed) due to a non-standard installation. But off hand I can't figure out how the non-standard install may have affected this upgrade. The 23 to 23.29 upgrade worked, except for root=UUID= was wrong, and that's due to... skip that part right now. I think there's a bug if it's intended for the priot /ostree/boot* path to change in an upgrade. That seems fragile because if either that change or the grub.cfg change doesn't happen, then the rollback is going to fail too. I think that old (current prior to upgrade reboot) tree needs to stay the same no matter. Non-standard install gory details: "ostree+grub2 will not auto-regenerate root=UUID=" https://bugzilla.redhat.com/show_bug.cgi?id=1290296 Gist is, that bug has an easy work around, and doesn't involve the ostree= parameter or a changed /ostree/boot* path at all which is why I don't think it's related. But I'm still suspicious because, well otherwise other people would be affected by now and I wouldn't be the first one posting this problem. -- Chris Murphy _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx
