Bug 103786

Hello, 
we experienced that the devno from the DASD used for the initial installation 
is hard coded in the initrd. With that it is impossible to boot the system on 
different DASDs, respective LPARs etc. 
This could be the same reason. We did not open a bugzilla yet.
   

Jim I would propose to increase the severity to high as for the impact on your 
test progress:
Here is the comment you tried to add before completion of your access group 
def's   ciao Georg

"If what Georg says is true, this would have an enormous impact on
> maintaining systems for LPARs. Currently, we build a standard system under
> VM on real volumes.
> 
> "To clone them for LPAR use, we copy the volumes to new volumes, change the
> dasd volumes assigned in /etc/zipl.conf and do a chroot/zipl/exit. We then
> only have to edit HOSTNAME entries and TCP/IP entries.
> 
> "If the device address is in initrd, then this adds additional work in
> preparing new releases for LPARs. We currently have approximately 25-30
> LPARs active. So this would have a large impact on us."

This is a show stopper for me because I cannot test under LPARs. In additon, I
need to have system that IPL both under VM and LPARs so that they can be used
interchangeablility for performance and functionality testing without changing
the testbed.

Instead of changing the zipl.conf, you need to change the dasd range in
/etc/modules.conf and rerun mkinitrd.  This is intentional because otherwise,
it's far too easy for people to lose needed kernel module options and break
their systems which would boot fine otherwise.

I could not IPL in an LPAR BEFORE I attempted to change zipl.conf. I built the
system under VM to real volumes. I then attempted to ipl from the same addresses
that I ipl'd from VMin an LPAR and the system would not IPL at all, but went
into the wait state provided.

As to your comment
"Instead of changing the zipl.conf, you need to change the dasd range in
/etc/modules.conf and rerun mkinitrd.  This is intentional because otherwise,
it's far too easy for people to lose needed kernel module options and break
their systems which would boot fine otherwise."

We have been using this cloning procedure since zipl came out and it has NOT
cause us any problem. Where exactly is the change to modules.conf and mkinitrd
documented? 

If anything, the comment is only a side issue to the real problem. If I can IPL
the volume under VM, why can't I IPL it in an LPAR?

 

Just to make sure that I get it right: 
 
> I then attempted to ipl from the same addresses that I ipl'd from VMin an LPAR and the system would not > 
> IPL at all, but went into the wait state provided. 
 
You have installed on DASDs 5601,5602,5611,5612 in VM, copied those DASDs to an LPAR with exactly 
the same devicenumbers and an IPL doesn't work ? 

NEGATIVE!!!!!!

I did the following:

1) On my VM guest, 

att 5601 * 5601
att 5602 * 5602
att 5611 * 5611
att 5612 * 5612

2) set my parameter file for the vmdrd install as

    dasd=5601,5602,5611,5612

2) did a vmrdr install to these volumes

     /dev/dasda1 = 5601   = /
     /dev/dasdb1 = 5602   = /usr
     /dev/dasdc1 = 5611   = /usr/share
     /dev/dasdd1 = 5621   = swap   

3) ipl'd 5601 to verify that it is iplable under VM, which is was.

4) Without any modification or change, I ipl'd 5601 in an LPAR. It got the
waitstate above.

I have gone back and rebuilt the system. I got the same results.

Do we have a LPAR case inside Red Hat where we can reproduce this problem?

Thanks a lot,

Florian La Roche

Apparently the dasd_eckd_mod is missing. 

I finally got it to work as follows:

1) you specify the dasd devices in /etc/modules.conf, i.e.

alias qeth0 qeth
options dasd_mod dasd=xxxx,yyyy,zzzz

2) Then you need to run mkinitrd:

a) do an "ls" on /lib/modules. The subdirectory name is what you need for the
mkinitrd. 
For example, /lib/modules/this-release

b) mkinitrd --preload dasd_eckd_mod new-initrd \
       this-release

3) change /etc/zipl so that
        ...
        ramdisk=/boot/new-initrd
        parameters="root=/dev/dasda1"        

    (also, other parameters, such as cio_ignore have to be coded here)

4) do a zipl

I tried this to clone a system, then use chroot to make the mods above. The
mkinitrd gave the following error messages, but it seemd to work:

/bin/bash: line 1: id: command not found
/bin/bash: line 1: id: command not found
/bin/bash: line 1: id: command not found
/sbin/mkinitrd: line 1: id: command not found
/sbin/mkinitrd: line 282: Y: !=: unary operator expected
/sbin/mkinitrd:line 1: tail: command not found

I could at least IPL the cloned system.

dasd_eckd_mod gets added to the initrd when the directory /proc/dasd exists. 
Can you please check which modules are in /lib of the original initrd ? 
 
It looks like you lost /usr/bin from your $PATH when you run chroot. 
 

two different issues:

1) /proc/dasd: on the base system (no chroot involved), when I used the system
as distributed, I cannot IPL in an LPAR. When I do the mkinitrd
--preload=dasd_eckd_mod, I can ipl in an LPAR.

It appears that, in an LPAR, dasd_eckd_mod is needed by initrd well before
/proc/dasd exists.

2) chroot: Since I have a multi-pack system and /usr is on a different volume,
then I suppose the chroot is not finding /usr. (/usr is on a separate pack
because of the size of the dircetory and I am constrained to 3390-3 images).

I built a "small" beta2 system to see what is happeninig. This is what I found

1) The system as built under vm will not IPL in an LPAR
2) If you do a mkinitrd (under vm), the /proc/dasd is present and the initrd is
corrected so that it will ipl in an lpar 
3) If you copy the respack pack to a new volume using "tar" or "cp" and change
the device addresses in modules.conf (and the root=/ to root/dev/dasda1 in
zipl.conf), then do the mkinitrd, the system will ipl in an LPAR (this is a bit
confusing because if you do a "ls" the chroot root does not show /proc/dasd).
4) With a small system, with /usr/bin on the root volume, the mkinitrd under
chroot, the miscellaneous error messages disappear.

I then went back to the beta2 cds and searched them for mkinitrd. There was no
mention of how to use mkinitrd or that you needed to run it to change the dasd
addresses.

How is this going to be handled on the candidate cd's? 

Problem appears to be fixed in RC1. lsmod showed dasd_mod_eckd present after VM
build. I was able to ipl in an LPAR with NO CHANGES.

That is very good news. Thanks a lot for your thorough testing!

greetings,

Florian La Roche