RE: specifying virtio block device as root filesystem for Debian S390X install?
Okay, looks like there are more developments to this ->
-----Original Message-----
From: Christian Borntraeger [mailto:borntraeger@de.ibm.com]
Sent: Friday, November 13, 2015 7:37 AM
To: kkwan.nyc@gmail.com; debian-s390@lists.debian.org
Subject: Re: specifying virtio block device as root filesystem for Debian
S390X install?
On 11/04/2015 10:52 PM, Kevin Kwan (Personal) wrote:
> Okay, I think I figured out the gist of the problem -
> This being the Debian8 kernel/initrd environment, netcfg will be an
> issue down the line, since it would not allow you to proceed with a
> virtio NIC configure. This will need to be patched with installing
> the netcfg 1.13 or
> 1.134 udeb from the repo (1.13 is stable, 1.134 is testing/sid)
>
> Then all you conceivably have to do is to patch the dasd-postinst so
> the machine will allow you to proceed
So Debian 8 did support the s390-ccw-virtio machine and so should Debian 9
- which it does not. Correct?
Yes. However, it looks like qemu 2.4.50/qemu-windows build 20150922 has an
implementation of virtio-CCW
that does not play well with Debian 9, but was okay for 8. This behavior
was also observed for the qemu 2.4
package on the Debian unstable repo (so if you run qemu on stretch/sid, it's
doing that as well).
The newer release (2.4.90/qemu-windows build 20151105) seemed to have fixed
the problem. This means that if you
plan to run Debian 9 nightly it should have no problems. I am guessing that
if qemu on sid is going to 2.4.1 (or wait for 2.5
to drop before Christmas),it should work on Debian itself as well.
>
> c) Unfortunately, that was not the technique I chose on this install -
> the command line I used for the initial install was this:
>
> qemu-system-s390x.exe -machine type=s390-virtio -m 512 -kernel
> kernel.debian9 -initrd initrd.debian9 -drive
> file=linux.disk,if=none,id=disk0 -device
> virtio-blk-s390,drive=disk0,id=virtio-disk0 -device
> virtio-net-s390,netdev=net0 -netdev user,id=net0 -k en-us -redir
> tcp:9022::22
> this is actually the old deprecated s390 machine, which uses an virtio
transport that is more of a hack and not very well maintained. The default
machine changed > to s390-ccw-virtio in qemu 2.4.
Ah, yeah. The one that requires the s390-zipl.rom file to start up rather
than s390-ccw.img on the bundle. I was wondering why it looked like such a
one-off.
> Yes, the old virtio transport only supports loading a disk that was
prepared with a modified zipl (as provided in SLES11.2 or so). Only the
s390-ccw-virtio machine has a working IPL from disks.
Ah, looked like a bit of a hack.
> zipl cannot clearly determine if the underlying device is a scsi disk,
image file or FBA formatted DASD device. So it uses the (unlikely) FBA
setup. QEMU only understands the zipl and eckd format. So solve this, you
can force zipl to use the scsi layout, e.g. by adding
targetbase=/dev/vda
targetblocksize=512
targettype=SCSI
targetoffset=0
to /etc/zipl.conf
(or the command line parameters)
This was changed in s390-tools 1.26, which now defaults to the scsi boot
layout for virtio disks unless it finds a proper volume label (in that case
it will write and ECKD boot layout)
Okay, I was trying to figure out how to fix it, but then I already did a
full 8 install defining a straight-up CCW-based machine instead of
deprecated s390-virtio.
Good to know anyways.
Some other things to note is that defining the QEMU machine as SMP with CPU
> 1 will result in a lockup during init on both Debian 8 and 9 (it would
report the CPUs, initialize the random pool, but it won't/can't init the
CPUs). I think there are some new code drops on qemu 2.5 that is supposed
to address that. And frankly, I don't see the same issue in Hercules, so it
looks fine to me.
BTW, has anyone attempt to use Debian-s390x as a hypervisor for Hercules to
launch Debian-S390X within KVM, or is that either really broken, or does
that require z/VM? Any speculation as to whether it would work or not?
Reply to: