3:47 p.m.
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
4:11 p.m.
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/
5:19 a.m.
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.
6:41 a.m.
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
9:31 a.m.
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
10:04 a.m.
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
11:59 a.m.
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
2:50 p.m.
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...
3:39 p.m.
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
5:26 p.m.
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
9:18 p.m.
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)
1:32 a.m.
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
4:06 a.m.
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.
5:43 a.m.
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
11:35 a.m.
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.
8:14 a.m.
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?
6:42 p.m.
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.
7:22 a.m.
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.
4089
days inactive
4104
days old
17 comments
3 participants
participants (3)
-
Dan Horák -
Harold Grovesteen -
Robert Knight