Has anyone successfully installed Fedora 36 s390x, in particular under the Hercules 390 emulator? If you have can you please share the secret of your success.
I successfully installed Fedora 30 s390x several years ago, but with every release since then I have had nothing but failure.
Ian
Hi Ian,
On Wed, 05 Oct 2022 15:25:25 -0000 "Ian Shorter" ian@iarosh.com wrote:
Has anyone successfully installed Fedora 36 s390x, in particular under the Hercules 390 emulator? If you have can you please share the secret of your success.
I successfully installed Fedora 30 s390x several years ago, but with every release since then I have had nothing but failure.
what hercules version do you use?
If you are on Linux, then I would recommend to use the standard libvirt based tools (virt-manager with qemu) to install Fedora/s390x.
Dan
Hello Dan,
I am on Linux (Fedora 36 x86), and I have used libvirt to install Fedora s390x, and it works well.
However, as I contribute to Hercules development, I would like to be able to install Fedora s390x under Hercules, but I haven't succeeded for several years. I am currently using SDL Hercules 4.
I do have Fedora 36 s390x running under Hercules, but those Fedora's have been dnf system-upgrade'd with each new Fedora since the last time I was able to do a successful install.
From your reply I infer that no one on the Fedora side bothers with Hercules any more, any effort is directed towards libvirt?
Ian
On Thu, 06 Oct 2022 07:01:46 -0000 "Ian Shorter" ian@iarosh.com wrote:
Hello Dan,
I am on Linux (Fedora 36 x86), and I have used libvirt to install Fedora s390x, and it works well.
However, as I contribute to Hercules development, I would like to be able to install Fedora s390x under Hercules, but I haven't succeeded for several years. I am currently using SDL Hercules 4.
I am not aware of anything that should intentionally break running Fedora under an emulator. SDL Hercules should run zEC12 (or now z13) code just fine.
Unless there is now more emulation of the HMC in Hercules, so it could install from an ISO image directly, then the crucial part is networking as even the actual installer is downloaded from a server.
What is the problem you are hitting?
I do have Fedora 36 s390x running under Hercules, but those Fedora's have been dnf system-upgrade'd with each new Fedora since the last time I was able to do a successful install.
From your reply I infer that no one on the Fedora side bothers with Hercules any more, any effort is directed towards libvirt?
the Fedora/s390x team (and the community as well) is very small, thus our focus is on running on real hardware, because that's what is required on the enterprise side.
Dan
I also suspect the problem is networking.
QETH. Using qeth I can often get the install as far as starting anaconda, which will start downloading the packages. The download of, usually, the first package stalls.
CTCM. Using ctcm the install never works, because although the interface is created it is not given an IP address, hence the interface is completely useless. This is a problem with my running f36's, and has been for a few releases, one has to logon and manually add the IP address whereupon the ctcm interface works.
LCS. Using lcs the install never works, but it's been ages since I tried lcs and I can't remember why it doesn't work.
The downloads are from a second machine on my LAN that runs an Apache server.
Ian
On Thu, 06 Oct 2022 08:39:37 -0000 "Ian Shorter" ian@iarosh.com wrote:
I also suspect the problem is networking.
QETH. Using qeth I can often get the install as far as starting anaconda, which will start downloading the packages. The download of, usually, the first package stalls.
I suspect this will be caused by some missing bits in the QETH emulation, because QETH is now used almost exclusively with real hw ... Does only the download stall and the system is still reachable over network?
CTCM. Using ctcm the install never works, because although the interface is created it is not given an IP address, hence the interface is completely useless. This is a problem with my running f36's, and has been for a few releases, one has to logon and manually add the IP address whereupon the ctcm interface works.
I think it should be possible to fix that. There were some changes how the installer sets up the network in the past and there might be bugs as no one test CTCM. What is your initial parameter file? Does it fail to even download the install.img or does lose the IP a bit later?
LCS. Using lcs the install never works, but it's been ages since I tried lcs and I can't remember why it doesn't work.
yes, this is unlikely to work, it was the least tested/used variant
Dan
I suspect this will be caused by some missing bits in the QETH emulation, ...
Yes, me too. I think the QETH emulation might need to respond to ARP packets.
... Does it fail to even download the install.img or does lose the IP a bit later?
No, there is no network activity at all, the IP is never set.
It would be good if CTCM were fixed, imho CTC is still the simplest and most reliable network interface in Hercules. Though as I said it isn't just the installer, an installed Fedora s390x has the same problem. Things have got better over the past few releases, in 34/35 the CTC wasn't even activated, one had to use znetconf.
Ian
On Thu, 2022-10-06 at 12:54 +0000, Ian Shorter wrote:
I suspect this will be caused by some missing bits in the QETH emulation, ...
Yes, me too. I think the QETH emulation might need to respond to ARP packets.
... Does it fail to even download the install.img or does lose the IP a bit later?
No, there is no network activity at all, the IP is never set.
A packet trace of QETH would be helpful in understand what exactly is failing. Hercules uses a tuntap as its interface so you will need to set up routing between the tuntap interface and the host system's Ethernet interface.
The other option is to bridge the tuntap interface directly to the host's physical Ethernet interface.
There are also trace options within Hercules to trace more closely the communication between the guest (Fedora) and the QETH emulation in Hercules.
Is it apparent whether the QETH interface is Layer-3 or Layer-2?
I am suspecting though, Ian, you are already aware of these options.
Harold Grovesteen
It would be good if CTCM were fixed, imho CTC is still the simplest and most reliable network interface in Hercules. Though as I said it isn't just the installer, an installed Fedora s390x has the same problem. Things have got better over the past few releases, in 34/35 the CTC wasn't even activated, one had to use znetconf.
Ian _______________________________________________ s390x mailing list -- s390x@lists.fedoraproject.org To unsubscribe send an email to s390x-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/s390x@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Thu, 06 Oct 2022 12:54:02 -0000 "Ian Shorter" ian@iarosh.com wrote:
I suspect this will be caused by some missing bits in the QETH emulation, ...
Yes, me too. I think the QETH emulation might need to respond to ARP packets.
... Does it fail to even download the install.img or does lose the IP a bit later?
No, there is no network activity at all, the IP is never set.
It would be good if CTCM were fixed, imho CTC is still the simplest and most reliable network interface in Hercules. Though as I said it isn't just the installer, an installed Fedora s390x has the same problem. Things have got better over the past few releases, in 34/35 the CTC wasn't even activated, one had to use znetconf.
I think we should be able to fix that. What are your network parameters in the "parameter" file? Is the CTC device correctly un-ignored during the boot, like visible in "lscss" or "ls /sys/bus/ccw" output?
Dan
The *lscss* command output was:
``` Device Subchan. DevType CU Type Use PIM PAM POM CHPIDs ---------------------------------------------------------------------- 0.0.0130 0.0.0000 3390/0c 3990/c2 yes 80 80 ff 01000000 00000000 0.0.0600 0.0.0001 3088/01 3088/08 yes 80 80 ff 06000000 00000000 0.0.0601 0.0.0002 3088/01 3088/08 yes 80 80 ff 06000000 00000000 ```
The *ls /sys/bus/ccw* command output was:
``` devices drivers drivers_autoprobe drivers_probe uevent ```
The output from a *znetconf -c* command was:
``` Device IDs Type Card Type CHPID Drv. Name State ------------------------------------------------------------------------------------- 0.0.0600,0.0.0601 3088/08 CTC/A ctcm slc600 online ```
The output from an *ip addr* command was:
``` 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: slc600: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 32760 qdisc fq_codel state UNKNOWN group default qlen 100 link/slip ```
After issuing an *ip addr add dev slc600 192.168.249.3 peer 192.168.249.4/26* command, the output from an *ip addr* command became:
``` 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: slc600: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 32760 qdisc fq_codel state UNKNOWN group default qlen 100 link/slip inet 192.168.249.3 peer 192.168.249.4/26 scope global slc600 valid_lft forever preferred_lft forever ```
Ian
On Wed, 12 Oct 2022 16:06:38 -0000 "Ian Shorter" ian@iarosh.com wrote:
The *lscss* command output was:
Device Subchan. DevType CU Type Use PIM PAM POM CHPIDs ---------------------------------------------------------------------- 0.0.0130 0.0.0000 3390/0c 3990/c2 yes 80 80 ff 01000000 00000000 0.0.0600 0.0.0001 3088/01 3088/08 yes 80 80 ff 06000000 00000000 0.0.0601 0.0.0002 3088/01 3088/08 yes 80 80 ff 06000000 00000000The *ls /sys/bus/ccw* command output was:
devices drivers drivers_autoprobe drivers_probe ueventThe output from a *znetconf -c* command was:
Device IDs Type Card Type CHPID Drv. Name State ------------------------------------------------------------------------------------- 0.0.0600,0.0.0601 3088/08 CTC/A ctcm slc600 onlineThe output from an *ip addr* command was:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: slc600: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 32760 qdisc fq_codel state UNKNOWN group default qlen 100 link/slip
this looks like the low level setup (un-ignoring, pairing 0600 + 0601) works well, but the problem is in NetworkManager not being able to set the IP address.
Could you share your /etc/NetworkManager/system-connections/*.nmconnection ? Probably will be named slc600.nmconnection
Dan
Could you share ...
I assume you meant when the install eventually drops into the maintenance shell? If so, then:
11:50:07 ls -l /etc/NetworkManager/system-connections/ 11:50:07 ls: cannot access '/etc/NetworkManager/system-connections/': No such file or directory
The /etc directory contains:
11:50:39 ls -l /etc 11:50:39 total 784 11:50:39 drwxr-xr-x 2 root root 60 Mar 30 2022 authselect 11:50:39 -rw-r--r-- 1 root root 34 Oct 15 09:12 ccw.conf 11:50:39 drwxrwxr-x 2 root root 120 Oct 15 09:13 cmdline.d 11:50:39 drwxr-xr-x 2 root root 60 Mar 30 2022 cmsfs-fuse 11:50:39 drwxrwxr-x 2 root root 60 Mar 30 2022 conf.d 11:50:39 -rw-r--r-- 1 root root 9 Oct 15 09:13 dasd.conf 11:50:39 drwxr-xr-x 7 root root 140 Mar 30 2022 dbus-1 11:50:39 -rw-rw-r-- 1 root root 236 Mar 30 2022 fipsmodules 11:50:39 -rw-rw-r-- 1 root root 0 Mar 30 2022 fstab.empty 11:50:39 -rw-r--r-- 1 root root 38 Jan 20 2022 fuse.conf 11:50:39 -rw-rw-r-- 1 root root 298 Oct 15 09:12 group 11:50:39 -rw-rw-r-- 1 root root 273 Mar 30 2022 group- 11:50:39 ---------- 1 root root 21 Oct 15 09:12 gshadow 11:50:39 -rw-r--r-- 1 root root 5799 Mar 2 2022 idmapd.conf 11:50:39 lrwxrwxrwx 1 root root 25 Mar 30 2022 initrd-release -> ../usr/lib/initrd-release 11:50:39 drwxr-xr-x 2 root root 60 Mar 30 2022 iscsi 11:50:39 -rw-r--r-- 1 root root 7111 Mar 30 2022 ld.so.cache 11:50:39 -rw-r--r-- 1 root root 28 Feb 28 2022 ld.so.conf 11:50:39 drwxr-xr-x 2 root root 60 Mar 30 2022 ld.so.conf.d 11:50:39 drwxr-xr-x 2 root root 40 Oct 15 09:22 lvm 11:50:39 -rw-rw-r-- 1 root root 33 Oct 15 09:12 machine-id 11:50:39 drwxr-xr-x 2 root root 100 Oct 15 09:13 modprobe.d 11:50:39 lrwxrwxrwx 1 root root 17 Mar 30 2022 mtab -> /proc/self/mounts 11:50:39 drwx------ 2 root root 60 Oct 15 09:13 multipath 11:50:39 -rw-rw-r-- 1 root root 121 Mar 30 2022 multipath.conf 11:50:39 -rw-r--r-- 1 root root 767 Jan 20 2022 netconfig 11:50:40 lrwxrwxrwx 1 root root 24 Mar 30 2022 nsswitch.conf -> authselect/nsswitch.conf 11:50:40 lrwxrwxrwx 1 root root 14 Mar 30 2022 os-release -> initrd-release 11:50:40 -rw-rw-r-- 1 root root 365 Oct 15 09:12 passwd 11:50:40 -rw-rw-r-- 1 root root 311 Mar 30 2022 passwd- 11:50:40 drwxr-xr-x 4 root root 80 Mar 30 2022 pki 11:50:40 drwxr-xr-x 2 root root 60 Mar 30 2022 plymouth 11:50:40 -rw-r--r-- 1 root root 23 Oct 15 09:22 profile 11:50:40 -rw-r--r-- 1 root root 6568 Jul 16 2021 protocols 11:50:40 drwxr-xr-x 3 root root 80 Mar 30 2022 rdma 11:50:40 -rw-r--r-- 1 root root 1634 Feb 25 2022 rpc 11:50:40 -rw-r--r-- 1 root root 701745 Jul 16 2021 services 11:50:40 ---------- 1 root root 20 Oct 15 09:12 shadow 11:50:40 drwxr-xr-x 2 root root 60 Mar 30 2022 sysconfig 11:50:40 lrwxrwxrwx 1 root root 25 Mar 30 2022 system-release -> ../usr/lib/fedora-release 11:50:40 drwxr-xr-x 3 root root 80 Mar 30 2022 systemd 11:50:40 drwxr-xr-x 3 root root 80 Mar 30 2022 udev 11:50:40 -rw-r--r-- 1 root root 24 Feb 16 2022 vconsole.conf 11:50:40 -rw-r--r-- 1 root root 1183 Mar 25 2022 virc 11:50:40 drwxr-xr-x 4 root root 100 Mar 30 2022 zkey
NM appears to know the CTC is there:
11:58:44 nmcli c 11:58:44 NAME UUID TYPE DEVICE [m 11:58:44 slc600 56949a46-55fc-4487-9e44-be07d3e94f32 ethernet -- [m 11:58:44 [K
11:59:20 nmcli d 11:59:21 DEVICE TYPE STATE CONNECTION 11:59:21 [2mslc600[0m [2methernet[0m [2munavailable[0m [2m--[0m 11:59:21 [2mlo[0m [2mloopback[0m [2munmanaged[0m [2m--[0m
Be nice if the install just worked -unix script -herc script -ipl installxx
many thanks dc
On 2022-10-06 4:39 a.m., Ian Shorter wrote:
I also suspect the problem is networking.
QETH. Using qeth I can often get the install as far as starting anaconda, which will start downloading the packages. The download of, usually, the first package stalls.
CTCM. Using ctcm the install never works, because although the interface is created it is not given an IP address, hence the interface is completely useless. This is a problem with my running f36's, and has been for a few releases, one has to logon and manually add the IP address whereupon the ctcm interface works.
LCS. Using lcs the install never works, but it's been ages since I tried lcs and I can't remember why it doesn't work.
The downloads are from a second machine on my LAN that runs an Apache server.
Ian _______________________________________________ s390x mailing list -- s390x@lists.fedoraproject.org To unsubscribe send an email to s390x-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/s390x@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Thu, 13 Oct 2022 11:50:38 -0400 dell-edward dell.coleman@gmail.com wrote:
Be nice if the install just worked -unix script -herc script -ipl installxx
there is nothing that prevents that, the installer can run unattended and some just needs to add the Hercules bits around it
Dan
many thanks dc
On 2022-10-06 4:39 a.m., Ian Shorter wrote:
I also suspect the problem is networking.
QETH. Using qeth I can often get the install as far as starting anaconda, which will start downloading the packages. The download of, usually, the first package stalls.
CTCM. Using ctcm the install never works, because although the interface is created it is not given an IP address, hence the interface is completely useless. This is a problem with my running f36's, and has been for a few releases, one has to logon and manually add the IP address whereupon the ctcm interface works.
LCS. Using lcs the install never works, but it's been ages since I tried lcs and I can't remember why it doesn't work.
The downloads are from a second machine on my LAN that runs an Apache server.
Ian _______________________________________________ s390x mailing list -- s390x@lists.fedoraproject.org To unsubscribe send an email to s390x-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/s390x@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
s390x mailing list -- s390x@lists.fedoraproject.org To unsubscribe send an email to s390x-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/s390x@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-
Dan Horák -
dell-edward -
Harold Grovesteen -
Ian Shorter