linuxboot qemu display & scsi not working as expected

[Madhan M]

Hi,

I am new to the linuxboot project and had some success so far. I am stuck at a point where I need some clarifications.

I got the heads build done. Built a qemu image and got a linuxboot.rom. I am able to run this in qemu and get to the boot menu.

I also got a linux (archlinux) to boot from USB, by attaching the thumbdrive to qemu during launch.

What is not working here as I expect is that the guest display is empty. The linux splash screen / menu is not coming up. But I see some menu options coming up on the qemu (--serial /dev/tty). Should the full fledged display on the qemu guest console come up? Is this a valid expectation? What can I do to get this working?

Also I tried attaching a cirros.img file as a scsi device to qemu. This shows up under lspci in the recovery prompt, but there is no driver attached and no /dev/sda entries created. The default boot option fails with message "dev/sda1 not found".

I have a suspicion that my expectations are wrong? The qemu build is not supposed to do a full fledged display and scsi boot? I confirmed both linux images (USB and SCSI) come up fine till the splash screen when loading with regular qemu (i.e no linuxboot). Any pointers will be a big help; even if it is to say this is not expected to work.

Thanks,

Madhan.

[Ryan O'Leary]

Our interns from last summer had difficulty getting graphics to display from the OS which was kexec'ed similar to how you described. They eventually got it to work, but I've forgotten how. There work is in github.com/u-root/webboot

Perhaps Ron or Gan can remember?

- Ryan

--
You received this message because you are subscribed to the Google Groups "linuxboot" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linuxboot+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/linuxboot/f9443776-8941-4b64-8096-2b370905765a%40googlegroups.com.

[ron minnich]

This is heads not webboot.

But you need to tell us a lot more than you have told us. What is your
qemu command line? How did you build your kernel? And so on.

[Madhan M]

Thanks for the quick response. Here is more detail.

I am running on an Ubuntu 18.04 system.

I did the following for build:

git clone https://github.com/osresearch/heads

cd heads

make BOARD=qemu-linuxboot

I get the linuxboot.rom in build/qemu-linuxboot

Then I downloaded a cirros-0.4.0-x86_64-disk.img file from the web.

If I just do qemu:

qemu-system-x86_64 -hda cirros-0.4.0-x86_64-disk.img --serial /dev/tty

I get the linux boot up text messages coming up both in the qemu client terminal window as well as the launch terminal and the OS boots.

But when I use linuxboot.rom with qemu command line:

sudo qemu-system-x86_64 -machine q35,smm=on -global ICH9-LPC.disable_s3=1 -global driver=cfi.pflash01,property=secure,value=on -drive if=pflash,format=raw,unit=0,file=./linuxboot.rom --serial /dev/tty -device virtio-blk-pci,drive=hdd -drive id=hdd,if=none,file=cirros-0.4.0-x86_64-disk.img,format=qcow2,boot=on,cache=writeback

I choose default boot at the boot menu.

This says 

mount: mounting /dev/sda1 on /boot failed: No such file or directory

!!!!! Unable to mount /boot

!!!!! Starting recovery shell

lspci shows up a new device with  

00:03.0 Class 0100: Device 1af4:1001

lsmod or the contents of /lib/modules has no *scsi* files in it. It looks like there is no driver attaching to this pci device?

If I attach the img file as a USB as per the qemu command line below:

sudo qemu-system-x86_64 -machine q35,smm=on -global ICH9-LPC.disable_s3=1 -global driver=cfi.pflash01,property=secure,value=on -drive if=pflash,format=raw,unit=0,file=./linuxboot.rom  --serial /dev/tty -usb -drive id=usbflash,format=qcow2,unit=1,file=cirros-0.4.0-x86_64-disk.img,if=none,boot=on,cache=writeback -device usb-storage,drive=usbflash

Then I choose "USB boot" at the boot menu and I get 

[   17.551752]  sda: sda1 sda15

[   17.580926] sd 0:0:0:0: [sda] Attached SCSI disk

+++ Select your USB disk:

1. /dev/sda1

2. /dev/sda15

Choose your USB disk [1-2, a to abort]: 1

[   34.328841] EXT4-fs (sda1): mounting ext3 file system using the ext4 subsystem

[   34.414034] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)

!!! Could not find any ISO, trying bootable USB

+++ Scanning for unsigned boot options

Failed to parse any boot options

!!!!! Something failed during USB boot

!!!!! Starting recovery shell

lspci shows the following new devices

00:1d.0 Class 0c03: Device 8086:2934 (rev 03)

00:1d.1 Class 0c03: Device 8086:2935 (rev 03)

00:1d.2 Class 0c03: Device 8086:2936 (rev 03)

00:1d.7 Class 0c03: Device 8086:293a (rev 03)

Note the serial tty, in this case the terminal used to launch qemu, shows us "Choose disk..." but the qemu display window is blank. This is a little better than trying to attach the image file as a hdd, but still has problems booting through to the OS.

Thanks,

Madhan.

>> To unsubscribe from this group and stop receiving emails from it, send an email to linu...@googlegroups.com.

[Madhan M]

Hi team,

I saw a note in the "Heads" page that says "Currently only tested in QEMU, the Thinkpad x230 and the Chell Chromebook. ** Xen and the TPM do not work in QEMU, so it is only for testing the initrd image." 

Does that mean it is not expected to support display (also scsi?) but USB seems to behave a little better as explained in the previous detailed mail.

Thanks,

Madhan.

[Madhan M]

Hi Team,

I tried another experiment. Built linuxboot with params BOARD=qemu KERNEL=../heads/build/qemu-linuxboot INITRD=../heads/build/qemu-linuxboot. Then tried running the linuxboot.rom from the linuxboot/build/qemu folder. This time qemu breaks out saying:

qemu-system-x86_64: Trying to execute code outside RAM or ROM at 0x00000000000a0000

This usually means one of the following happened:

(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine)

(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end

(3) Your guest kernel has a bug and crashed by jumping off into nowhere

Regards,

Madhan.

PS: Sorry about the flood of info. We seem to be across time zones and it takes a day to get any reply. So hoping to cut down on back and forth replies.

[Chris Koch]

You should open an issue on https://github.com/osresearch/heads

They may be more helpful than we are.

To unsubscribe from this group and stop receiving emails from it, send an email to linuxboot+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/linuxboot/e4f8603e-4808-4f5f-a085-fd7f13305c38%40googlegroups.com.

[Madhan Muruganantham]

Ok. Will do. Makes sense! 

Appreciate your time spent on all that info dump.

So, meanwhile I guess everybody is using actual hardware to work? 

I should role up my sleeves, rip open a server and start meddling with it? At the risk of bricking in? There is no safe step like a working emulator version?

Thanks and Regards,

Madhan.

[Ron Minnich]

get it working in qemu first. I suspect you're still doing something
not quite right

> To view this discussion on the web visit https://groups.google.com/d/msgid/linuxboot/CAMT_wypTV8Dthc2CTQ7LR3FfQ5sffLTy1gQjR9cjQbC%3DR-jXyQ%40mail.gmail.com.