Hello list!
About a year ago, Viktor Mihajovski pointed out, that the virtio net
modules (and deoendencies) are missing, this is still the case.

For an installation to work via virt-install, you have to manually add failover.ko, net_failover.ko and virtio_net.ko (debian-10.9.0-s390x-netinst.iso) and set the right console (ttysclp0).

These seem like really easy additions to make things work again (adding
them to the image).

I‘ll put my workaround on of those wellknown portals during the day, for anyone who is interested.

Best,
Ben.

Hello list!<div dir="auto">About a year ago, Viktor Mihajovski pointed out, that the virtio net modules (and deoendencies) are missing, this is still the case.</div><div dir="auto"><br></div><div dir="auto">For an installation to work via virt-install,
you have to manually add failover.ko, net_failover.ko and virtio_net.ko (debian-10.9.0-s390x-netinst.iso) and set the right console (ttysclp0).</div><div dir="auto"><br></div><div dir="auto">These seem like really easy additions to make things work again
(adding them to the image).</div><div dir="auto"><br></div><div dir="auto">I‘ll put my workaround on of those wellknown portals during the day, for anyone who is interested.</div><div dir="auto"><br></div><div dir="auto">Best,</div><div dir="auto">Ben.<
/div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-04-26 08:35, Benjamin Zimmermann wrote:

About a year ago, Viktor Mihajovski pointed out, that the virtio net
modules (and deoendencies) are missing, this is still the case.

For an installation to work via virt-install, you have to manually add failover.ko, net_failover.ko and virtio_net.ko (debian-10.9.0-s390x-netinst.iso) and set the right console (ttysclp0).

How do you do the latter? console=ttysclp0? But presumably that's not
valid everywhere. Are you seeing the steal_ctty failure otherwise? In
what environment?

These seem like really easy additions to make things work again (adding
them to the image).

