Menu
▾
▴
[sisuite-users] systemimager-4.3.0-0.3 (kernel 3.7.2, hpsa, bnx2, ...) (For testing purpose).
|
From: <dav...@cn...> - 2013-01-24 16:36:51
|
Second attempt after the first one bounced due to size ...
David K Livingstone
CN Signals and Communications
10229 127 Avenue floor 2
Walker Operations East Building
Edmonton, AB, T5E 0B9
Ph : 780 472-3959 Fax : 780 472-3046
Email: Dav...@cn...
----- Forwarded by David Livingstone/LIVING03/CNR/CA on 2013/01/24 09:34
-----
From:
David Livingstone/LIVING03/CNR/CA
To:
oli...@ce...
Date:
2013/01/24 09:03
Subject:
Fw: [sisuite-users] systemimager-4.3.0-0.3 (kernel 3.7.2, hpsa, bnx2, ...)
(For testing purpose).
Olivier,
Just received a reply from the list saying the post exceeded the limit and
it needs to be approved by the moderator ...
In the meantime her is the post sent directly to you !
I was running out the door last night when I posted and forgot to answer
your question :
- I included the rsync -L option(as described below with a snippet from my
original post) because
unfortunately this is the default result when applying the HP
spp(firmware and driver updates) to an HPserver.
The first time an spp is applied to a server the HP updated driver is
applied correctly to the /lib/modules/kernel
tree. If you subsequently upgrade your kernel and then apply an spp
again then the a link is made rather
then the module being copied(as shown below). Yes I could fight HP/redhat
on this however I don't
have the time or energy ...
- Needed modules(ie hpsa) as symbolic links under
/lib/modules/(uname -r)
ex
[root@scdev ~]# ls -al
/lib/modules/2.6.32-220.4.2.el6.i686/weak-updates/hpsa/hpsa.ko
0 lrwxrwxrwx 1 root root 50 Mar 5 04:05
/lib/modules/2.6.32-220.4.2.el6.i686/weak-updates/hpsa/hpsa.ko ->
/lib/modules/2.6.32-71.el6.i686/extra/hpsa/hpsa.ko
[root@scdev ~]#
This results in the modules not being copied correctly in the
generated initrd.
I resolved this by modifying the UseYourOwnKernel.pm rsync
invocations
to copy the resultant files(the L rather then the l option. I
include the diff
below.
David K Livingstone
CN Signals and Communications
10229 127 Avenue floor 2
Walker Operations East Building
Edmonton, AB, T5E 0B9
Ph : 780 472-3959 Fax : 780 472-3046
Email: Dav...@cn...
----- Forwarded by David Livingstone/LIVING03/CNR/CA on 2013/01/24 08:51
-----
From:
David Livingstone/LIVING03/CNR/CA
To:
sis...@li...
Date:
2013/01/23 16:51
Subject:
Re: [sisuite-users] systemimager-4.3.0-0.3 (kernel 3.7.2, hpsa, bnx2, ...)
(For testing purpose).
Olivier,
I just attempted to load an x86_64 machine using your previous build with
my changes applied as described in my email below. I haven't
yet had a chance to look at your new build.
- I attempted a boot using the standard kernel/initd and :
- the dhclient DEVICE failed. Later in the shell with "dhclient -v
eth1) it turns out the interface was not up. After doing a "ifconfig eth1
up"
the dhclinet eth1 is now is successful however now it attempts to
write the lease into /var/db/dhclient.leases rather then
the expected /var/state/dhcp/... Did you ever get a dhclient boot to
work ?
- also during booting requested firmware was hanging ie netxen_nic:...:
firmware: requesting phanfw.bin
See below with uyok.
- I eventually tried setting all the IP parameters and IMAGESERVER in
the pxelinux.cfg file which
bypasses dhclient. At this point we now fail because there is no hpsa
module loaded and no
disks are visible.
-The uyok load fails as once again numerous firmware files fail to load.
This problem did not happen
with my initial test setup using the 4.1.99.svn4556_bli-1 packages but
does with 4.3.0-0.2.el6.
In this case the firmware files are in the initrd however what appears
to have changed is
that the firmware loading code changed from a shell script (firmware.sh)
to a binary.
See https://bugzilla.redhat.com/show_bug.cgi?id=560031
The 4.1.99.svn4556_bli-1 package
systemimager-i386initrd_template-4.1.99.svn4556_bli-1.noarch
has :
[root@nasedm udev]# pwd
/usr/share/systemimager/boot/i386/standard/initrd_template/lib/udev
[root@nasedm udev]# ls
total 132
12 ata_id* 8 collect* 12 edd_id* 12 path_id*
24 scsi_id* 12 vol_id* 4 write_net_rules*
8 cdrom_id* 12 create_floppy_devices* 4 firmware.sh* 4
rule_generator.functions 16 usb_id* 4 write_cd_rules*
[root@nasedm udev]#
And the systemimager-x86_64initrd_template-4.3.0-0.2.el6.noarch has :
[root@wild1 udev]# pwd
/usr/share/systemimager/boot/x86_64/standard/initrd_template/lib/udev
[root@wild1 udev]# ls
total 356
24 ata_id* 12 collect* 20 edd_id* 20 fstab_import* 36
path_id* 40 usb_id* 4 write_cd_rules*
36 cdrom_id* 44 create_floppy_devices* 44 firmware* 32 input_id* 32
scsi_id* 8 v4l_id* 4 write_net_rules*
[root@wild1 udev]#
The original firmware.sh is invoked in the
/usr/share/systemimager/boot/i386/standard/initrd_template/etc/udev/rules.d/80-programs.rules
:
[root@nasedm udev]# rpm -qf
/usr/share/systemimager/boot/i386/standard/initrd_template/etc/udev/rules.d/80-programs.rules
systemimager-i386initrd_template-4.1.99.svn4556_bli-1.noarch
[root@nasedm udev]# cd
/usr/share/systemimager/boot/i386/standard/initrd_template/etc/udev/rules.d
[root@nasedm rules.d]# ls
total 56
4 00-init.rules 4 30-cdrom_id.rules 4 61-persistent-storage-edd.rules
4 75-cd-aliases-generator.rules 4 90-modprobe.rules
4 05-options.rules 4 60-cdrom_id.rules 4 65-persistent-input.rules 4
75-persistent-net-generator.rules 4 99-udevmonitor.rules
4 20-names.rules 4 60-symlinks.rules 4 65-persistent-storage.rules 4
80-programs.rules
[root@nasedm rules.d]# grep -i firmw *
80-programs.rules:# firmware class requests
80-programs.rules:SUBSYSTEM=="firmware", ACTION=="add",
RUN+="/lib/udev/firmware.sh"
|