RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 832915 - RHEV-H restart twice during upgrade via RHEV-M or kernel command line.
Summary: RHEV-H restart twice during upgrade via RHEV-M or kernel command line.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ovirt-node
Version: 6.3
Hardware: x86_64
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Mike Burns
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-18 07:59 UTC by cshao
Modified: 2016-04-26 14:43 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-18 11:44:31 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description cshao 2012-06-18 07:59:41 UTC 
Description of problem:
RHEV-H restart twice during upgrade via RHEV-M or kernel command line.

Version-Release number of selected component (if applicable):
rhev-hypervisor6-6.3-20120615.1.el6

How reproducible:
100%

Steps to Reproduce:
1. Install RHEV-H 6.2 GA version(rhevh-6.2-20111117.1.el6).
2. Upgrade from RHEV-H 6.2 GA to latest version via RHEV-M or kernel command line.
3. Focus on upgrade process.

Actual results:
1. RHEV-H restart twice during upgrade.
2. After the twice restart, rhevh will boot from backup menu direct, but boot failed as bug 827383 description.

============================================
Entering non-interactive startup
Starting ovirt-early: init: rc main process (1330) killed by TERM signal
Sending all processes the TERM signal... [ OK ]
Sending all processes the KILL signal... [ OK ]
Saving random seed: [ OK ]
Syncing hardware clock to system time [ OK ]
Turning off swap: [ OK ]
Unmounting file systems: [ OK ]
umount2: Device or resource busy
umount: /etc: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))
umount2: Device or resource busy
umount: / dev / .initramfs/live: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fusRestarting system.
er(1))
umount2:


Expected results:
1. RHEV-H can boot to latest version after upgrade.
2. RHEV-H restart once during upgrade.

Additional info:
1. No such issue when upgrade from 6.2 GA to rhev-hypervisor6-6.3-20120606.3.el6, so it is a regression bug.
2. RHEV-H upgrade via TUI can successful and restart once.
Comment 3 Mike Burns 2012-06-18 11:44:31 UTC 
This is (unfortunately) by design.  There is a limitation in the in-place upgrade that causes it to run all the code from the old version to do the upgrade.  To run custom upgrade logic that requires boot time changes (and can't be enabled/disabled during run-time), it needs to be run during the first boot after upgrade.  Since the changes require things to be set at boot time, the host is rebooted a second time.
Note You need to log in before you can comment on or make changes to this bug.