Hi,
I've finished the instructions for installing Fedora 20 in Hercules, please read http://sharkcz.livejournal.com/12268.html if you want to follow the process. If not, the blog contains also a link where you can download the resulting image.
Dan
I add my thanks to Wayne's for this valuable description. For me, it's the first one that has worked without change.
The rest of this message is just details of what I saw during the installation and a trick to avoid a large log file.
I ran it on a Fedora 20 system, using iptables-services, rather than firewalld, with hercules-3.09-1.fc20.x86_64 .
As you said in the blog, it takes a long time. For me, these were the red herrings that made me suspect that a failure had occurred:
1. Early on in the installation a new (for me, anyway) error was reported:
dracut-initqueue 567!: arping: Device ctc0 not available.
As I had initially broken networking by adding an unnecessary iptables rule, this lead to a futile attempt to diagnose why this had arisen. It is, however, just a new item that looks like a problem but is not.
2. There is a service called dnf-makecache that eventually fails before the installer starts. We see:
K 1;31mFAILED 0m! Failed to start dnf makecache. See 'systemctl status dnf-makecache.service' for details.
This seems to happen consistently, at least, on the 8 installations that I tried. From some of the bugzilla entries, it looks like this may download and additional 75 meg if it actually was working.
3. Once the installer had started, it displayed:
anaconda 1071!: Creating ext4 on /dev/mapper/Fedora-Root
and then just sat and apparently spun. Hercules shows instruction counts in the main console and this occurred around 50 billion instructions. There was no output for over an additional 50 billion instructions.
4. My guess is that the anaconda console output is buffered. This results in bursts of lists of packages installed, interspersed with long periods with no output, but obvious activity. My previous experience with the x86_64, ARM and PPC installers had lead me to expect a steady progression of installation messages, but that's not the case with s390x. This was only concerning when my old friend dnf makecache reappeared with:
Starting dnf makecache... 1;31mFAILED 0m! Failed to start dnf makecache. See 'systemctl status dnf-makecache.service' for details.
in the middle of the package installation list, followed, naturally, with a very long pause.
5. Unless I missed something, the message that is shown in step 13 of the blog entry, i.e.:
HHCCP014I CPU0000: Operand exception CODE=0015 ILC=4 CPU0000: PSW=00001000 80000000 00000000001167F0 INST=B232D116 MSCH 278(13) modify_subchannel
will be repeated endlessly until it is stopped by a Hercules command such as "quit". This seemed to happen even when I changed the permissions on /sys/firmware/reipl/ccw/loadparm, as suggested in step 12. One of my experiments, when I had to leave the house for a while, resulted in a 60 GB log file of (mostly) that message.
I tried a version of the kickstart with "reboot" replace by "poweroff" and that seemed to work.
Cheers!
On Mon, 13 Jan 2014 08:39:27 -0500 Robert Knight knight@princeton.edu wrote:
I add my thanks to Wayne's for this valuable description. For me, it's the first one that has worked without change.
nice to hear, thanks :-)
The rest of this message is just details of what I saw during the installation and a trick to avoid a large log file.
I ran it on a Fedora 20 system, using iptables-services, rather than firewalld, with hercules-3.09-1.fc20.x86_64 .
As you said in the blog, it takes a long time. For me, these were the red herrings that made me suspect that a failure had occurred:
- Early on in the installation a new (for me, anyway) error was
reported:
dracut-initqueue 567!: arping: Device ctc0 not available.
As I had initially broken networking by adding an unnecessary iptables rule, this lead to a futile attempt to diagnose why this had arisen. It is, however, just a new item that looks like a problem but is not.
this is fine, I think it's because the CTC interface as a point-to-point link doesn't support the ARP protocol (as opposed to eg. qeth)
- There is a service called dnf-makecache that eventually fails
before the installer starts. We see:
K 1;31mFAILED 0m! Failed to start dnf makecache. See 'systemctl status dnf-makecache.service' for details.
This seems to happen consistently, at least, on the 8 installations that I tried. From some of the bugzilla entries, it looks like this may download and additional 75 meg if it actually was working.
yeah, I see these too, but haven't found the reason yet, can be just because running in Hercules makes it very slow and systemd considers it as an error during start-up
- Once the installer had started, it displayed:
anaconda 1071!: Creating ext4 on /dev/mapper/Fedora-Root
and then just sat and apparently spun. Hercules shows instruction counts in the main console and this occurred around 50 billion instructions. There was no output for over an additional 50 billion instructions.
- My guess is that the anaconda console output is buffered. This
results in bursts of lists of packages installed, interspersed with long periods with no output, but obvious activity. My previous
there should be activity visible in the TUI interface (after pressing Esc), where you can see the 0600 interface blinking
experience with the x86_64, ARM and PPC installers had lead me to expect a steady progression of installation messages, but that's not the case with s390x. This was only concerning when my old friend dnf makecache reappeared with:
Starting dnf makecache...1;31mFAILED 0m! Failed to start dnf makecache. See 'systemctl status dnf-makecache.service' for details.
in the middle of the package installation list, followed, naturally, with a very long pause.
yes, it will be some output buffering in Anaconda, it looks the same on real HW, first nothing, then 100 packages, then another, etc
- Unless I missed something, the message that is shown in step 13
of the blog entry, i.e.:
HHCCP014I CPU0000: Operand exception CODE=0015 ILC=4 CPU0000: PSW=00001000 80000000 00000000001167F0 INST=B232D116 MSCH 278(13) modify_subchannel
will be repeated endlessly until it is stopped by a Hercules command such as "quit". This seemed to happen even when I changed the permissions on /sys/firmware/reipl/ccw/loadparm, as suggested in step 12. One of my experiments, when I had to leave the house for a while, resulted in a 60 GB log file of (mostly) that message.
I tried a version of the kickstart with "reboot" replace by "poweroff" and that seemed to work.
I've updated the kickstart with this change, thanks for the idea
Dan
-
Dan Horák -
Robert Knight