Hi,
to install current PC models (with new Intel NICs) via Kickstart/PXE, I wanted to add the newest e1000e-Treiber to initrd.img. With this modified image, the Kickstart kernel crashes with the following error messages:
[...] md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. RAMDISK: Compressed image found at block 0 RAMDISK: incomplete write (20480 != 32768) 6062080 VFS: Cannot open root device "<NULL>" or unknown-block(253,3) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(253,3)
To modify the initrd.img, I took the original CentOS 5.2 image, unpacked with cpio/gunzip and replaced modules/2.6.18-92.el5/x86_64/e1000e.ko with a current version. This driver module had been created on a freshly installed CentOS 5.2 host with kernel 2.6.18-92.el5 and w/o any updates. After adding the driver, I re-archived and re-packed the image and replaced the initrd.img on my tftp server.
The new image is considerably bigger than the old one (12 MB vs. 5.7 MB) which puzzles me, as the driver file itself is 2.8 MB (compared to the old e1000e.ko with ca 170 KB) but the resulting modules.cgz is only around 700 KB bigger than the original one. All files have been compressed with `gzip -9`.
My PXE bootsettings are:
KERNEL CentOS-5.2_64/vmlinuz APPEND initrd=CentOS-5.2_64/initrd.img ramdisk_size=5940 kssendmac ks=http://srv/ks/ks.cgi noipv6
Even raising ramdisk_size doesn't help. At around ramdisk_size=7100 there seems to be an overflow and the size is recounted from zero (?).
Any Ideas, how one can/should create an updated and working initrd.img for Kickstart/PXE?
A similar question has been asked before on this list and a recommendation was to wait for 5.3. Unfortunately I cannot wait for the next release.
Thanks in advance
frank
Frank Thommen wrote:
To modify the initrd.img, I took the original CentOS 5.2 image, unpacked with cpio/gunzip and replaced modules/2.6.18-92.el5/x86_64/e1000e.ko with a current version. This driver module had been created on a freshly installed CentOS 5.2 host with kernel 2.6.18-92.el5 and w/o any updates. After adding the driver, I re-archived and re-packed the image and replaced the initrd.img on my tftp server.
The new image is considerably bigger than the old one (12 MB vs. 5.7 MB) which puzzles me, as the driver file itself is 2.8 MB (compared to the old e1000e.ko with ca 170 KB) but the resulting modules.cgz is only around 700 KB bigger than the original one. All files have been compressed with `gzip -9`.
What cpio options did you use to re-create modules/modules.cgz and then the initrd.img?
Did you gzip the initrd.img after cpio'ing it?
It might be better to wait for CentOS 5.3 - as that has an updated e1000e module - hopefully 5.3 might be out this week end ...
James Pearson
Frank Thommen wrote:
To modify the initrd.img, I took the original CentOS 5.2 image, unpacked with cpio/gunzip and replaced modules/2.6.18-92.el5/x86_64/e1000e.ko with a current version. This driver module had been created on a freshly installed CentOS 5.2 host with kernel 2.6.18-92.el5 and w/o any updates. After adding the driver, I re-archived and re-packed the image and replaced the initrd.img on my tftp server.
The new image is considerably bigger than the old one (12 MB vs. 5.7 MB) which puzzles me, as the driver file itself is 2.8 MB (compared to the old e1000e.ko with ca 170 KB) but the resulting modules.cgz is only around 700 KB bigger than the original one. All files have been compressed with `gzip -9`.
Just wondering... can you safely strip modules like you would strip executables?
JD
John Doe wrote:
Frank Thommen wrote:
[...]
The new image is considerably bigger than the old one (12 MB vs. 5.7 MB) which puzzles me, as the driver file itself is 2.8 MB (compared to the old e1000e.ko with ca 170 KB) [...]
Just wondering... can you safely strip modules like you would strip executables?
Don't know. Admittedly I don't even know what stripping is...[reading in Wikipedia]...now having some half-knowledge...
`strip e1000e.ko` results in a 148K file (compared to the 2.8MB original). I'll try to put this one into the initrd.ing tomorrow.
Thanks
frank
On Thu, 2009-03-26 at 17:49 +0100, Frank Thommen wrote:
John Doe wrote:
Frank Thommen wrote:
[...]
The new image is considerably bigger than the old one (12 MB vs. 5.7 MB) which puzzles me, as the driver file itself is 2.8 MB (compared to the old e1000e.ko with ca 170 KB) [...]
Just wondering... can you safely strip modules like you would strip executables?
It's been a long time since I dinked with this stuff, but...
IIRC, there's several levels of strip. One strips everything, save for standalone binaries (not dependent on run-time linking with a library) and "safe". Safe leaves the external symbols intact so that the loader can tell what linkages are needed. I don't remember the parameters, but the manual should tell you.
I *think* that some symbols are needed for loadable modules for both the kernel linkage and any references to shared libraries that might be used. Again, I'm unsure now - to many decaeds have passed since I dinked with this stuff.
<snip>
Thanks
frank<snip sig stuff>
HTH
On Thu, 2009-03-26 at 14:56 -0400, William L. Maltby wrote:
<snip>
It's been a long time since I dinked with this stuff, but...
IIRC, there's several levels of strip. One strips everything, save for
s/save/safe/ # RATS!
standalone binaries (not dependent on run-time linking with a library) and "safe". Safe leaves the external symbols intact so that the loader can tell what linkages are needed. I don't remember the parameters, but the manual should tell you.
I *think* that some symbols are needed for loadable modules for both the kernel linkage and any references to shared libraries that might be used. Again, I'm unsure now - to many decaeds have passed since I dinked with this stuff.
<snip>
John Doe wrote:
Frank Thommen wrote:
To modify the initrd.img, I took the original CentOS 5.2 image, unpacked with cpio/gunzip and replaced modules/2.6.18-92.el5/x86_64/e1000e.ko with a current version. This driver module had been created on a freshly installed CentOS 5.2 host with kernel 2.6.18-92.el5 and w/o any updates. After adding the driver, I re-archived and re-packed the image and replaced the initrd.img on my tftp server.
The new image is considerably bigger than the old one (12 MB vs. 5.7 MB) which puzzles me, as the driver file itself is 2.8 MB (compared to the old e1000e.ko with ca 170 KB) but the resulting modules.cgz is only around 700 KB bigger than the original one. All files have been compressed with `gzip -9`.
Just wondering... can you safely strip modules like you would strip executables?
Unfortunately stripping didn't help. Same error message at boot.
frank
What cpio options did you use to re-create modules/modules.cgz and then the initrd.img?
I used `cpio -ovF <file>` and `cpio -ov -H crc -F <file>` (I found the latter on http://sial.org/howto/linux/initrd/). However I could not find any "officially looking" information about how the initrd.img/modules.cgz is created.
Did you gzip the initrd.img after cpio'ing it?
yes, with `gzip -9`.
It might be better to wait for CentOS 5.3 - as that has an updated e1000e module - hopefully 5.3 might be out this week end ...
OK, I could wait this long (better: short) :-)
frank
On Thu, Mar 26, 2009 at 05:27:10PM +0100, Frank Thommen wrote:
What cpio options did you use to re-create modules/modules.cgz and then the initrd.img?
I used `cpio -ovF <file>` and `cpio -ov -H crc -F <file>` (I found the latter on http://sial.org/howto/linux/initrd/). However I could not find any "officially looking" information about how the initrd.img/modules.cgz is created.
find ./ | cpio -H newc -o | | gzip -c9 > /path/to/my/initrd.img
Tru
Tru Huynh wrote:
On Thu, Mar 26, 2009 at 05:27:10PM +0100, Frank Thommen wrote:
What cpio options did you use to re-create modules/modules.cgz and then the initrd.img?
I used `cpio -ovF <file>` and `cpio -ov -H crc -F <file>` (I found the latter on http://sial.org/howto/linux/initrd/). However I could not find any "officially looking" information about how the initrd.img/modules.cgz is created.
find ./ | cpio -H newc -o | | gzip -c9 > /path/to/my/initrd.img
This give a slightly different error message:
[...] md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. VFS: Cannot open root device "<NULL>" or unknown-block(253,3) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(253,3)
The two "RAMDISK" error lines have gone. I have archived modules/modules.cgz *and* initrd.img with "-H newc".
frank
On Fri, Mar 27, 2009 at 04:04:40PM +0100, Frank Thommen wrote:
This give a slightly different error message:
[...] md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. VFS: Cannot open root device "<NULL>" or unknown-block(253,3) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(253,3)
The two "RAMDISK" error lines have gone. I have archived modules/modules.cgz *and* initrd.img with "-H newc".
only the initrd needs "-H newc"
This one works for me LABEL centos5 MENU LABEL ^1) centos 5 x86_64 raid1 ks KERNEL centos5.x86_64/vmlinuz APPEND initrd=centos5.x86_64/initrd.img method=http://10.0.0.4/pub/linux/c5/os/x86_64 noipv6 syslog=10.0.0.4 kssendmac ip=dhcp ks=http://10.0.0.4/ks/c5-raid1-64-min.cfg
Tru
Tru Huynh wrote:
On Fri, Mar 27, 2009 at 04:04:40PM +0100, Frank Thommen wrote:
This give a slightly different error message:
[...] md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. VFS: Cannot open root device "<NULL>" or unknown-block(253,3) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(253,3)
The two "RAMDISK" error lines have gone. I have archived modules/modules.cgz *and* initrd.img with "-H newc".
only the initrd needs "-H newc"
I tried also with non-newc for modules.cgz but this doesn't help. However when I look at the original, gunzipped modules.cgz wich `file`, then I get "ASCII cpio archive (SVR4 with no CRC)" which would also be 'newc'.
This one works for me LABEL centos5 MENU LABEL ^1) centos 5 x86_64 raid1 ks KERNEL centos5.x86_64/vmlinuz APPEND initrd=centos5.x86_64/initrd.img method=http://10.0.0.4/pub/linux/c5/os/x86_64 noipv6 syslog=10.0.0.4 kssendmac ip=dhcp ks=http://10.0.0.4/ks/c5-raid1-64-min.cfg
That is more or less what we have:
KERNEL CentOS-5.2_64/vmlinuz APPEND initrd=CentOS-5.2_64/initrd.img ramdisk_size=5940 kssendmac ks=http://srv/ks/ks.cgi noipv6
This should not be the problem as it works fine for the unmodified initrd.img.
frank
Frank Thommen wrote:
Hi,
to install current PC models (with new Intel NICs) via Kickstart/PXE, I wanted to add the newest e1000e-Treiber to initrd.img. With this modified image, the Kickstart kernel crashes with the following error messages:
Maybe you need to increase the memory allocated to ramdisk? by default I use ramdisk_size=16384 as a kernel parameter for booting the installer.
nate
to install current PC models (with new Intel NICs) via Kickstart/PXE, I wanted to add the newest e1000e-Treiber to initrd.img. With this modified image, the Kickstart kernel crashes with the following error messages:
Maybe you need to increase the memory allocated to ramdisk? by default I use ramdisk_size=16384 as a kernel parameter for booting the installer.
with ramdisk_size=16384 the error message is:
[...] md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. RAMDISK: Compressed image found at block 0 RAMDISK: incomplete write (-28 != 32768) 16777216 VFS: Cannot open root device "<NULL>" or unknown-block(253,3) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(253,3)
There is probably an exact way to determine a valid ramdisk_size, buth which? :-}
frank
-
Frank Thommen -
James Pearson -
John Doe -
nate -
Tru Huynh -
William L. Maltby