Bug 1302644
Summary: | centos 6 grub 'press any key to continue' takes a long time if no serial device attached | ||
---|---|---|---|
Product: | [Community] Virtualization Tools | Reporter: | David Caro <dcaroest> |
Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | crobinso, dcaroest, eedri, ptoscano, rbalakri, rjones |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-05-02 19:19:38 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: |
Description
David Caro
2016-01-28 10:19:42 UTC
When creating the vm from virt-manager, it adds a serial pty, adding that element speeds up a lot the boot (as expected) Confirmed, adding this to the devices section works around the issue: <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> I think this was a qemu regression... I swear there was a commit for it but I can't think of what to grep for in the logs. Can you reproduce with latest qemu from f23? And if that still has the issue, can you grab newer qemu from https://fedoraproject.org/wiki/Virtualization_Preview_Repository I still have the issue on fc23 with the above repo and qemu: $ rpm -qa qemu\* qemu-kvm-2.6.0-0.2.rc3.fc23.x86_64 qemu-user-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-s390x-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-m68k-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-aarch64-2.6.0-0.2.rc3.fc23.x86_64 qemu-common-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-arm-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-x86-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-unicore32-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-moxie-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-cris-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-tricore-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-microblaze-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-sparc-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-ppc-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-lm32-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-sh4-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-mips-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-alpha-2.6.0-0.2.rc3.fc23.x86_64 qemu-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-xtensa-2.6.0-0.2.rc3.fc23.x86_64 qemu-system-or32-2.6.0-0.2.rc3.fc23.x86_64 qemu-guest-agent-2.4.1-8.fc23.x86_64 qemu-img-2.6.0-0.2.rc3.fc23.x86_64 Tested a similar setup (vm disk created with virt-builder centos-6) and the domxml: <domain type='kvm' id='3'> <name>46df9c20-lago_functional_tests_vm01</name> <uuid>86813091-9e3e-45a5-9dd6-a84b98d20383</uuid> <memory unit='KiB'>524288</memory> <currentMemory unit='KiB'>524288</currentMemory> <vcpu placement='static'>2</vcpu> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-i440fx-2.6'>hvm</type> <bootmenu enable='yes'/> </os> <features> <acpi/> <apic/> <pae/> </features> <cpu mode='host-passthrough'> <topology sockets='2' cores='1' threads='1'/> </cpu> <clock offset='utc'> <timer name='kvmclock'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/bin/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/home/dcaro/Work/lago-project/lago/tests/functional/fixtures/deploy/.lago/default/images/lago_functional_tests_vm01_root.qcow2'/> <backingStore type='file' index='1'> <format type='raw'/> <source file='/home/dcaro/lago/store/phx_repo:el6-base:latest'/> <backingStore/> </backingStore> <target dev='vda' bus='virtio'/> <boot order='1'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <controller type='usb' index='0'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'> <alias name='pci.0'/> </controller> <controller type='virtio-serial' index='0'> <alias name='virtio-serial0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> <interface type='network'> <mac address='54:52:c0:a8:c8:02'/> <source network='46df-785d5195a1' bridge='46df-785d519'/> <target dev='vnet0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/46df9c20-lago_functional_tests_vm01.org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0' keymap='en-us'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='cirrus' vram='16384' heads='1'/> <alias name='video0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='none'> <alias name='balloon0'/> </memballoon> <rng model='virtio'> <backend model='random'>/dev/random</backend> <alias name='rng0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </rng> </devices> <seclabel type='dynamic' model='selinux' relabel='yes'> <label>system_u:system_r:svirt_t:s0:c433,c921</label> <imagelabel>system_u:object_r:svirt_image_t:s0:c433,c921</imagelabel> </seclabel> </domain> Okay, I reproduced. But I don't think this is a qemu bug, probably a centos 6 grub bug, if a bug at all. virt-builder images have grub configured to send output to the serial console. Maybe that's the default config, I didn't confirm. Either way, I suspect grub is trying to detect serial hardware which is what causes the delay. I thought maybe it was some serial buffer filling up because there was no host side reader (which has been an issue in the past), but once it gets to the grub screen things proceed normally. So I'm closing this as NOTABUG for the virt stack. Maybe rjones can provide more info though (In reply to Cole Robinson from comment #5) > Okay, I reproduced. But I don't think this is a qemu bug, probably a centos > 6 grub bug, if a bug at all. > > virt-builder images have grub configured to send output to the serial > console. Maybe that's the default config, I didn't confirm. Either way, I > suspect grub is trying to detect serial hardware which is what causes the > delay. I thought maybe it was some serial buffer filling up because there > was no host side reader (which has been an issue in the past), but once it > gets to the grub screen things proceed normally. > > So I'm closing this as NOTABUG for the virt stack. Maybe rjones can provide > more info though I think it's because we create the base images using a serial console, so anaconda configures one. Then when virt-builder creates a disk image from this template and the user boots it, it will still have the serial console. eg: https://github.com/libguestfs/libguestfs/blob/master/builder/website/centos.sh#L94 I had seen this problem was puzzled by it before, so at least it's good to see the analysis of why it happens. I guess the solutions include: - somehow(?) remove the serial console in virt-builder - fix GRUB so it doesn't hang for 5 minutes when there's no serial console - users can add a serial console |