[Qemu-devel] [Bug 1169856] Re: OpenBIOS seek fails on NetBSD CD image

[Mark Cave-Ayland]

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