[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] unable to boot from cdrom using OVMF in latest xen-unstable



On Wed, Jul 29, 2015 at 03:25:29PM +0200, Fabio Fantoni wrote:
> Il 29/07/2015 13:20, Wei Liu ha scritto:
> >On Wed, Jul 29, 2015 at 01:15:24PM +0200, Fabio Fantoni wrote:
> >[...]
> >>>(d14) BIOS map:
> >>>(d14)  ffe00000-ffffffff: Main BIOS
> >>>(d14) E820 table:
> >>>(d14)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
> >>>(d14)  HOLE: 00000000:000a0000 - 00000000:000f0000
> >>>(d14)  [01]: 00000000:000f0000 - 00000000:00100000: RESERVED
> >>>(d14)  [02]: 00000000:00100000 - 00000000:7eead000: RAM
> >>>(d14)  HOLE: 00000000:7eead000 - 00000000:fc000000
> >>>(d14)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
> >>>(d14) Invoking OVMF ...
> >>>(XEN) irq.c:276: Dom14 PCI link 0 changed 5 -> 11
> >>>(XEN) irq.c:276: Dom14 PCI link 1 changed 10 -> 11
> >>>(XEN) irq.c:276: Dom14 PCI link 2 changed 11 -> 10
> >>>(XEN) irq.c:276: Dom14 PCI link 3 changed 5 -> 10
> >>The strange thing is that I not found lines "Boot from" similar to domUs
> >>with seabios instead, for example a w10 domU, seabios and boot='dc' and with
> >>empty cdrom have also these lines:
> >Right. That's because OVMF doesn't write to the correct port. Sigh.
> >
> >It requires recompiling OVMF to make it write to serial console, which
> >is probably too much trouble for you.
> >
> >Another thing to try is to use VNC to connect to your DomU to see if
> >there is anything useful there.
> >
> >Wei.
> I use spice instead, output should be same even if quality and features is
> better.
> I remembered that ovmf from debian packages is compiled without debug, I
> recompiled with ovmf included in xen-unstable instead.
> After on first test I saw that boot correctly from cdrom.
> I did other tests after remember that with serial='pty' I need to look qemu
> log, see the port and do a cat on it (sorry for lost time previously for my
> bad memory).
> Without debug is too fast on boot is not possible but with this with debug
> yes.
> With ide (default) and boot='c' do strange things, boot from cdrom and
> domU's serial output is:
> >cat /dev/pts/5
> >3h
> >3h
> With hdtype='ahci' printed the output correctly but what did in boot is
> still strange:
> >cat /dev/pts/4
> >Boot Failed. EFI Floppy
> >Boot Failed. EFI Floppy 1
> >Booting in insecure mode
> >System BootOrder not found.  Initializing defaults.
> >device path: 
> >"Acpi(PNP0A03,0)/Pci(2|0)/VenHw(3D3CA290-B9A5-11E3-B75D-B8AC6F7D65E6)/HD(Part1,SigF5D503AE-FD24-4E28-8D1B-8D0A2F97F0BC)/\EFI\fedora\shim.efi"
> >Creating boot entry "Boot0005" with label "Fedora" for file
> >"\EFI\fedora\shim.efi"
> >Booting in insecure mode
> based on qemu configuration floppy should be not present and about the boot
> order the strange thing is "System BootOrder not found. Initializing
> defaults."
> 
> if you need more informations/tests tell me and I'll post them.

Anthony told me that this could be indeed a bug that OVMF doesn't really
honor the boot sequence specified.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.