Created attachment 1190329 [details] picture Description of problem: The default item of boot menu is upgraded layer after imgbase rollback Version-Release number of selected component (if applicable): redhat-virtualization-host-4.0-20160811.0.x86_64 imgbased-0.8.4-1.el7ev.noarch cockpit-ws-0.114-2.el7.x86_64 cockpit-ovirt-dashboard-0.10.6-1.3.6.el7ev.noarch How reproducible: 100% Steps to Reproduce: 1. Install RHVH with old version (rhvh-4.0-0.20160727.0) 2. Upgrade it to the latest version (rhvh-4.0-0.20160811.0) 3. Login with root account, check the result [root@cshao740 ~]# imgbase layout rhvh-4.0-0.20160727.0 +- rhvh-4.0-0.20160727.0+1 rhvh-4.0-0.20160811.0 +- rhvh-4.0-0.20160811.0+1 [root@cshao740 ~]# imgbase w [INFO] You are on rhvh-4.0-0.20160811.0+1 4. Input "imgbase rollback" command 5. Reboot node, check the boot menu Actual results: The default item of boot menu is upgraded layer( rhvh-4.0-0.20160811.0) after imgbase rollback Expected results: The default item of boot menu should be the original layer( rhvh-4.0-0.20160727.0) after imgbase rollback Additional info:
Created attachment 1190330 [details] log files
update: imgbase rollback -> nodectl rollback
This is not reproducible on EFI. The cause seems to be that /boot/grub2/grubenv is a symlink to /boot/efi/EFI/.../grubenv even on legacy systems. I'm investigating the right place for a fix.
*** Bug 1393626 has been marked as a duplicate of this bug. ***
Please put the workaround for grub in a comment here
(In reply to Sandro Bonazzola from comment #5) > Please put the workaround for grub in a comment here The workaround is use --bad-image-okay in the grubby. As we don't have the resolution in bz#1323842 and have a workaround for this one, moving to POST.
Please verify this. grubby --bad-image-okay correctly updates grubenv, but grub2 still doesn't honor it (and load_env fails to find grubenv). grubby returns a successful result, but grub2 will still boot into the newest image. I just tested this, and it still seems to fail, even with --bad-image-okay.
Note that, as comment#3, this works as expected on EFI installations, but fails on legacy/mbr boot.
The only workaround I know for this is the following: # If not an EFI system mv /boot/efi/EFI/${distro}/grubenv /boot/grub2 Or: # This is a symlink -- grubby will recreate it in the correct # location if removed on MBR systems, wrong location on EFI systems rm /boot/grub2/grubenv We could detect the presence of efivars in nodectl and take the appropriate action (leave grubenv in place if it's EFI, remove it if it's mbr and grubenv is a symlink), but this is extremely hacky.
Looks like, I wrote too quickly. I remembered we talked about it and thought that patch had the full workaround. (In reply to Ryan Barry from comment #9) > The only workaround I know for this is the following: > > # If not an EFI system > mv /boot/efi/EFI/${distro}/grubenv /boot/grub2 > > Or: > > # This is a symlink -- grubby will recreate it in the correct > # location if removed on MBR systems, wrong location on EFI systems > rm /boot/grub2/grubenv > Just re-tested and worked here: # grubby --set-default=/boot/vmlinuz-VERSION-HERE # cp /boot/efi/EFI/${distro}/grubenv /boot/grub2 > We could detect the presence of efivars in nodectl and take the appropriate > action (leave grubenv in place if it's EFI, remove it if it's mbr and > grubenv is a symlink), but this is extremely hacky. +1, would be nice to have such feature out of box.
I'm working on a high-priority z-stream. Can you please test a patch? We shouldn't need to copy -- grubenv is just enough '#' characters to make 1024 bytes out of the box, and grubby creates it correctly. Something like: if not os.path.isfile("/proc/efi/vars") and os.path.islink("/boot/grub2/grubenv"): # remove grubenv # then invoke Bootloader.()...
(In reply to Ryan Barry from comment #11) > I'm working on a high-priority z-stream. Can you please test a patch? > > We shouldn't need to copy -- grubenv is just enough '#' characters to make > 1024 bytes out of the box, and grubby creates it correctly. > > Something like: > > if not os.path.isfile("/proc/efi/vars") and > os.path.islink("/boot/grub2/grubenv"): > # remove grubenv > # then invoke Bootloader.()... Thanks Ryan, as we talked, would be better if platform fix the issue but here the workaround: https://gerrit.ovirt.org/#/c/71547/1 As reference only: For EFI tests, I have setup in virtual machine with UEFI bios, steps here: https://fedoraproject.org/wiki/Using_UEFI_with_QEMU
(In reply to Douglas Schilling Landgraf from comment #12) > (In reply to Ryan Barry from comment #11) > > I'm working on a high-priority z-stream. Can you please test a patch? > > > > We shouldn't need to copy -- grubenv is just enough '#' characters to make > > 1024 bytes out of the box, and grubby creates it correctly. > > > > Something like: > > > > if not os.path.isfile("/proc/efi/vars") and > > os.path.islink("/boot/grub2/grubenv"): > > # remove grubenv > > # then invoke Bootloader.()... > > Thanks Ryan, as we talked, would be better if platform fix the issue but > here the workaround: https://gerrit.ovirt.org/#/c/71547/1 Can you open a BZ on platform about this and reference it here? > As reference only: > For EFI tests, I have setup in virtual machine with UEFI bios, steps here: > https://fedoraproject.org/wiki/Using_UEFI_with_QEMU Can you please ensure we have this is documented in ovirt.org website in the page where we provide info about contributing to Node project?
> Can you open a BZ on platform about this and reference it here? This is already referenced as a dependency: rhbz#1366785
> > > As reference only: > > For EFI tests, I have setup in virtual machine with UEFI bios, steps here: > > https://fedoraproject.org/wiki/Using_UEFI_with_QEMU > > Can you please ensure we have this is documented in ovirt.org website in the > page where we provide info about contributing to Node project? https://github.com/oVirt/ovirt-site/pull/769
Test version: redhat-virtualization-host-4.1-20170309.0 cockpit-ovirt-dashboard-0.10.6-1.4.0.el7ev.noarch cockpit-ws-0.114-2.el7.x86_64 imgbased-0.8.5-0.1.el7ev.noarch Test steps: 1. Install RHVH with old version (rhvh-4.0-0.20160919.0) 2. Upgrade it to the latest version (rhvh-4.1-0.20170309.0) 3. Login with root account, check the result [root@dhcp-10-16 ~]# imgbase layout rhvh-4.0-0.20160919.0 +- rhvh-4.0-0.20160919.0+1 rhvh-4.1-0.20170309.0 +- rhvh-4.1-0.20170309.0+1 [root@dhcp-10-16 ~]# imgbase w [INFO] You are on rhvh-4.1-0.20170309.0+1 4. Input "imgbase rollback" command 5. Reboot node, check the boot menu Result: The default item of boot menu is the right one rhvh-4.0-0.20160919.0+1 The bug is fixed, change the status to VERIFIED.