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

[Martin Husemann]

Public bug reported:

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

** Affects: qemu
     Importance: Undecided
         Status: New

** Description changed:

  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 fourth boot block opens "cdrom:f" and
+ 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
+   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 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

-- 
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:
  New

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