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 -
Some comments inline.
>
> a) If I boot up the machine with a debian9 (daily build) kernel using the
> following comamnd line:
>
> qemu-system-s390x.exe -machine type=s390-ccw-virtio-2.5 -m 512 -hda
> linux.disk -device virtio-net-ccw,netdev=net0 -netdev user,id=net0 -k en-us
> -redir tcp:9022::22
>
> The VM will boot with issues initializing the virtio devices for the disk
> and the networking...looks to be a regression.
>
> b) If I boot up the machine with a debian8 (stable) kernel using the
> following comamnd line:
>
> qemu-system-s390x.exe -machine type=s390-ccw-virtio-2.5 -m 512 -kernel
> kernel.debian8 -initrd initrd.debian8 -hda linux.disk -device
> virtio-net-ccw,netdev=net0 -netdev user,id=net0 -k en-us -redir tcp:9022::22
>
> The VM will boot with no problems, see the virtio hard drive and the
> networking.
>
> 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?
>
> 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.
>
> Note that the peripherals are virtio-blk-s390 and virtio-net-s390 instead of
> being ccw devices. The install went seemingly well, everything went to
> /dev/vda1, zipl ran, and after the install was complete the QEMU session
> completed with no issues. I would assume that I can remove the
> kernel/initrd parameters on QEMU and it should IPL directly into Debian.
> HOWEVER, after the install when I tried to run the installed VM, I ran this:
>
> qemu-system-s390x.exe -machine type=s390-virtio -m 512 -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
>
> QEMU starts up, shows up with a blank console and then no discernable
> suggestion that it did anything.
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.
>
> Well, so what I did was to modify the command line to this:
>
> qemu-system-s390x.exe -machine type=s390-ccw-virtio-2.5 -m 512 -hda
> linux.disk -device virtio-net-ccw,netdev=net0 -netdev user,id=net0 -k en-us
> -redir tcp:9022::22
>
> Which remarkably enough worked. The console renders the usual Linux boot
> sequence, and it worked until it tried to mount the root filesystem, in
> which case it looks like the kernel commandline (/proc/cmdline) expected
> root=/dev/disk/by-path/ccw-virtio0-part1
>
> However, since the machine booted with ccw peripherals, the disk is now:
> /dev/disk/by-path/ccw-0.0.0001-part1 (which is a symlink to ../../vda1)
>
> This will result in the init process bombing out to an initramfs mini-shell
> with a failure to find the root.
>
> This is a relatively easy fix since all I had to do is to make a symlink:
>
> cd /dev/disk/by-path/
> ln -s ../../vda1 ccw-virtio0-part1
>
> And then exit the initramfs, in which case the init process re-initializes.
> This time, the correct rootfs is referenced so init runs to completion and
> brings up Debian.
>
> That being said, I tried to correct the issue by running zipl. However,
> this time I run into an error:
>
> Error: Assume disk_type FBA for virtblk device, but please specify type
> manually: Virtblk device type not clearly determined.
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)
> I am not sure how the original Debian install process ran zipl during the
> initial install, but how would I specify the proper type for zipl?
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Philipp Kern [mailto:pkern@debian.org]
> Sent: Wednesday, November 04, 2015 3:22 AM
> To: kkwan.nyc@gmail.com
> Cc: debian-s390@lists.debian.org
> Subject: RE: specifying virtio block device as root filesystem for Debian
> S390X install?
>
> On 2015-11-04 05:23, Kevin Kwan (Personal) wrote:
>> If I use the CCW version:
>>
>> qemu-system-s390x.exe -machine type=s390-ccw-virtio-2.5 -m 512 -hda
>> linux.disk -device virtio-net-ccw,netdev=net0 -netdev user,id=net0 -k
>> en-us -redir tcp:9022::22
>>
>
> I just use -nographic on Linux and it does the right thing.
>
>> Then I'll see a console, followed by some complaints about missing
>> /sys/bus/ccw/devices/virtio/cutype (sysfs not populating info on the
>> CCW
>> bus?)
>
> Can you transcribe the actual failure you see?
>
> Kind regards
> Philipp Kern
>
>
Reply to: