Bug 1457670 - Boot entry and layer are wrong after upgrade to rhvh-4.1-0.20170531.0
Summary: Boot entry and layer are wrong after upgrade to rhvh-4.1-0.20170531.0
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-node
Classification: oVirt
Component: Installation & Update
Version: 4.1
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ovirt-4.1.3
: 4.1
Assignee: Ryan Barry
QA Contact: Huijuan Zhao
URL:
Whiteboard:
Depends On:
Blocks: 1368420 1419829 1447887
TreeView+ depends on / blocked
 
Reported: 2017-06-01 06:50 UTC by Huijuan Zhao
Modified: 2017-07-06 13:16 UTC (History)
14 users (show)

Fixed In Version: imgbased-0.9.30-0.1.el7ev
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-06 13:16:40 UTC
oVirt Team: Node
Embargoed:
rule-engine: ovirt-4.1+
rule-engine: blocker+
cshao: testing_ack+


Attachments (Terms of Use)
Screenshot of boot entry (839.89 KB, image/png)
2017-06-01 06:50 UTC, Huijuan Zhao
no flags Details
All logs in /var/log, /tmp and sosreport (8.58 MB, application/x-gzip)
2017-06-01 06:53 UTC, Huijuan Zhao
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 77681 0 master MERGED osupdater: swap arguments for threaded_boot_runner 2020-09-11 07:38:42 UTC
oVirt gerrit 77683 0 ovirt-4.1 MERGED osupdater: swap arguments for threaded_boot_runner 2020-09-11 07:38:41 UTC

Description Huijuan Zhao 2017-06-01 06:50:44 UTC
Created attachment 1284008 [details]
Screenshot of boot entry

Description of problem:
Upgrade from rhvh-4.0-0.20170307.0 to rhvh-4.1-0.20170531.0, the new build boot entry is wrong, when enter this wrong boot entry, the layer is also wrong, it is the old layer.
The boot entry shows as below:
----------------------
rhvh-4.0-0.20170307.0
rhvh-4.0-0.20170307.0
tboot 1.9.4
----------------------


Version-Release number of selected component (if applicable):
From: rhvh-4.0-0.20170307.0
To: rhvh-4.1-0.20170531.0
    imgbased-0.9.30-0.1.el7ev.noarch


How reproducible:
100%


Steps to Reproduce:
1. Clean install redhat-virtualization-host-4.0-20170307.0
2. Reboot and login rhvh-4.0, setup local repos, and upgrade host to rhvh-4.1-0.20170531.0
   # yum update
3. After upgrade, reboot and focus on boot entry
4. Enter the first boot entry, check imgbase and lvs


Actual results:
1. After step 3, the new build boot entry is wrong, it shows as below:
----------------------
rhvh-4.0-0.20170307.0
rhvh-4.0-0.20170307.0
tboot 1.9.4
----------------------

2. After step 4, the new build layer is wrong, it is the old layer imgbase, but lvs shows new partitions.
# imgbase w
[INFO] You are on rhvh-4.0-0.20170307.0+1

# rpm -qa | grep imgbase
imgbased-0.8.16-0.1.el7ev.noarch

# lvs -a
  LV                      VG              Attr       LSize   Pool   Origin                Data%  Meta%  Move Log Cpy%Sync Convert
  home                    rhvh_dhcp-10-16 Vwi-a-tz--   1.00g pool00                       58.06                                  
  [lvol0_pmspare]         rhvh_dhcp-10-16 ewi------- 116.00m                                                                    
  pool00                  rhvh_dhcp-10-16 twi-aotz-- 906.75g                              1.00   0.12                            
  [pool00_tdata]          rhvh_dhcp-10-16 Twi-ao---- 906.75g                                                                    
  [pool00_tmeta]          rhvh_dhcp-10-16 ewi-ao----   1.00g                                                                    
  rhvh-4.0-0.20170307.0   rhvh_dhcp-10-16 Vwi---tz-k 891.75g pool00 root                                                        
  rhvh-4.0-0.20170307.0+1 rhvh_dhcp-10-16 Vwi-aotz-- 891.75g pool00 rhvh-4.0-0.20170307.0 0.44                                  
  rhvh-4.1-0.20170531.0   rhvh_dhcp-10-16 Vri---tz-k 891.75g pool00                                                              
  rhvh-4.1-0.20170531.0+1 rhvh_dhcp-10-16 Vwi-a-tz-- 891.75g pool00 rhvh-4.1-0.20170531.0 0.29                                  
  root                    rhvh_dhcp-10-16 Vwi-a-tz-- 891.75g pool00                       0.30                                  
  swap                    rhvh_dhcp-10-16 -wi-ao----   7.75g                                                                    
  tmp                     rhvh_dhcp-10-16 Vwi-a-tz--   2.00g pool00                       3.52                                  
  var                     rhvh_dhcp-10-16 Vwi-aotz--  15.00g pool00                       3.52                                  
  var-log                 rhvh_dhcp-10-16 Vwi-a-tz--   8.00g pool00                       3.31                                  
  var-log-audit           rhvh_dhcp-10-16 Vwi-a-tz--   2.00g pool00                       4.93


Expected results:
1. After step 3, the new build boot entry should be correct, it should show as below:
----------------------
rhvh-4.1-0.20170531.0
rhvh-4.0-0.20170307.0
tboot 1.9.4
----------------------

2. After step 4, the new layer/imgbase should be correct.


Additional info:
1. Also encountered this issue when upgrade from rhvh-4.1-0.20170522.0 to rhvh-4.1-0.20170531.0
2. Also encountered this issue when upgrade via "yum install *update*.rpm"
3. Also encountered this issue when upgrade from rhvm side
4. According to above test results, this bug blocked the upgrade testing

Comment 1 Huijuan Zhao 2017-06-01 06:53:17 UTC
Created attachment 1284011 [details]
All logs in /var/log,  /tmp and sosreport

Comment 2 Huijuan Zhao 2017-06-01 10:06:47 UTC
No such issue in the 4.1.2 build rhvh-4.1-20170522.0, so add regression keywords.

Comment 3 Huijuan Zhao 2017-06-12 06:21:50 UTC
Test version:
From: rhvh-4.0-0.20170307.0
To: rhvh-4.1-0.20170609.2

Test steps:
Same as comment 0

Test results:
The new build boot entry and layer both are correct.


So this bug is fixed in rhvh-4.1-0.20170609.2, I will change the status to VERIFIED after the status is changed to ON_QA.

Comment 4 Huijuan Zhao 2017-06-14 23:04:48 UTC
According to comment 3, the bug is fixed in imgbased-0.9.31-0.1.el7ev.noarch, change the status to VERIFIED.


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