Instrutions for installing Fedora 20 in Hercules

[Dan Horák]

On Mon, 13 Jan 2014 08:39:27 -0500
Robert Knight <knight at 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:
> 
> 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.

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)

> 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.

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
 
> 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

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
 
> 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.

I've updated the kickstart with this change, thanks for the idea


		Dan