False Prophets

We have started using qemu for automated testing at work. Right now we only have one kernel and disk image that I threw together by hand (for ARM), so I spent a big chunk of this afternoon trying to figure out how to do it and document the process. When I did it last time, I needed major kernel hacks and qemu patches and debian-installer tweaks, because the ARM emulation didn’t have anything capable of working as a hard drive; so I took some code that Paul had written to use the Angel RDI semihosting operations as a “virtual block device” that talked to the host system. I added support for this hack to qemu and forced d-i to install even though there was only a single non-partitionable device.

Since then, Paul added real PCI support to the ARM qemu. So I expected everything to be much easier. I took Aur�lien Jarno’s excellent writeup and prepared to try again. But since we already had a functional ARM disk image, that was lower priority… I decided to try MIPS. I helped get the MIPS softmmu port working about a year ago, but it hasn’t been receiving a whole lot in the way of care (though there’s a bunch of unreviewed patches for it).

First I discovered that I’d never gotten initrds implemented last time I worked on qemu-system-mips. So I hacked that together. Then I needed a drive; I used root NFS in my last setup, but the whole point of this experiment was to avoid that. So I added the emulated ISA IDE controller. Good news: both of those worked easily! And the d-i session starts up OK, and even writes to the disk OK; partition tables were discovered at next boot. I’ve posted some patches for these.

Bad news: it hangs during formatting the swap partition, consuming endless CPU. It’s definitely doing _something_ in userspace, but I’m not sure what, and it’s hard to find out. I’ve heard other reports of faulty MIPS emulation recently, too. I know how to debug this sort of thing, but it’s really more time-consuming than I can manage now :-(

While waiting for builds in that, I resolved to try reproducing a nasty kernel bug in qemu for x86-64: since I booted into 2.6.19-rc1 all my coredumps have been truncated very short. My normal hardware kernel boots OK, but if I rebuild the kernel with the default config and debug info, it doesn’t:

checking if image is initramfs…it isn’t (bad gzip magic numbers); looks like an initrd
Freeing initrd memory: 5498k freed
*hang*

And the other thing that’s apparently not been getting a lot of love lately is the debugging stub; if I attach GDB, it dies much earlier, so I can’t set a breakpoint at initramfs detection to see what’s going on.

Overall result for the day: Argh!