Thanks for the bug report!
This was a slight bug in the interpose logic within the OpenBIOS disk-
label package - we were always interposing a partition package if we
could detect a valid partition magic. In actual fact the interpose
should only happen when no arguments are specified when opening the
package, otherwise when opening the raw block device you "fall into" the
first valid partition by mistake.
I've committed a fix for this to OpenBIOS SVN trunk as r1127 and it
passes all my tests here so I am happy to close this out.
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1169856
Title:
OpenBIOS seek fails on NetBSD CD image
Status in QEMU:
Fix Committed
Bug description:
With qemu 1.3.0 it is not possible to boot a NetBSD install CD image,
using a command line like:
qemu-system-sparc64 -nographic -boot d -cdrom
NetBSD-6.99.19-sparc64.iso
The image used here is a custom one with a bit of bootloader debugging
added (see below). It is 310968320 bytes long (hex: 12890000) and when
burned to a CD boots on real Sun hardware.
The partition table on the CD is listed below, it consists of a big
ISO9660 partition first (the root filesystem) and a small UFS/FFS
partition only containing bootloader, kernel and a config file.
Probably what happens is: "open" is called in OF, for the "cdrom"
device. Then a "seek" call on this handle to the superblock of the UFS
partition fails, maybe because OpenBIOS eroneously interprets the
partition table and does not consider "cdrom" the full device?
Before we get to this stage, the forth boot block opens "cdrom:f" and
accesses the file system from there (without the full partition
offset, of course), which works fine - this is how we get the
secondary bootloader (ofwboot) loaded and executed.
Could this be simple "cdrom" vs "cdrom:a" confusion or something like
that?
Here are the relevant excerpts from the boot messages - I can make the
test image available, or just use a daily build HEAD image from
NetBSD.org.
I can also easily try patches or try to fix the bug myself, if you
could give me a hint where this open/seek openfirmware functions are
implemented.
Thanks,
Martin
--8<--
OpenBIOS for Sparc64
Configuration device id QEMU version 1 machine id 0
kernel cmdline
CPUs: 1 x SUNW,UltraSPARC-IIi
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.0 built on Aug 19 2012 13:06
Type 'help' for detailed information
Trying cdrom:f...
Not a bootable ELF image
Not a bootable a.out image
Loading FCode image...
Loaded 7478 bytes
entry point is 0x4000
NetBSD IEEE 1275 Multi-FS Bootblock
Version $NetBSD: bootblk.fth,v 1.13 2010/06/24 00:54:12 eeh Exp $
..
Jumping to entry point 0000000000100000 for type 0000000000000001...
switching to new context: entry point 0x100000 stack 0x00000000ffe86b39
>> NetBSD/sparc64 OpenFirmware Boot, Revision 1.16 (Mon Apr 15 22:11:52 CEST
20$
bootoptions: device='cdrom:f', kernel='', options=''
..
OF_open("cdrom")
... ok, handle: -3644496
devopen: cdrom is now open
devopen: trying to read disklabel
..
partition 0 start 0 size 93a80
partition 1 start 0 size 0
partition 2 start 0 size 0
partition 3 start 0 size 0
partition 4 start 0 size 0
partition 5 start 93a80 size a00
partition 6 start 0 size 0
partition 7 start 0 size 0
disklabel_sun_to_bsd: success!
devopen: setting partition 5 offset 93a80
devopen: return 0
..
strategy: block 10, partition offset 93a80, blksz 200
strategy: seek position should be: 12752000
strategy: seeking to 12752000
OF_seek(handle -3644496, pos 309665792)
OF_seek -> -1
UFS read failed with 5
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1169856/+subscriptions
