Okay, looks like there are more developments to this -> -----Original Message----- From: Christian Borntraeger [mailto:borntrae...@de.ibm.com] Sent: Friday, November 13, 2015 7:37 AM To: kkwan....@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?