I already did that for the next release (https://salsa.debian.org/kernel-team/linux/-/merge_requests/262). Feel
free to propose something similar for stable.

I'll put my workaround on of those wellknown portals during the day,
for anyone who is interested.

Given that ~no-one works on Debian s390x, people will need to step up
and fix things in Debian.

Kind regards and thanks
Philipp Kern

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 26/04/2021 09:21, Philipp Kern wrote:

On 2021-04-26 08:35, Benjamin Zimmermann wrote:

About a year ago, Viktor Mihajovski pointed out, that the virtio net
modules (and deoendencies) are missing, this is still the case.

For an installation to work via virt-install, you have to manually add failover.ko, net_failover.ko and virtio_net.ko (debian-10.9.0-s390x-netinst.iso) and set the right console (ttysclp0).


How do you do the latter? console=ttysclp0? But presumably that's not valid everywhere. Are you seeing the steal_ctty failure otherwise? In what environment?

Yes.

$ sudo virt-install [...] --extra-args 'console=ttysclp0 [...]

I do see the 'steal_ctty failure' otherwise.

Environment is a z14 LPAR with Fedora 33:

$ virt-install --version

3.2.0

$ qemu-system-s390x --version

QEMU emulator version 5.1.0 (qemu-5.1.0-9.fc33)

Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers

$ uname -a

Linux zl01s001 5.10.19-200.fc33.s390x #1 SMP Fri Feb 26 16:05:49 UTC 2021
s390x s390x s390x GNU/Linux


These seem like really easy additions to make things work again (adding
them to the image).


I already did that for the next release ( https://salsa.debian.org/kernel-team/linux/-/merge_requests/262). Feel free
to propose something similar for stable.

I'll put my workaround on of those wellknown portals during the day, for
anyone who is interested.


Given that ~no-one works on Debian s390x, people will need to step up and
fix things in Debian.

Kind regards and thanks
Philipp Kern

For the sake of completeness, her my (little bit censored) working command line:

$ sudo virt-install --name foobar --ram 1536 --vcpus 2 --disk /dev/disk/by-path/ccw-0.0.XXXX --network network=some-intranet,portgroup=vlan-XXX --location /mnt/tmp/debian-10.9.0-s390x-netinst.iso --initrd-inject /mnt/tmp/debian-virtio-net-4.19.0-16-raw.tar.gz --extra-args
'console=ttysclp0 preseed/early_command="gunzip -c debian-virtio-net-4.19.0-16-raw.tar.gz | tar -x; insmod failover.ko; insmod net_failover.ko; insmod virtio_net.ko"'

With that, it is an installation as usual and works like a charm.


Best,

Ben.

<div>



<div></div></div><div>
<div>On 26/04/2021 09:21, Philipp Kern
wrote:<br>
</div>
<blockquote type="cite">On
2021-04-26 08:35, Benjamin Zimmermann wrote:
<br>
<blockquote type="cite">About a year ago, Viktor Mihajovski
pointed out, that the virtio net modules (and deoendencies) are
missing, this is still the case.
<br>
<br>
For an installation to work via virt-install, you have to
manually add failover.ko, net_failover.ko and virtio_net.ko
(debian-10.9.0-s390x-netinst.iso) and set the right console
(ttysclp0).
<br>
</blockquote>
<br>
How do you do the latter? console=ttysclp0? But presumably that&#39;s
not valid everywhere. Are you seeing the steal_ctty failure
otherwise? In what environment?
<br>
<br>
</blockquote>
<p>Yes.</p>
<p>$ sudo virt-install [...] <span>--extra-args &#39;console=ttysclp0
[...]</span></p>
<p><span>I do see the &#39;steal_ctty failure&#39; otherwise.</span></p>
</div><div><p><span>Environment is a z14 LPAR with Fedora 33:</span></p></div><div>
<p class="MsoNormal"><span lang="EN-US">$ virt-install --version</span></p>
<p class="MsoNormal"><span lang="EN-US">3.2.0</span></p>
<p class="MsoNormal"><span lang="EN-US">$ qemu-system-s390x
--version</span></p>
<p class="MsoNormal"><span lang="EN-US">QEMU emulator version 5.1.0
(qemu-5.1.0-9.fc33)</span></p>
<p class="MsoNormal"><span lang="EN-US">Copyright (c) 2003-2020
Fabrice Bellard and the QEMU Project developers</span></p>
<p class="MsoNormal"><span lang="EN-US">$ uname -a</span></p>
<p class="MsoNormal"><span lang="EN-US">Linux zl01s001
5.10.19-200.fc33.s390x #1 SMP Fri Feb 26 16:05:49 UTC 2021 s390x
s390x s390x GNU/Linux</span></p>
<p><span><br>
</span></p>
<blockquote type="cite">
<blockquote type="cite">These seem like really easy additions to
make things work again (adding them to the image).
<br>
</blockquote>
<br>
I already did that for the next release
(<a href="https://salsa.debian.org/kernel-team/linux/-/merge_requests/262" target="_blank">https://salsa.debian.org/kernel-team/linux/-/merge_requests/262</a>).
Feel free to propose something similar for stable.
<br>
<br>
<blockquote type="cite">I&#39;ll put my workaround on of those
wellknown portals during the day, for anyone who is interested.
<br>
</blockquote>
<br>
Given that ~no-one works on Debian s390x, people will need to step
up and fix things in Debian.
<br>
<br>
Kind regards and thanks
<br>
Philipp Kern
<br>
</blockquote>
<p>For the sake of completeness, her my (little bit censored)
working command line:</p>
<p><span>$ sudo virt-install --name foobar --ram 1536 --vcpus 2
--disk /dev/disk/by-path/ccw-0.0.XXXX --network
network=some-intranet,portgroup=vlan-XXX --location
/mnt/tmp/debian-10.9.0-s390x-netinst.iso --initrd-inject
/mnt/tmp/debian-virtio-net-4.19.0-16-raw.tar.gz --extra-args
&#39;console=ttysclp0 preseed/early_command=&quot;gunzip -c
debian-virtio-net-4.19.0-16-raw.tar.gz | tar -x; insmod
failover.ko; insmod net_failover.ko; insmod virtio_net.ko&quot;&#39;</span></p>
</div><div><p><span>With that, it is an installation as usual and works like a
charm.</span></p>
<p><span><br>
</span></p>
<p><span>Best,</span></p>
<p><span>Ben.<br>
</span></p>


</div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 26.04.21 10:52, Benjamin Zimmermann wrote:
$ sudo virt-install [...] --extra-args 'console=ttysclp0 [...]

I do see the 'steal_ctty failure' otherwise.

I'd be cool if someone from IBM could actually go and fix [1] in some
form or another. Valentin tried[2] to do that in the kernel and got told
off. Maybe the answer is to bring this to linux-390 but I don't actually
know.

I think technically what we want is "just" for /proc/consoles to do the
right thing or have a way to map console name to tty name.

Kind regards
Philipp Kern

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961056
[2] https://lkml.org/lkml/2020/5/19/854

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27.04.21 09:22, Philipp Kern wrote:

On 26.04.21 10:52, Benjamin Zimmermann wrote:
$ sudo virt-install [...] --extra-args 'console=ttysclp0 [...]

I do see the 'steal_ctty failure' otherwise.

I'd be cool if someone from IBM could actually go and fix [1] in some
form or another. Valentin tried[2] to do that in the kernel and got told
off. Maybe the answer is to bring this to linux-390 but I don't actually know.

I think we did not tell him to go away. It was just that the patch itself
has some downsides in that it can break existing howtos (that do contain console=tty0).

We could revisit the initial patch (I think we also need to change arch/s390/kernel/setup.c set_preferred_console) and then
we would need to test all possible combinations on LPAR, KVM, z/VM
and see if we could fixup existing documentation.

Would Valentin be willing to provide a new version that also touches
setup.c?

Or, as an alternative we could revisit Valentins initial patch for the installer.

I think technically what we want is "just" for /proc/consoles to do the
right thing or have a way to map console name to tty name.

Kind regards
Philipp Kern

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961056
[2] https://lkml.org/lkml/2020/5/19/854

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27.04.21 14:40, Valentin Vidic wrote:

On Tue, Apr 27, 2021 at 12:08:01PM +0200, Christian Borntraeger wrote:

I think we did not tell him to go away. It was just that the patch itself
has some downsides in that it can break existing howtos (that do contain
console=tty0).

We could revisit the initial patch (I think we also need to change
arch/s390/kernel/setup.c set_preferred_console) and then
we would need to test all possible combinations on LPAR, KVM, z/VM
and see if we could fixup existing documentation.

Would Valentin be willing to provide a new version that also touches
setup.c?

Sure, I can try to update that patch, but would probably only be able to
test it with KVM.

That is OK. I will try to test it then on LPAR and find someone that will test it on z/VM. Please remove the cc stable as I want to have this tested for
a while. Hopefully it only affects the ttysclp0 console, which is not the default console for z/VM and LPAR. We would at least need to change the
device driver and commands documentation. Anything else?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)