On Sun, 20 Sep 2020 at 19:37, roger <roger@beardandsandals.co.uk> wrote:
The only other thing I see at the start of the boot process is the scsi device driver timing out, and giving warning stack traces.
sym53c8xx 0000:00:0c.0: enabling device (0100 -> 0103)
sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 66
sym0: No NVRAM, ID 7, Fast-40, ??, parity checking
random: fast init done
CACHE TEST FAILED: timeout.
sym0: CACHE INCORRECTLY CONFIGURED.
sym0: giving up ...
------------[ cut here ]------------
This is your problem, I think -- the new kernel fails to correctly
init the SCSI adaptor, and so it never sees the disk, and then
later the kernel panics becasue you told it to use a disk that's
not there. It's identified the adaptor, so your command line is
correct. This looks like it's going to either be a bug in QEMU's
emulation of the scsi card or in the kernel's driver for it.
Googling for the error message I find an email from Paolo
from 2015 (about a similar but not identical failure) advising
that this particular SCSI controller is not a good one to use
because its emulation is incomplete and it's slow:
https://lists.cs.columbia.edu/pipermail/kvmarm/2015-April/014380.html
So my suggestions:
(1) if you're not using a current QEMU you could try using
the latest version to see if this particular bug has been
fixed
(2) you could try changing your commandline to explicitly
plug in a better-supported SCSI controller rather than
relying on the lsi53c8xx that the versatilepb board
will give you by default. Using a virtio disk device
of some form is usually the best choice, assuming the
drivers have been compiled into your guest kernel.
thanks
-- PMM