Is it better to use the IRC or this list when asking for help?
I'm unable to get past the IPL from the card reader with the Fedora 18 image with Hercules on Fedora 17 x86_64. It dies in dracut with the /dev/root not found message which is a catch-all for "something went wrong".
It would be my preference to use the CTC networking rather than the QETH networking, but only because I know that it works with the Fedora 14 image.
If there's a recipe for using QETH for Hercules, I'm certainly willing to do that.
Regards, Robert
Robert Knight píše v Ne 27. 01. 2013 v 16:47 -0500:
Is it better to use the IRC or this list when asking for help?
list is better because it's archived and searchable, but quick tips can be provided also on IRC
I'm unable to get past the IPL from the card reader with the Fedora 18 image with Hercules on Fedora 17 x86_64. It dies in dracut with the /dev/root not found message which is a catch-all for "something went wrong".
the problem here is that the install.img file with the root filesystem can't be retrieved because network doesn't work
It would be my preference to use the CTC networking rather than the QETH networking, but only because I know that it works with the Fedora 14 image.
There is a little bug [1] in dracut that prevents setting up a CTC interface, but I have a solution for it. I've fixed the dracut file and repackaged the initrd.img file containing the kernel's initramfs. Please see [2] in a while for the new initrd.img and also sample generic.prm.
Fedora 14 (and all < 17) used the old way for setting up the hardware, and I know CTC works with Fedora 16. Fedora 17 and newer uses dracut for setting up the hw and there can still be bugs.
And most likely there is a bug in parted making it impossible to use FBA disk, but ECKD should work.
If there's a recipe for using QETH for Hercules, I'm certainly willing to do that.
I'm also interested in a QETH config settings for Hercules :-)
Dan
[1] http://www.spinics.net/lists/linux-initramfs/msg03040.html [2] http://fedora.danny.cz/s390/fedora-18/
On 1/27/2013 5:11 PM, Dan Horák wrote:
Robert Knight píše v Ne 27. 01. 2013 v 16:47 -0500:
There is a little bug [1] in dracut that prevents setting up a CTC interface, but I have a solution for it. I've fixed the dracut file and repackaged the initrd.img file containing the kernel's initramfs. Please see [2] in a while for the new initrd.img and also sample generic.prm.
That new initramfs did fix the CTC networking problem. Thank you. And thanks for the generic.prm. It helped as well.
Fedora 14 (and all < 17) used the old way for setting up the hardware, and I know CTC works with Fedora 16. Fedora 17 and newer uses dracut for setting up the hw and there can still be bugs.
And most likely there is a bug in parted making it impossible to use FBA disk, but ECKD should work.
Unfortunately, there are still challenges with the new anaconda.
The first was that the VNC panel says that it's preparing with the little spinning circle forever. Logging into the installation, I can see that it is actually installing and that it has even finished. However, the GUI panel never changed.
The second was that it only put one partition on my (ECKD) DASD and it was an LVM container, so Hercules sat there spinning with no message but not booting. When I compared the new partitioning to the working Fedora 14 one, I reinstalled and specified standard partitioning. This produced three (/boot, swap and /) but this will not come up, either. It does boot, which is an advance, but stop after it has activated the network.
I'll continue the science and report.
Robert Knight píše v Út 29. 01. 2013 v 06:19 -0500:
On 1/27/2013 5:11 PM, Dan Horák wrote:
Robert Knight píše v Ne 27. 01. 2013 v 16:47 -0500:
There is a little bug [1] in dracut that prevents setting up a CTC interface, but I have a solution for it. I've fixed the dracut file and repackaged the initrd.img file containing the kernel's initramfs. Please see [2] in a while for the new initrd.img and also sample generic.prm.
That new initramfs did fix the CTC networking problem. Thank you. And thanks for the generic.prm. It helped as well.
Fedora 14 (and all < 17) used the old way for setting up the hardware, and I know CTC works with Fedora 16. Fedora 17 and newer uses dracut for setting up the hw and there can still be bugs.
And most likely there is a bug in parted making it impossible to use FBA disk, but ECKD should work.
Unfortunately, there are still challenges with the new anaconda.
The first was that the VNC panel says that it's preparing with the little spinning circle forever. Logging into the installation, I can see that it is actually installing and that it has even finished. However, the GUI panel never changed.
yeah, that's something I also observed, but only when running in Hercules, not on real iron. So I switched to using kickstarts (unattended installation), which also saves the cycles otherwise spent for doing GUI. I'll upload my files as samples.
The second was that it only put one partition on my (ECKD) DASD and it was an LVM container, so Hercules sat there spinning with no message but not booting. When I compared the new partitioning to the working Fedora 14 one, I reinstalled and specified standard partitioning. This produced three (/boot, swap and /) but this will not come up, either. It does boot, which is an advance, but stop after it has activated the network.
can you post the logs somewhere?
Dan
On 01/29/2013 07:41 AM, Dan Horák wrote:
yeah, that's something I also observed, but only when running in Hercules, not on real iron. So I switched to using kickstarts (unattended installation), which also saves the cycles otherwise spent for doing GUI. I'll upload my files as samples.
That would be welcome. I know that enough things have changed so that an old kickstart file might get me into trouble so I'd like to start with a known-working one.
The second was that it only put one partition on my (ECKD) DASD and it was an LVM container, so Hercules sat there spinning with no message but not booting. When I compared the new partitioning to the working Fedora 14 one, I reinstalled and specified standard partitioning. This produced three (/boot, swap and /) but this will not come up, either. It does boot, which is an advance, but stop after it has activated the network.
can you post the logs somewhere?
I can as soon as I understand whether you want the logs from the installation that created the unusable LVM one or the failing standard partitioning one. That second ones ends with
10:06:13 46.569884! EXT4-fs (dasda3): re-mounted. Opts: (null) 10:06:16 48.925978! ctcm: CTCM driver initialized 10:06:16 49.151379! lcs: Loading LCS driver 10:06:17 50.143046! dasdconf.sh Warning: 0.0.0120 is already online, not configuring 10:06:17 50.766355! Adding 2064380k swap on /dev/dasda2. Priority:-1 extents:1 acros 10:06:17 s:2064380k 10:06:18 51.857063! EXT4-fs (dasda1): mounted filesystem with ordered data mode. Opts 10:06:18 : (null) 10:06:23 56.551601! systemd-journald 267!: Received SIGUSR1 10:06:23 HHCCP040I CPI: System Type: LINUX Name: Sysplex: 10:06:32 65.790131! ip6_tables: (C) 2000-2006 Netfilter Core Team 10:06:33 66.073412! Ebtables v2.0 registered 10:06:34 67.831449! nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
At this point, it just sits there forever.
Regards, Robert
Robert Knight píše v Út 29. 01. 2013 v 10:31 -0500:
On 01/29/2013 07:41 AM, Dan Horák wrote:
yeah, that's something I also observed, but only when running in Hercules, not on real iron. So I switched to using kickstarts (unattended installation), which also saves the cycles otherwise spent for doing GUI. I'll upload my files as samples.
That would be welcome. I know that enough things have changed so that an old kickstart file might get me into trouble so I'd like to start with a known-working one.
uploaded to http://fedora.danny.cz/s390/fedora-18/
The second was that it only put one partition on my (ECKD) DASD and it was an LVM container, so Hercules sat there spinning with no message but not booting. When I compared the new partitioning to the working Fedora 14 one, I reinstalled and specified standard partitioning. This produced three (/boot, swap and /) but this will not come up, either. It does boot, which is an advance, but stop after it has activated the network.
can you post the logs somewhere?
I can as soon as I understand whether you want the logs from the installation that created the unusable LVM one or the failing standard partitioning one. That second ones ends with
both would be interesting
10:06:13 46.569884! EXT4-fs (dasda3): re-mounted. Opts: (null) 10:06:16 48.925978! ctcm: CTCM driver initialized 10:06:16 49.151379! lcs: Loading LCS driver 10:06:17 50.143046! dasdconf.sh Warning: 0.0.0120 is already online, not configuring 10:06:17 50.766355! Adding 2064380k swap on /dev/dasda2. Priority:-1 extents:1 acros 10:06:17 s:2064380k 10:06:18 51.857063! EXT4-fs (dasda1): mounted filesystem with ordered data mode. Opts 10:06:18 : (null) 10:06:23 56.551601! systemd-journald 267!: Received SIGUSR1 10:06:23 HHCCP040I CPI: System Type: LINUX Name: Sysplex: 10:06:32 65.790131! ip6_tables: (C) 2000-2006 Netfilter Core Team 10:06:33 66.073412! Ebtables v2.0 registered 10:06:34 67.831449! nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
At this point, it just sits there forever.
hmm, this is quite far I think, does the system respond to pings?
Dan
Robert Knight píše v Út 29. 01. 2013 v 10:31 -0500:
On 01/29/2013 07:41 AM, Dan Horák wrote:
yeah, that's something I also observed, but only when running in Hercules, not on real iron. So I switched to using kickstarts (unattended installation), which also saves the cycles otherwise spent for doing GUI. I'll upload my files as samples.
That would be welcome. I know that enough things have changed so that an old kickstart file might get me into trouble so I'd like to start with a known-working one.
The second was that it only put one partition on my (ECKD) DASD and it was an LVM container, so Hercules sat there spinning with no message but not booting. When I compared the new partitioning to the working Fedora 14 one, I reinstalled and specified standard partitioning. This produced three (/boot, swap and /) but this will not come up, either. It does boot, which is an advance, but stop after it has activated the network.
can you post the logs somewhere?
I can as soon as I understand whether you want the logs from the installation that created the unusable LVM one or the failing standard partitioning one. That second ones ends with
10:06:13 46.569884! EXT4-fs (dasda3): re-mounted. Opts: (null) 10:06:16 48.925978! ctcm: CTCM driver initialized 10:06:16 49.151379! lcs: Loading LCS driver 10:06:17 50.143046! dasdconf.sh Warning: 0.0.0120 is already online, not configuring 10:06:17 50.766355! Adding 2064380k swap on /dev/dasda2. Priority:-1 extents:1 acros 10:06:17 s:2064380k 10:06:18 51.857063! EXT4-fs (dasda1): mounted filesystem with ordered data mode. Opts 10:06:18 : (null) 10:06:23 56.551601! systemd-journald 267!: Received SIGUSR1 10:06:23 HHCCP040I CPI: System Type: LINUX Name: Sysplex: 10:06:32 65.790131! ip6_tables: (C) 2000-2006 Netfilter Core Team 10:06:33 66.073412! Ebtables v2.0 registered 10:06:34 67.831449! nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
At this point, it just sits there forever.
seems my attempt ends with the same messages ...
Dan
On 01/29/2013 12:59 PM, Dan Horák wrote:
Robert Knight píše v Út 29. 01. 2013 v 10:31 -0500:
At this point, it just sits there forever.
seems my attempt ends with the same messages ...
So, I stuck a user "install" into that kickstart (f18-part.ks) so that I could interact with the install. While the logs to seem to show that things ended successfully, on the installer screen, I see:
Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 91, in run threading.Thread.run(self, *args, **kwargs) File "/usr/lib64/python2.7/threading.py", line 504, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 135, in doInstall writeBootLoader(storage, payload, instClass, ksdata) File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2312, in writeBootLoader storage.bootloader.write() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 952, in write self.install() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2070, in install message = iutil.reIPL(self.stage1_name) File "/usr/lib64/python2.7/site-packages/pyanaconda/iutil.py", line 892, in reIPL for disk in anaconda.storage.disks: NameError: global name 'anaconda' is not defined
wherein it had tried a "chreipl" and it had failed. I don't believe there's more to do at this point. lsreipl shows the expected device already set up. There are two more processes with /mnt/sysimage, one being anaconda and the other bash.
I guess I'll try hacking the iutil.py file before things start...
Robert Knight píše v Út 29. 01. 2013 v 15:50 -0500:
On 01/29/2013 12:59 PM, Dan Horák wrote:
Robert Knight píše v Út 29. 01. 2013 v 10:31 -0500:
At this point, it just sits there forever.
seems my attempt ends with the same messages ...
So, I stuck a user "install" into that kickstart (f18-part.ks) so that I could interact with the install. While the logs to seem to show that things ended successfully, on the installer screen, I see:
Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 91, in run threading.Thread.run(self, *args, **kwargs) File "/usr/lib64/python2.7/threading.py", line 504, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 135, in doInstall writeBootLoader(storage, payload, instClass, ksdata) File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2312, in writeBootLoader storage.bootloader.write() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 952, in write self.install() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2070, in install message = iutil.reIPL(self.stage1_name) File "/usr/lib64/python2.7/site-packages/pyanaconda/iutil.py", line 892, in reIPL for disk in anaconda.storage.disks: NameError: global name 'anaconda' is not defined
hm, same problem as https://bugzilla.redhat.com/show_bug.cgi?id=904245 that I ascribed to the use of FBA disk originally, but got it today also with CKD (all in Hercules). There seems to be a difference between real iron and Hercules ...
wherein it had tried a "chreipl" and it had failed. I don't believe there's more to do at this point. lsreipl shows the expected device already set up. There are two more processes with /mnt/sysimage, one being anaconda and the other bash.
I guess I'll try hacking the iutil.py file before things start...
Dan
On 1/29/2013 4:39 PM, Dan Horák wrote:
Robert Knight píše v Út 29. 01. 2013 v 15:50 -0500:
On 01/29/2013 12:59 PM, Dan Horák wrote:
Robert Knight píše v Út 29. 01. 2013 v 10:31 -0500:
At this point, it just sits there forever.
seems my attempt ends with the same messages ...
So, I stuck a user "install" into that kickstart (f18-part.ks) so that I could interact with the install. While the logs to seem to show that things ended successfully, on the installer screen, I see:
Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 91, in run threading.Thread.run(self, *args, **kwargs) File "/usr/lib64/python2.7/threading.py", line 504, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 135, in doInstall writeBootLoader(storage, payload, instClass, ksdata) File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2312, in writeBootLoader storage.bootloader.write() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 952, in write self.install() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2070, in install message = iutil.reIPL(self.stage1_name) File "/usr/lib64/python2.7/site-packages/pyanaconda/iutil.py", line 892, in reIPL for disk in anaconda.storage.disks: NameError: global name 'anaconda' is not defined
hm, same problem as https://bugzilla.redhat.com/show_bug.cgi?id=904245 that I ascribed to the use of FBA disk originally, but got it today also with CKD (all in Hercules). There seems to be a difference between real iron and Hercules ...
That just a straight-up defect in the anaconda module iutil.py. There is no "anaconda" included. There are other places where there is "storage.disks" in the code, so I'm guessing (and will check some time tonight) that removing the "anaconda." prefix will make that failure go away.
wherein it had tried a "chreipl" and it had failed. I don't believe there's more to do at this point. lsreipl shows the expected device already set up. There are two more processes with /mnt/sysimage, one being anaconda and the other bash.
I guess I'll try hacking the iutil.py file before things start...
The bad news is that when this is fixed, we're going to see "Unable to set reIPL device to..." followed by this: "After shutdown, please perform a manual IPL from ... to continue installation.", so that's not what's keeping it from booting.
This module on which it appears likely to be stuck is for network tracking to make firewalls work, I believe. Could this just be the defect that your replacement initrd corrected?
Regards, Robert
On 1/29/2013 6:26 PM, Robert Knight wrote:
That just a straight-up defect in the anaconda module iutil.py. There is no "anaconda" included. There are other places where there is "storage.disks" in the code, so I'm guessing (and will check some time tonight) that removing the "anaconda." prefix will make that failure go away.
wherein it had tried a "chreipl" and it had failed. I don't believe there's more to do at this point. lsreipl shows the expected device already set up. There are two more processes with /mnt/sysimage, one being anaconda and the other bash.
I guess I'll try hacking the iutil.py file before things start...
The bad news is that when this is fixed, we're going to see "Unable to set reIPL device to..." followed by this: "After shutdown, please perform a manual IPL from ... to continue installation.", so that's not what's keeping it from booting.
Removing "anaconda." did allow the code to run, but
02:08:18,285 INFO program: Preparing boot device: dasda. 02:08:18,296 INFO program: Done. 02:08:18,341 INFO program: Running... chreipl node /dev/dasda 02:08:18,780 ERR program: chreipl: Could not open "reipl/ccw/loadparm" (Permission denied)
Robert Knight píše v Út 29. 01. 2013 v 22:18 -0500:
On 1/29/2013 6:26 PM, Robert Knight wrote:
That just a straight-up defect in the anaconda module iutil.py. There is no "anaconda" included. There are other places where there is "storage.disks" in the code, so I'm guessing (and will check some time tonight) that removing the "anaconda." prefix will make that failure go away.
strange is that it doesn't affect real iron installation ... although the can be difference between LPAR (that's what Hercules emulates) and z/VM guest.
wherein it had tried a "chreipl" and it had failed. I don't believe there's more to do at this point. lsreipl shows the expected device already set up. There are two more processes with /mnt/sysimage, one being anaconda and the other bash.
I guess I'll try hacking the iutil.py file before things start...
The bad news is that when this is fixed, we're going to see "Unable to set reIPL device to..." followed by this: "After shutdown, please perform a manual IPL from ... to continue installation.", so that's not what's keeping it from booting.
Removing "anaconda." did allow the code to run, but
02:08:18,285 INFO program: Preparing boot device: dasda. 02:08:18,296 INFO program: Done. 02:08:18,341 INFO program: Running... chreipl node /dev/dasda 02:08:18,780 ERR program: chreipl: Could not open "reipl/ccw/loadparm" (Permission denied)
the "reipl" step blocks other steps including setting up the network in the installed image, see https://bugzilla.redhat.com/show_bug.cgi?id=858996 IIRC the workaround is to copy the ifcfg-ctc0 file from /tmp to /mnt/sysimage/etc/sysconfig/network-scripts and also setting the root's password is needed after "chroot /mnt/sysimage"
Dan
On 1/30/2013 2:32 AM, Dan Horák wrote:
Robert Knight píše v Út 29. 01. 2013 v 22:18 -0500:
On 1/29/2013 6:26 PM, Robert Knight wrote:
That just a straight-up defect in the anaconda module iutil.py. There is no "anaconda" included. There are other places where there is "storage.disks" in the code, so I'm guessing (and will check some time tonight) that removing the "anaconda." prefix will make that failure go away.
strange is that it doesn't affect real iron installation ... although the can be difference between LPAR (that's what Hercules emulates) and z/VM guest.
It would only affect real iron if the chreipl command failed. The branch where the broken code is will not be executed if the chreipl succeeds as I'm sure it does on z/VM. Or at least that's what I'd bet on -- my last access to real iron was VM/ESA.
the "reipl" step blocks other steps including setting up the network in the installed image, see https://bugzilla.redhat.com/show_bug.cgi?id=858996 IIRC the workaround is to copy the ifcfg-ctc0 file from /tmp to /mnt/sysimage/etc/sysconfig/network-scripts and also setting the root's password is needed after "chroot /mnt/sysimage"
Will try it. Do some s390-utils, aside from the obviously VM only ones, only work on z/VM? I've only read one presentation on them and didn't note that if it is the case. anaconda knows or at least something knows if this is virtual -- I see it issue DIAG to check. Hmmm. Maybe that's checking for IUCV instead.
Report in a couple of hours when I get back to that point.
On Wed, 2013-01-30 at 05:06 -0500, Robert Knight wrote:
anaconda knows or at least something knows if this is virtual -- I see it issue DIAG to check. Hmmm. Maybe that's checking for IUCV instead.
Report in a couple of hours when I get back to that point.
DIAGNOSE X'308' is only partially implemented in Hercules. The "set parameter" and "store parameter" options are not implemented but return "OK" as if they were successful. It uses two Hercules commands to do this: - stopall - stops the CPUS - ipl or iplc - using the previous IPL device
I have not personally tested this, so can't attest to how well this works. If "set parameter" is being used to change the IPL device, unpredictable results may occur.
I have looked at the Linux code involved in use of "set parameter" and "store parameter" and do not believe those would be too difficult to implement but have not had the time to do so. I am watching this thread with interest.
Harold Grovesteen
On 01/30/2013 05:06 AM, Robert Knight wrote:
the "reipl" step blocks other steps including setting up the network in the installed image, see https://bugzilla.redhat.com/show_bug.cgi?id=858996 IIRC the workaround is to copy the ifcfg-ctc0 file from /tmp to /mnt/sysimage/etc/sysconfig/network-scripts and also setting the root's password is needed after "chroot /mnt/sysimage"
Will try it. Do some s390-utils, aside from the obviously VM only ones, only work on z/VM? I've only read one presentation on them and didn't note that if it is the case. anaconda knows or at least something knows if this is virtual -- I see it issue DIAG to check. Hmmm. Maybe that's checking for IUCV instead.
Report in a couple of hours when I get back to that point.
OK. That was refreshing. More like a couple of days. At the time that I wrote the above, I thought I knew how to modify anaconda to chase this, but had to learn that I did not.
I'm still stuck at the install finishes but produces an un-IPLable disk image. I see in the bug quoted above (and the repair in that bug's referenced bug) that this has been trouble.
I can hack out the crash in the iutil.py code that blows up anaconda, but the chreipl is not working. It looks from the logs like it thinks it has installed the "boot loader", although the disk still won't boot.
On 2/1/2013 12:35 PM, Robert Knight wrote:
On 01/30/2013 05:06 AM, Robert Knight wrote:
I'm still stuck at the install finishes but produces an un-IPLable disk image. I see in the bug quoted above (and the repair in that bug's referenced bug) that this has been trouble.
I can hack out the crash in the iutil.py code that blows up anaconda, but the chreipl is not working. It looks from the logs like it thinks it has installed the "boot loader", although the disk still won't boot.
Sorry that Dan's bug reference became unattributed. It was
On 1/30/2013 2:32 AM, Dan Horák wrote:
the "reipl" step blocks other steps including setting up the network in the installed image, see https://bugzilla.redhat.com/show_bug.cgi?id=858996 IIRC the workaround is to copy the ifcfg-ctc0 file from /tmp to /mnt/sysimage/etc/sysconfig/network-scripts and also setting the root's password is needed after "chroot /mnt/sysimage"
Making those two changes allowed me to install successfully on an LVM. One of my sources of confusion was that, unlike the Fedora 14 installation, the F18 installation quits writing to the main console once the CTC has started.
I'm still having trouble with the standard partition -- just after IPL, it goes into a tight loop.
I was successful in doing a "yum update", but the new kernel shows the same symptom -- IPLing into it goes into a tight loop at the same addresses. It makes me think that ZIPL needs something I'm not providing.
Should I be taking some other action following the new kernel installation that is not done by the yum update?
On 2/2/2013 9:14 AM, Robert Knight wrote:
I'm still having trouble with the standard partition -- just after IPL, it goes into a tight loop.
I was successful in doing a "yum update", but the new kernel shows the same symptom -- IPLing into it goes into a tight loop at the same addresses. It makes me think that ZIPL needs something I'm not providing.
Should I be taking some other action following the new kernel installation that is not done by the yum update?
The updated kernel, 3.7.4-204.fc18.s390x, looks to be about 650K smaller than the previous one (3.6.10-4.fc18.s390x) and the initramfs files differ by about the same.
So, my conjecture as to the cause of my troubles with the update were completely wrong.
With the offline help of Roger Bowler (thanks very much!), he determined that it was problem in Hercules, which has been corrected by a series of changes that are present in his git repo ( https://github.com/rbowler/spinhawk.git ). His description of what needed correcting was:
There were two definite problems that had to be fixed before z/Linux would IPL:
- PFMF failing to update r1 register due to testing wrong bits
- STFL must set bit 44 for z/Linux (and z/VM V6 too, I am informed)
additionally, he determined that dyncrypto(.so / dll) was now always needed to boot the kernel update ( 3.7.4-204.fc18.s390x ) for Fedora 18 that started this portion of this thread.
Since the topic has drifted so far from its Subject, I do not intend posting further under this.
-
Dan Horák -
Harold Grovesteen -
Robert Knight