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.