Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1366549 - imgbase rollback does not result in a rollback (no default boot entry change)
Summary: imgbase rollback does not result in a rollback (no default boot entry change)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-node
Classification: oVirt
Component: UI
Version: 4.0
Hardware: Unspecified
OS: Unspecified
medium
high vote
Target Milestone: ovirt-4.1.1
: 4.1
Assignee: Douglas Schilling Landgraf
QA Contact: Wei Wang
URL:
Whiteboard:
: 1393626 (view as bug list)
Depends On: 1323842 1366785
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-12 09:51 UTC by Wei Wang
Modified: 2017-04-21 09:45 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Previously, users with MBR boot system were unable to rollback images by imagebase rollback command. Consequence: After imgbase rollback the users kept booting the same image. Fix: For MBR system, for a regeneration of grubenv file. Result: Now users with MBR system are able to rollback.
Clone Of:
Environment:
Last Closed: 2017-04-21 09:45:38 UTC
oVirt Team: Node
rbarry: needinfo-
rule-engine: ovirt-4.1+
mgoldboi: planning_ack+
fdeutsch: devel_ack+
cshao: testing_ack+


Attachments (Terms of Use)
picture (deleted)
2016-08-12 09:51 UTC, Wei Wang
no flags Details
log files (deleted)
2016-08-12 09:52 UTC, Wei Wang
no flags Details


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 60053 None None None 2017-01-31 21:20:12 UTC
oVirt gerrit 71547 master MERGED bootloader: workaround for grubby --set-default 2017-02-04 04:27:32 UTC
oVirt gerrit 71643 ovirt-4.1 MERGED bootloader: workaround for grubby --set-default 2017-02-04 05:52:42 UTC

Description Wei Wang 2016-08-12 09:51:08 UTC
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:

Comment 1 Wei Wang 2016-08-12 09:52:31 UTC
Created attachment 1190330 [details]
log files

Comment 2 Wei Wang 2016-08-12 09:55:28 UTC
update: imgbase rollback -> nodectl rollback

Comment 3 Ryan Barry 2016-08-12 19:04:16 UTC
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.

Comment 4 Fabian Deutsch 2016-11-10 02:32:47 UTC
*** Bug 1393626 has been marked as a duplicate of this bug. ***

Comment 5 Sandro Bonazzola 2017-01-17 09:42:01 UTC
Please put the workaround for grub in a comment here

Comment 6 Douglas Schilling Landgraf 2017-01-31 21:20:12 UTC
(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.

Comment 7 Ryan Barry 2017-01-31 22:24:59 UTC
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.

Comment 8 Ryan Barry 2017-01-31 22:26:39 UTC
Note that, as comment#3, this works as expected on EFI installations, but fails on legacy/mbr boot.

Comment 9 Ryan Barry 2017-01-31 22:55:23 UTC
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.

Comment 10 Douglas Schilling Landgraf 2017-02-01 00:24:26 UTC
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.

Comment 11 Ryan Barry 2017-02-01 04:02:12 UTC
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.()...

Comment 12 Douglas Schilling Landgraf 2017-02-02 00:32:54 UTC
(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

Comment 13 Sandro Bonazzola 2017-02-02 08:03:53 UTC
(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?

Comment 14 Ryan Barry 2017-02-02 12:57:35 UTC
> Can you open a BZ on platform about this and reference it here?

This is already referenced as a dependency:

rhbz#1366785

Comment 15 Douglas Schilling Landgraf 2017-02-04 05:50:15 UTC
> 
> > 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

Comment 16 Wei Wang 2017-03-10 08:09:40 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.