Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1019778

Summary: ubuntu guest would stop at grub screen after multiple system_reset
Product: Red Hat Enterprise Linux 6 Reporter: Xiaoqing Wei <xwei>
Component: qemu-kvmAssignee: Ademar Reis <areis>
Status: CLOSED NOTABUG QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.5CC: acathrow, bsarathy, juzhang, michen, mkenneth, qzhang, shuang, virt-maint, xwei
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-17 14:55:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
guest pic none

Description Xiaoqing Wei 2013-10-16 11:41:45 UTC
Created attachment 812873 [details]
guest pic

Description of problem:

ubuntu guest would stop at grub screen after multiple system_reset

Version-Release number of selected component (if applicable):
kernel-2.6.32-422.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.412.el6.x86_64
spice-server-0.12.4-3.el6.x86_64
gpxe-roms-qemu-0.9.7-6.10.el6.noarch
package vgabios-bin is not installed
sgabios-bin-0-0.3.20110621svn.el6.noarch
seabios-0.6.1.2-28.el6.x86_64
ubuntu-12.04 or ubuntu-13.04

How reproducible:
4/4

Steps to Reproduce:
1./root/staf-kvm-devel/autotest-devel/client/tests/virt/qemu/qemu \
    -S \
    -name 'virt-tests-vm1' \
    -nodefaults \
    -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20131015-173942-7y3gpb7k,server,nowait \
    -mon chardev=qmp_id_qmpmonitor1,mode=control \
    -chardev socket,id=serial_id_serial1,path=/tmp/serial-serial1-20131015-173942-7y3gpb7k,server,nowait \
    -device isa-serial,chardev=serial_id_serial1 \
    -chardev socket,id=seabioslog_id_20131015-173942-7y3gpb7k,path=/tmp/seabios-20131015-173942-7y3gpb7k,server,nowait \
    -device isa-debugcon,chardev=seabioslog_id_20131015-173942-7y3gpb7k,iobase=0x402 \
    -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=0x4 \
    -drive file='/root/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/ubuntu-13.04-server-64-virtio.qcow2',index=0,if=none,id=drive-virtio-disk1,media=disk,cache=none,snapshot=off,format=qcow2,aio=native \
    -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,bootindex=0 \
    -device virtio-net-pci,netdev=idnmcZuR,mac='9a:f7:f8:f9:fa:fb',bus=pci.0,addr=0x3,id='idu7Jt6M' \
    -netdev tap,id=idnmcZuR,vhost=on,vhostfd=23,fd=22 \
    -m 2048 \
    -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \
    -cpu 'SandyBridge' \
    -M rhel6.5.0 \
    -device AC97,addr=0x6 \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
    -vnc :0 \
    -vga cirrus \
    -rtc base=utc,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off   \
    -no-kvm-pit-reinjection \
    -enable-kvm
2. login guest
3. then on qemu monitor: system_reset(send multiple times, sleep 0 ~ 120 sec  before next system_reset  )


Actual results:
vm stops at grub, wont automatically select a entry to boot, manually send enter key would boot

Expected results:

guest should still boot automatically
Additional info:

Comment 2 Ademar Reis 2013-10-16 14:01:54 UTC
(In reply to Xiaoqing Wei from comment #0)
> 2. login guest
> 3. then on qemu monitor: system_reset(send multiple times, sleep 0 ~ 120 sec
> before next system_reset  )
> 
> Actual results:
> vm stops at grub, wont automatically select a entry to boot, manually send
> enter key would boot

Since you're resetting the VM with the OS "alive", I wonder if the guest fs is getting corrupted, or files that interfere with grub are changed by something that happens in the background (in the guest).

One way to check is: once it gets stuck at the boot screen (grub), shut it off (not just a reset) and then on again. What happens on the next boot? If it gets stuck again, then my theory is right and there's nothing we can do.

Comment 3 Xiaoqing Wei 2013-10-17 02:26:29 UTC
(In reply to Ademar de Souza Reis Jr. from comment #2)
> (In reply to Xiaoqing Wei from comment #0)
> > 2. login guest
> > 3. then on qemu monitor: system_reset(send multiple times, sleep 0 ~ 120 sec
> > before next system_reset  )
> > 
> > Actual results:
> > vm stops at grub, wont automatically select a entry to boot, manually send
> > enter key would boot
> 
> Since you're resetting the VM with the OS "alive", I wonder if the guest fs
> is getting corrupted, or files that interfere with grub are changed by
> something that happens in the background (in the guest).
> 
> One way to check is: once it gets stuck at the boot screen (grub), shut it
> off (not just a reset) and then on again. What happens on the next boot? If
> it gets stuck again, then my theory is right and there's nothing we can do.

I tried quit the qemu process when this happens, then launch the qemu again,
the vm still, get stuck at the grub,

Regards,
Xiaoqing.

Comment 4 Ademar Reis 2013-10-17 14:55:05 UTC
(In reply to Xiaoqing Wei from comment #3)
> > Since you're resetting the VM with the OS "alive", I wonder if the guest fs
> > is getting corrupted, or files that interfere with grub are changed by
> > something that happens in the background (in the guest).
> > 
> > One way to check is: once it gets stuck at the boot screen (grub), shut it
> > off (not just a reset) and then on again. What happens on the next boot? If
> > it gets stuck again, then my theory is right and there's nothing we can do.
> 
> I tried quit the qemu process when this happens, then launch the qemu again,
> the vm still, get stuck at the grub,
> 

That means something is wrong on the guest side. Since you're rebooting the VM "the hard way" many times, this is expected (it's like hitting the "reset" button on a physical machines while the OS is alive... odds are at some point it'll stop working if you do this many times)