Bug 708469 - RHEVH 6.1(20110510.1) allows unsupported upgrade from RHEVH 5.6(10.2.el5_6)
Summary: RHEVH 6.1(20110510.1) allows unsupported upgrade from RHEVH 5.6(10.2.el5_6)
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ovirt-node
Version: 6.1
Hardware: All
OS: Linux
high
medium
Target Milestone: beta
: ---
Assignee: Alan Pevec
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-27 18:28 UTC by Sanjay Mehrotra
Modified: 2011-11-07 17:35 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-07 17:35:41 UTC
Target Upstream Version:


Attachments (Terms of Use)
Messages file /var/log/message (171.72 KB, application/octet-stream)
2011-05-27 18:28 UTC, Sanjay Mehrotra
no flags Details
Ovirt Log file of upgrade (101.22 KB, application/octet-stream)
2011-05-27 18:29 UTC, Sanjay Mehrotra
no flags Details
Ovirt log from original 5.6 install (100.39 KB, application/octet-stream)
2011-05-27 18:31 UTC, Sanjay Mehrotra
no flags Details

Description Sanjay Mehrotra 2011-05-27 18:28:23 UTC
Created attachment 501360 [details]
Messages file /var/log/message

Description of problem:
On a released 5.6 hypervisor, install ( i used pxe boot ) rhevh 6.1 using the following commands at boot prompt. 
boot:  rhev6.1 console=ttyS0,9600n8   ( Please note - there is no storage_init, root_pw  used here ) 

Version-Release number of selected component (if applicable):
See Summary

How reproducible:
100% 

Steps to Reproduce:
1. Clean Install 2.2 version of RHEVH  aka 5.6 Hypervisor 
2. Upgrade with boot commands mentioned above
3. The installation succeeds, allowed to login into the hypervisor. 
4.  Old 5.6 information ( ip address, volume information etc) 
  
Actual results:
It appears the packages are updated, daemons started which is not expected to work. 

Expected results:
Either of the following results will work 
1. Perform clean install - with interaction from installer.  Meaning, user should be warned all data will be lost. 
2. Disallow the operation completely as it is not supported, informing the user about the correct boot: arguments. 

Additional info:
Attachments of /var/log/message, /var/log/ovirt.log ( 6.1 upgrade). /var/log/ovirt.log.orig ( 5.6 install )

Comment 1 Sanjay Mehrotra 2011-05-27 18:29:52 UTC
Created attachment 501361 [details]
Ovirt Log file of upgrade

Comment 2 Sanjay Mehrotra 2011-05-27 18:31:08 UTC
Created attachment 501362 [details]
Ovirt log from original 5.6 install

Comment 4 Sanjay Mehrotra 2011-05-27 18:32:47 UTC
Please let me know if access is required for the machine.

Comment 5 Mohua Li 2011-06-01 03:46:57 UTC
upgrade from rhev-hypervisor 5.6-11.1 to rhev-hypervisor 6.1-20110510.1 with kernel boot command line "linux upgrade", will get "Major version upgrade not allowed", this is expected,
 

what i don't understand is your boot command line, this is no upgrade at all, 
boot:  rhev6.1 console=ttyS0,9600n8   ( Please note - there is no storage_init,
root_pw  used here )

Comment 6 Alan Pevec 2011-06-01 07:24:03 UTC
> boot:  rhev6.1 console=ttyS0,9600n8
> ( Please note - there is no storage_init,root_pw  used here ) 

This will boot rhevh as any livecd but it will pick existing LVs on the local storage. Nothing is installed in this case, image runs live from CD.

Persisted storage ( /config partition ) is not versioned, we're using Stateless Linux support (in RHEL since 5) which happily uses anything you point it to (via STATE_LABEL in /etc/sysconfig/readonly-root).
This would make a nice RFE for Stateless Linux but note that it's currently not under active development, see http://fedoraproject.org/wiki/StatelessLinux

Comment 7 Mike Burns 2011-10-26 18:07:51 UTC
This is a corner case where we're running stateless but still using the config from the 5.x version.  Best bet until we have full stateless support is to detect when we're running from media (pxe media, cdrom, usb?) rather than the installed location and not allow anything other than the installation flow (which blocks the upgrade).


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