Once installed, it won't boot. Booting from iso image works, and the installed system is mountable and accessible. Booting it gives: QEMU Starting Build Date = Oct 12 2015 13:18:48 FW Version = mockbuild@ release 20151012 Press "s" to enter Open Firmware. Populating /vdevice methods Populating /vdevice/v-scsi@2000 SCSI: Looking for devices 8002000000000000 DISK : "QEMU QEMU HARDDISK 2.3." 8001000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.3." Populating /vdevice/vty@30000000 Populating /vdevice/nvram@71000000 Populating /pci@800000020000000 00 1800 (D) : 1af4 1002 unknown-legacy-device* 00 1000 (D) : 106b 003f serial bus [ usb-ohci ] 00 0800 (D) : 8086 100e e1000 [ net ] Scanning USB OHCI: initializing USB Keyboard USB mouse Using default console: /vdevice/vty@30000000 Welcome to Open Firmware Copyright (c) 2004, 2011 IBM Corporation All rights reserved. This program and the accompanying materials are made available under the terms of the BSD License available at http://www.opensource.org/licenses/bsd-license.php Trying to load: from: /vdevice/v-scsi@2000/disk@8002000000000000 ... Successfully loaded >> FreeBSD/powerpc Open Firmware boot block Boot path: /vdevice/v-scsi@2000/disk@8002000000000000 Boot loader: /boot/loader domount: can't read superblock panic: domount W3411: Client application returned. E3406: Client application returned an error. hence the boot code is executed, but there is a problem with the openfirmware routines that read the disk returnig nulls instead of the superblock of the UFS filesystem.
Here is my disk image (raw, gzipped): http://www.vespaperitivo.it/freebsd/disk_image.gz and the quemu command (generated by libvirt) should be in: http://www.vespaperitivo.it/freebsd/launch Luciano.
Created attachment 173451 [details] a single frame from a video witnessing the crash
Comment on attachment 173451 [details] a single frame from a video witnessing the crash Could your problem be related to what I have been seeing on a PowerMac G5 after BETA3? BETA2 boots just fine. BETA3 panics persistently every time and always at the exact same step during boot. The command name in the center of the image reads "swapper".
No, it happens before the crash you are showing. It has to do with IBM's implementation of the openfirmware. The boot program calls openfirmware foe each disk slice, but fails to get the UFS magic number that indeed is there: you can boot from the iso image and mount the filesystem containing the boot (and even recompile and reinstall everything from source).
(In reply to jau from comment #3) Doing a bit of debugging shows that the fsread_size() function (in /src/sys/boot/common/ufsread.c) calls 4 times dskread() and gets fs.fs_magic == 0 each time so it gives up and domount gives up too. I don't know where to look for the dskread() code, so I gave up.
(In reply to Luciano Mannucci from comment #5) Have you tried a newer version of QEMU? The QEMU 2.4.1 that comes with Fedora 23 boots your disk image with no problems at all.
(In reply to Nathan Whitehorn from comment #6) Not so easy. IBM ships with powerKWM as the only supported OS, wich is based on Fedora 22 (which bears qemu 2.3.1). I'll try to recompile 2.4.1 from source under fedora 22 to see if there are kernel/kvm incompatibilities. It may take a while, though.
(In reply to Luciano Mannucci from comment #7) Great, thanks. I'll try out QEMU 2.3 here. If we can just trace the issue to a SLOF difference between those two QEMU releases, I think it will be pretty easy to work around whatever the problem is.
(In reply to Nathan Whitehorn from comment #8) That would be very cool. It'll stop IBM from claiming that Freebsd and MacOs 9 won't run on their Power8 under Qemu... :)
(In reply to Luciano Mannucci from comment #9) Could you please try running the following command from the SLOF prompt? boot disk:0
A commit references this bug: Author: nwhitehorn Date: Tue Aug 30 00:47:21 UTC 2016 New revision: 305036 URL: https://svnweb.freebsd.org/changeset/base/305036 Log: Some versions of SLOF do not append the partition number to the boot device argument to the stage-1 bootloader. In such cases, boot1 would only try to read the entire device rather than checking for partitions. Instead of panic'ing, fall back to reading the partitions as normal in such situations. This was preventing boot of installed systems on some versions of PowerKVM. PR: kern/211599 MFC after: 2 days Changes: head/sys/boot/powerpc/boot1.chrp/boot1.c
A commit references this bug: Author: nwhitehorn Date: Thu Sep 1 22:24:31 UTC 2016 New revision: 305249 URL: https://svnweb.freebsd.org/changeset/base/305249 Log: MFC r305036: Some versions of SLOF do not append the partition number to the boot device argument to the stage-1 bootloader. In such cases, boot1 would only try to read the entire device rather than checking for partitions. Instead of panic'ing, fall back to reading the partitions as normal in such situations. This was preventing boot of installed systems on some versions of PowerKVM. PR: kern/211599 Changes: _U stable/11/ stable/11/sys/boot/powerpc/boot1.chrp/boot1.c
A commit references this bug: Author: nwhitehorn Date: Fri Sep 2 00:45:44 UTC 2016 New revision: 305266 URL: https://svnweb.freebsd.org/changeset/base/305266 Log: MFS11 r305249: MFC r305036: Some versions of SLOF do not append the partition number to the boot device argument to the stage-1 bootloader. In such cases, boot1 would only try to read the entire device rather than checking for partitions. Instead of panic'ing, fall back to reading the partitions as normal in such situations. This was preventing boot of installed systems on some versions of PowerKVM. PR: kern/211599 Approved by: re (gjb) Changes: _U releng/11.0/ releng/11.0/sys/boot/powerpc/boot1.chrp/boot1.c