Bug 467425
|
Description
Julian Sikorski
2008-10-17 12:20:59 UTC
Not sure how important that is, but if you answer no to the question about enabling graphics, install will stop saying no consoles are available. Can you attach /var/log/libvirt/qemu/pararawhide-i386.log please? Created attachment 322413 [details]
Log file of an attempted install using virt-install, no graphics
Here you go. This is the latest one, so I believe it contains data for installation without graphics support enabled.
What is your xen-runtime version? Must be latest (3.2.0-15.fc9) with this fix: * Thu Jul 31 2008 Mark McLoughlin <markmc> - 3.2.0-15.fc9 - Support booting bzImage DomU kernel (e.g. Fedora 10) That's what I have installed here: [jsikorski@snowball dev]$ rpm -q xen-runtime xen-runtime-3.2.0-15.fc9.x86_64 Hmm, thats odd, xen_guest_parse shouldn't fail then, and it actually works for me (64bit f9 host, f10-snap3 32bit guest). Can you run "xenner -debug 2 -kernel /path/to/vmlinuz-PAE" and attach the output please? I hope I used the correct path, it was the only vmlinuz-PAE I was able to find: [root@snowball jsikorski]# xenner -debug 2 -kernel http://sunsite.icm.edu.pl/pub/Linux/fedora/linux/development/i386/os/images/pxeboot/vmlinuz-PAE [xenner,2] started as: "xenner" "-debug" "2" "-kernel" "http://sunsite.icm.edu.pl/pub/Linux/fedora/linux/development/i386/os/images/pxeboot/vmlinuz-PAE" kvm capability clocksource: not enabled kvm capability nop-iodelay: not enabled kvm capability mmu-op: not enabled [xenner,2] prepare_environment: LD_LIBRARY_PATH=/usr/lib64/xenner [xenner,2] do_fork_exec: "/usr/lib64/xen/bin/qemu-dm" "-M" "xenpv" "-d" "4584" "-domain-name" "no-name" "-nographic" "-serial" "stdio" "-net" "none" domid: 4584 Console: prepared domain, waiting for ringref at /local/domain/4584/console or /local/domain/4584/serial/0 FB: Waiting for KBD backend creation Doing backend watch on /local/domain/0/backend/vkbd/4584/0 Wrong state 0 FB: Shutting down backend ==================== setup ==================== libxc: xc_evtchn_open -> handle 9 libxc: xenner_evtchnd_domid(handle 9, domid 4584) -> 4584 libxc: xc_evtchn_bind_unbound_port(handle 9, domid 0) -> 1 [xenner,2] evtchn_port: port 1 is xenstore libxc: xc_evtchn_bind_unbound_port(handle 9, domid 0) -> 2 [xenner,2] evtchn_port: port 2 is console xc_dom_allocate: cmdline="(null)", features="(null)" xen_guest_parse: ----- parse kernel ----- xc_dom_kernel_file: filename="http://sunsite.icm.edu.pl/pub/Linux/fedora/linux/development/i386/os/images/pxeboot/vmlinuz-PAE" xen_guest_parse: ----- FAILURE ----- domain_builder: ----- FAILURE ----- domain builder failed xenner_cleanup: ----- cleaning up ----- [root@snowball jsikorski]# -kernel arg must be a local file Created attachment 322415 [details]
Output of xenner command
I did something clueless: downloaded the file from the url and saved it on the hard drive, then I ran the suggested xen command. It ended up spitting out libxc: xc_evtchn_notify(handle 9, port 2) -> 0 until killed with ctrl-c. Does it mean that paravirt installs from network are unsupported?
Back to square one. Parsing the guest kernel worked fine this time, thus the logfile from comment #3 is probably stale. Can you retry the install and attach a fresh logfile? Network installs are supported. xenner doesn't fetch the kernel itself though, virt-install handles that. Created attachment 322421 [details] Log file of an attempted install using virt-install, no graphics It must have been stale, sorry. Here is the console output: [root@snowball qemu]# LANG=C virt-install --paravirt --os-type=linux --location=http://sunsite.icm.edu.pl/pub/Linux/fedora/linux/development/i386/os/ --name=pararawhide-i386 --vcpus=1 --file=/var/lib/libvirt/images/pararawhide-i386.img --accelerate --ram=512 --file-size=15 Would you like to enable graphics support? (yes or no) no Starting install... Retrieving file .treeinfo... | 1.1 kB 00:00 Retrieving file vmlinuz-PAE... | 2.6 MB 00:24 Retrieving file initrd-PAE.img... | 16 MB 01:51 Creating domain... | 0 B 00:00 No console available for domain Domain installation still in progress. You can reconnect to the console to complete the installation process. [root@snowball qemu]# After that the domain was still running, virt-manager said it was not configured for a guest and I had to destroy it. Created attachment 322423 [details]
Log file of an attempted install using virt-install, with graphics
Same file, but this time with graphics support enabled. Sits displaying parallel0 console indefinitely.
Uhm, virt-install creates a pretty pointless configuration. There isn't a serial line configured. IMHO it should do that. Especially for the non-graphical install ... Ok, try fixing it up this way: (1) start install as in comment #11 (2) virsh dumpxml <domain> > tmp.xml (3) virsh destroy <domain> (4) edit tmp.xml, add "<serial/>" to the devices. (5) virsh define tmp.xml (6) virsh start <domain> && virsh console <domain> Best case would be it works now. Even if it doesn't work we should at least see the kernel boot messages, giving clue what is going wrong. Created attachment 322467 [details]
edited tmp.xml
[root@snowball jsikorski]# LANG=C virsh start pararawhide-i386 && virsh console pararawhide-i386
Domain pararawhide-i386 started
unable to open TTY /dev/pts/2: No such file or directory
[root@snowball jsikorski]#
Hmm, what does "virsh list" say then? Does the guest still run? Could be virt-install cleaned up and deleted the kernel fetched from the internet, so the kernel path in the xml file doesn't work any more. Try fetching kernel & initrd by hand then and put the locations into the xml file. initrd & kernel were indeed deleted, so I downloaded them manually. Now the domain shows up in virsh list, but the error is only slightly different: /dev/pts/2 is replaced with /dev/pts/4. Hmm. No clue. Can you attach the libvirt logfile for this attempt please? Created attachment 322769 [details]
Log file of domain defined with tmp.xml
Does not look much different...
Created attachment 322770 [details]
xml file used to define the above domain
[xenner,1] child 8466 (qemu-dm) exited: 1 Thats why /dev/pts/4 disappeared, qemu-dm handles it and it is gone (probably crashed). Ok, one more experiment: can you try adding <graphics> to the devices? That could work around qemu-dm crash. Also add "console=hvc0" to the command line then, otherwise the kernel will prefer the framebuffer. There is also this one in the log: [xenner,1] qemu_disk_config_blkbackd: if != xen, ignoring disk Can you change the bus='ide' to bus='xen' in the xml config? Otherwise the guest will have no disk. Thanks. Created attachment 322859 [details]
xml that made it work
With the above file anaconda started and reached the stage after connection type selection. Is that good enough?
Created attachment 322860 [details]
log of the above attempt
It should be noted that anaconda got stuck after that, but it's an improvement nontheless. Oops, looks like it works perfectly fine now, sorry. The installer was getting stuck at the point in which it was supposed to fetch install.img due to bug #467687. Once I realised that, I restarted the virtual network and install.img is being retrieved as we speak. Do you want me to do any more testing? Fedora 10 is about to be released, and it won't be long until I update to it. It is likely I won't be able to reproduce the issue any more then. Seems like it works in Fedora 10. |