Werner and the Kernel Gods,
I have tried for the past 3 days fruitlessly to resolve my kernel
woes. Spent most of my working hours searching google for any answers
but I got confused instead. I am desperate for any info that would
point
me to the right direction. Your assistance will be highly appreciated
and I know that I am not alone on this one.
Here's what I am trying to do.
I have successfully installed RH 7.1 with 2.4.2 kernel on a Compaq
Proliant 6000 (4 Processors) . The SCSI driver that was loaded on
install is sym53c8xx .
cat /proc/scsi/scsi
Attached devices:
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: COMPAQ Model: MAB3091SC Rev: 0814
Type: Direct-Access ANSI SCSI revision: 02
[root@tinkerbell smpimg]# lsmod
Module Size Used by
loop 9120 2 (autoclean)
eepro100 16624 1 (autoclean)
sym53c8xx 62080 5
sd_mod 11680 5
scsi_mod 95072 2 [sym53c8xx sd_mod]
[root@tinkerbell smpimg]# cat /proc/mounts
/dev/root / ext2 rw 0 0
/proc /proc proc rw 0 0
/dev/sda8 /home ext2 rw 0 0
/dev/sda6 /usr ext2 rw 0 0
/dev/sda5 /var ext2 rw 0 0
none /dev/pts devpts rw 0 0
/dev/loop0 /mnt/smpimg ext2 rw 0 0
Also, /dev/ram0 is enabled:
fdisk /dev/ram0
Note: sector size is 1024 (not 512)
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF
disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
Command (m for help): p
Disk /dev/ram0: 1 heads, 4096 sectors, 1 cylinders
Units = cylinders of 4096 * 1024 bytes
Device Boot Start End Blocks Id System
Since I wanted to have EXT3 support , I upgraded my kernel to
2.4.9-12 from redhat.com together with the
required SysVinit, modutils, initscripts, filesystem and all.
Once I have the new kernel installed I created an initrd image. The
reason is that the SCSI drivers are modules and
not compiled in:
[root@tinkerbell scsi]# pwd
/lib/modules/2.4.9-12smp/kernel/drivers/scsi
[root@tinkerbell scsi]# ls
3w-xxxx.o aha1740.o cpqfc.o fdomain.o ips.o
pci2000.o qlogicfas.o sg.o tmscsim.o
53c7,8xx.o aic7xxx dmx3191d.o gdth.o iscsi.o
pci2220i.o qlogicfc.o sim710.o u14-34f.o
a100u2w.o aic7xxx_mod.o dpt_i2o.o g_NCR5380.o megaraid.o
pcmcia qlogicisp.o sr_mod.o ultrastor.o
aacraid.o aic7xxx.o dtc.o ide-scsi.o NCR53c406a.o
ppa.o scsi_debug.o st.o wd7000.o
advansys.o AM53C974.o eata_dma.o imm.o ncr53c8xx.o
psi240i.o scsi_mod.o sym53c416.o
aha152x.o atp870u.o eata.o in2000.o osst.o
qla1280.o sd_mod.o sym53c8xx.o
aha1542.o BusLogic.o eata_pio.o initio.o pas16.o
qla2x00.o seagate.o t128.o
Since I understand that I have to create an image for my booting
process, I created one with the following
command:
[root@tinkerbell scsi]# cd /boot/
mkinitrd initrd-2.4.9-12smp.img 2.4.9-12smp --preload scsi_mod
--with=sd_mod --with=sym53c8xx -v
Using modules: ./kernel/drivers/scsi/scsi_mod.o
./kernel/drivers/scsi/sd_mod.o ./kernel/drivers/scsi/sym53c8xx.o
Using loopback device /dev/loop1
/sbin/nash -> /tmp/initrd.QCmw3a/bin/nash
/sbin/insmod.static -> /tmp/initrd.QCmw3a/bin/insmod
`/lib/modules/2.4.9-12smp/./kernel/drivers/scsi/scsi_mod.o' ->
`/tmp/initrd.QCmw3a/lib/scsi_mod.o'
`/lib/modules/2.4.9-12smp/./kernel/drivers/scsi/sd_mod.o' ->
`/tmp/initrd.QCmw3a/lib/sd_mod.o'
`/lib/modules/2.4.9-12smp/./kernel/drivers/scsi/sym53c8xx.o' ->
`/tmp/initrd.QCmw3a/lib/sym53c8xx.o'
Loading module scsi_mod with options
Loading module sd_mod with options
Loading module sym53c8xx with options
Here's my /etc/modules.conf
[root@tinkerbell /boot]# cat /etc/modules.conf
alias eth0 eepro100
alias eth1 eepro100
alias scsi_hostadapter1 sym53c8xx
alias parport_lowlevel parport_pc
alias scsi_hostadapter2 sym53c8xx
alias scsi_hostadapter3 sym53c8xx
alias scsi_hostadapter4 sym53c8xx
After creating the initrd image, I wanted to make sure that it will
mount the correct device:
[root@tinkerbell /boot]# zcat initrd-2.4.9-12smp.img > /tmp/smp
[root@tinkerbell /boot]# mount /tmp/smp -t ext2 /mnt/smpimg/ -o loop
[root@tinkerbell /boot]# cd /mnt/smpimg/
[root@tinkerbell smpimg]# vi linuxrc
Here's the content of mkinitrd generated /linuxrc
#!/bin/nash
echo "Loading scsi_mod module"
insmod /lib/scsi_mod.o
echo "Loading sd_mod module"
insmod /lib/sd_mod.o
echo "Loading sym53c8xx module"
insmod /lib/sym53c8xx.o
mount -t proc /proc /proc
echo Mounting /proc filesystem
echo Creating root device
mkrootdev /dev/root
echo 0x0100 > /proc/sys/kernel/real-root-dev
umount /proc
echo Mounting root filesystem
mount --ro -t ext2 /dev/root /sysroot
pivot_root /sysroot /sysroot/initrd
I saw a posting on the net saying that I should have this edited as
follows:
#!/bin/nash
echo "Loading scsi_mod module"
insmod /lib/scsi_mod.o
echo "Loading sd_mod module"
insmod /lib/sd_mod.o
echo "Loading sym53c8xx module"
insmod /lib/sym53c8xx.o
mount -t proc /proc /proc
echo Mounting /proc filesystem
echo Creating root device
mkrootdev /dev/root
echo 0x0100 > /proc/sys/kernel/real-root-dev
umount /proc
echo Mounting root filesystem
mount --ro -t ext2 /dev/root /sysroot
cd /sysroot ## CD to
/sysroot first
pivot_root /sysroot /sysroot/initrd ## Do pivot_root
exec /sbin/init "$@" ## Execute
/sbin/init
After which I added this line my /etc/lilo.conf file:
image=/boot/vmlinuz-2.4.9-12smp
label=2.4.9smp
append="initrd=/boot/initrd-2.4.9-12smp.img root=/dev/ram0
init=/linuxrc rw"
Reran lilo
[root@tinkerbell /root]# lilo -v
LILO version 21.4-4, Copyright (C) 1992-1998 Werner Almesberger
'lba32' extensions Copyright (C) 1999,2000 John Coffman
Reading boot sector from /dev/sda
Merging with /boot/boot.b
Mapping message file /boot/message
Boot image: /boot/vmlinuz-2.4.2-2smp
Mapping RAM disk /boot/initrd-2.4.2-2smp.img
Added linux
Boot image: /boot/vmlinuz-2.4.2-2
Mapping RAM disk /boot/initrd-2.4.2-2.img
Added linux-up *
Boot image: /boot/vmlinuz-2.4.9-12smp ## Entry for SMP kernel
Added 2.4.9smp
Boot image: /boot/vmlinuz-2.4.9-12-smp-4th
Added custom
/boot/boot.0800 exists - no backup copy made.
Writing boot sector.
Now for the real fun part, when I reboot I get the following error:
"VFS: Cannot open root device "ram0" or 01:00
Please append a correct "root=" boot option
Kernel panic: VFS: unable to mount root fs on 01:00 "
I have tried other approaches but to no avail. I decided that I seek
assistance from you
hoping that you will be kind and patient enough to help me.
Thanks in advance,
Joy
Joy,
Had a similar problem a while ago. Explicitely after upgrading to
redhat mkinitrd-3.2.6-1.i386.rpm.
Going back to mkinitrd-3.2.6-1.i386.rpm (form the installation CD)
got me going again...
-Marcel
On Tue, Dec 11, 2001 at 01:50:46PM -0500, Joy Almacen wrote:
> Werner and the Kernel Gods,
>
>
> I have tried for the past 3 days fruitlessly to resolve my kernel
> woes. Spent most of my working hours searching google for any answers
> but I got confused instead. I am desperate for any info that would
> point
> me to the right direction. Your assistance will be highly appreciated
> and I know that I am not alone on this one.
>
> Here's what I am trying to do.
>
--
======-------- Marcel J.E. Mol MESA Consulting B.V.
=======--------- ph. +31-(0)6-54724868 P.O. Box 112
=======--------- [email protected] 2630 AC Nootdorp
__==== http://www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____
They couldn't think of a number, Linux user 1148 -- counter.li.org
so they gave me a name! -- Rupert Hine -- http://www.ruperthine.com
Boy, what a detailed report!
I never used lilo, but:
> After which I added this line my /etc/lilo.conf file:
>
> image=/boot/vmlinuz-2.4.9-12smp
> label=2.4.9smp
> append="initrd=/boot/initrd-2.4.9-12smp.img root=/dev/ram0
> init=/linuxrc rw"
>
> Reran lilo
>
> [root@tinkerbell /root]# lilo -v
>
> LILO version 21.4-4, Copyright (C) 1992-1998 Werner Almesberger
> 'lba32' extensions Copyright (C) 1999,2000 John Coffman
>
> Reading boot sector from /dev/sda
> Merging with /boot/boot.b
> Mapping message file /boot/message
> Boot image: /boot/vmlinuz-2.4.2-2smp
> Mapping RAM disk /boot/initrd-2.4.2-2smp.img
> Added linux
> Boot image: /boot/vmlinuz-2.4.2-2
> Mapping RAM disk /boot/initrd-2.4.2-2.img
> Added linux-up *
> Boot image: /boot/vmlinuz-2.4.9-12smp ## Entry for SMP kernel
> Added 2.4.9smp
> Boot image: /boot/vmlinuz-2.4.9-12-smp-4th
> Added custom
> /boot/boot.0800 exists - no backup copy made.
> Writing boot sector.
"Mapping RAM disk" seems to be missing for 2.4.9-12, so you'll get:
> "VFS: Cannot open root device "ram0" or 01:00
> Please append a correct "root=" boot option
> Kernel panic: VFS: unable to mount root fs on 01:00 "
Check your lilo conf. Include it in your reply.
BTW, don't go for 2.4x, x>10. initrd is broken there and is still unfixed.
--
vda
On Thu, 13 Dec 2001, vda wrote:
> BTW, don't go for 2.4x, x>10. initrd is broken there and is still unfixed.
Bullshit.
On Thursday 13 December 2001 06:19, Alexander Viro wrote:
> On Thu, 13 Dec 2001, vda wrote:
> > BTW, don't go for 2.4x, x>10. initrd is broken there and is still
> > unfixed.
>
> Bullshit.
I have a slackware initrd (minix) which is booting fine with 2.4.10
but fails to boot with 2.4.12 and later (same .config, same bootloader,
same hardware, same AC voltage in the wall outlet, time of day differs by
1 minute), so it might be true :-)
I have a report of romfs initrd with same symptoms. ext2 initrds OTOH
boots fine.
--
vda
On Thursday 13 December 2001 11:22, vda wrote:
> On Thursday 13 December 2001 06:19, Alexander Viro wrote:
> > On Thu, 13 Dec 2001, vda wrote:
> > > BTW, don't go for 2.4x, x>10. initrd is broken there and is still
> > > unfixed.
> >
> > Bullshit.
>
> I have a slackware initrd (minix) which is booting fine with 2.4.10
> but fails to boot with 2.4.12 and later (same .config, same bootloader,
> same hardware, same AC voltage in the wall outlet, time of day differs by
> 1 minute), so it might be true :-)
>
> I have a report of romfs initrd with same symptoms. ext2 initrd OTOH
> boots fine.
You can dl and try to load this minix initrd from
http://port.imtp.ilyichevsk.odessa.ua/linux/vda/minix.gz
If you can do that, please tell me exact kernel version, what bootloader you
use and send your .config, I'll try it here.
--
vda
Hi,
On Tue, Dec 11, 2001 at 01:50:46PM -0500, Joy Almacen wrote:
> After which I added this line my /etc/lilo.conf file:
>
> image=/boot/vmlinuz-2.4.9-12smp
> label=2.4.9smp
> append="initrd=/boot/initrd-2.4.9-12smp.img root=/dev/ram0
> init=/linuxrc rw"
That's your problem. You need to specify your real root device in the
"root=" section; for example, mine looks like
image=/boot/vmlinuz-2.4.9-13
label=linux
initrd=/boot/initrd-2.4.9-13.img
read-only
root=/dev/md1
The initrd magic happens before the real root gets loaded: you don't
need to point root to /dev/ram0 to get a ramdisk.
Cheers,
Stephen
Stephen,
I have tried every imaginable root device out there but with no success.
Thank you though for all your emails. I gave up on RH 7.1
and decided to install RH7.2. SMP is now enabled only after
configuring the BIOS of Proliant 6000 to "Linux" as the
OS. Now it is working the way we expect it. I still
have issues with my Fiber Channel but that's not critical at the moment.
There is definitely something screwy with the mkinitrd RPM that was
supplied by RedHat.
Good day,
"Stephen C. Tweedie" wrote:
> Hi,
>
> On Tue, Dec 11, 2001 at 01:50:46PM -0500, Joy Almacen wrote:
>
> > After which I added this line my /etc/lilo.conf file:
> >
> > image=/boot/vmlinuz-2.4.9-12smp
> > label=2.4.9smp
> > append="initrd=/boot/initrd-2.4.9-12smp.img root=/dev/ram0
> > init=/linuxrc rw"
>
> That's your problem. You need to specify your real root device in the
> "root=" section; for example, mine looks like
>
> image=/boot/vmlinuz-2.4.9-13
> label=linux
> initrd=/boot/initrd-2.4.9-13.img
> read-only
> root=/dev/md1
>
> The initrd magic happens before the real root gets loaded: you don't
> need to point root to /dev/ram0 to get a ramdisk.
>
> Cheers,
> Stephen
On Thu, 13 Dec 2001, vda wrote:
> On Thursday 13 December 2001 06:19, Alexander Viro wrote:
> > On Thu, 13 Dec 2001, vda wrote:
> > > BTW, don't go for 2.4x, x>10. initrd is broken there and is still
> > > unfixed.
> >
> > Bullshit.
>
> I have a slackware initrd (minix) which is booting fine with 2.4.10
> but fails to boot with 2.4.12 and later (same .config, same bootloader,
> same hardware, same AC voltage in the wall outlet, time of day differs by
> 1 minute), so it might be true :-)
Hmm.. works here with 2.5.1-pre8.
-Mike
...
RAMDISK driver initialized: 16 RAM disks of 12288K size 1024 blocksize
...
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 5161k freed
MINIX-fs: mounting unchecked file system, running fsck is recommended.
VFS: Mounted root (minix filesystem).
Freeing unused kernel memory: 236k freed
On Saturday 15 December 2001 10:14, Mike Galbraith wrote:
> On Thu, 13 Dec 2001, vda wrote:
> > On Thursday 13 December 2001 06:19, Alexander Viro wrote:
> > > On Thu, 13 Dec 2001, vda wrote:
> > > > BTW, don't go for 2.4x, x>10. initrd is broken there and is still
> > > > unfixed.
> > >
> > > Bullshit.
> >
> > I have a slackware initrd (minix) which is booting fine with 2.4.10
> > but fails to boot with 2.4.12 and later (same .config, same bootloader,
> > same hardware, same AC voltage in the wall outlet, time of day differs by
> > 1 minute), so it might be true :-)
>
> Hmm.. works here with 2.5.1-pre8.
>
> -Mike
> ...
> RAMDISK driver initialized: 16 RAM disks of 12288K size 1024 blocksize
> ...
> RAMDISK: Compressed image found at block 0
> Freeing initrd memory: 5161k freed
> MINIX-fs: mounting unchecked file system, running fsck is recommended.
> VFS: Mounted root (minix filesystem).
> Freeing unused kernel memory: 236k freed
Have you tried it with minix initrd from
http://port.imtp.ilyichevsk.odessa.ua/linux/vda/minix.gz
(slackware install initrd, should load up to login prompt stage,
does not touch hd) or with some other one?
--
vda
On Saturday 15 December 2001 10:14, Mike Galbraith wrote:
> On Thu, 13 Dec 2001, vda wrote:
> > On Thursday 13 December 2001 06:19, Alexander Viro wrote:
> > > On Thu, 13 Dec 2001, vda wrote:
> > > > BTW, don't go for 2.4x, x>10. initrd is broken there and is still
> > > > unfixed.
> > >
> > > Bullshit.
> >
> > I have a slackware initrd (minix) which is booting fine with 2.4.10
> > but fails to boot with 2.4.12 and later (same .config, same bootloader,
> > same hardware, same AC voltage in the wall outlet, time of day differs by
> > 1 minute), so it might be true :-)
>
> Hmm.. works here with 2.5.1-pre8.
>
> -Mike
> ...
> RAMDISK driver initialized: 16 RAM disks of 12288K size 1024 blocksize
> ...
> RAMDISK: Compressed image found at block 0
> Freeing initrd memory: 5161k freed
> MINIX-fs: mounting unchecked file system, running fsck is recommended.
> VFS: Mounted root (minix filesystem).
> Freeing unused kernel memory: 236k freed
I'd like to try it, can you send a .config?
--
vda
(cc list trimmed.. forgot to do that last time;)
On Sat, 15 Dec 2001, vda wrote:
> On Saturday 15 December 2001 10:14, Mike Galbraith wrote:
> > On Thu, 13 Dec 2001, vda wrote:
> > > On Thursday 13 December 2001 06:19, Alexander Viro wrote:
> > > > On Thu, 13 Dec 2001, vda wrote:
> > > > > BTW, don't go for 2.4x, x>10. initrd is broken there and is still
> > > > > unfixed.
> > > >
> > > > Bullshit.
> > >
> > > I have a slackware initrd (minix) which is booting fine with 2.4.10
> > > but fails to boot with 2.4.12 and later (same .config, same bootloader,
> > > same hardware, same AC voltage in the wall outlet, time of day differs by
> > > 1 minute), so it might be true :-)
> >
> > Hmm.. works here with 2.5.1-pre8.
> >
> > -Mike
> > ...
> > RAMDISK driver initialized: 16 RAM disks of 12288K size 1024 blocksize
> > ...
> > RAMDISK: Compressed image found at block 0
> > Freeing initrd memory: 5161k freed
> > MINIX-fs: mounting unchecked file system, running fsck is recommended.
> > VFS: Mounted root (minix filesystem).
> > Freeing unused kernel memory: 236k freed
>
> I'd like to try it, can you send a .config?
.config?.. normal config with initrd+ramdisk+minix in kernel.
-Mike
On Sat, 15 Dec 2001, vda wrote:
> On Saturday 15 December 2001 10:14, Mike Galbraith wrote:
> > On Thu, 13 Dec 2001, vda wrote:
> > > On Thursday 13 December 2001 06:19, Alexander Viro wrote:
> > > > On Thu, 13 Dec 2001, vda wrote:
> > > > > BTW, don't go for 2.4x, x>10. initrd is broken there and is still
> > > > > unfixed.
> > > >
> > > > Bullshit.
> > >
> > > I have a slackware initrd (minix) which is booting fine with 2.4.10
> > > but fails to boot with 2.4.12 and later (same .config, same bootloader,
> > > same hardware, same AC voltage in the wall outlet, time of day differs by
> > > 1 minute), so it might be true :-)
> >
> > Hmm.. works here with 2.5.1-pre8.
> >
> > -Mike
> > ...
> > RAMDISK driver initialized: 16 RAM disks of 12288K size 1024 blocksize
> > ...
> > RAMDISK: Compressed image found at block 0
> > Freeing initrd memory: 5161k freed
> > MINIX-fs: mounting unchecked file system, running fsck is recommended.
> > VFS: Mounted root (minix filesystem).
> > Freeing unused kernel memory: 236k freed
>
> Have you tried it with minix initrd from
>
> http://port.imtp.ilyichevsk.odessa.ua/linux/vda/minix.gz
No, I converted my 'fire department' initrd to minix and booted that.
-Mike
On Saturday 15 December 2001 15:59, Mike Galbraith wrote:
> > > > I have a slackware initrd (minix) which is booting fine with 2.4.10
> > > > but fails to boot with 2.4.12 and later (same .config, same
> > > > bootloader, same hardware, same AC voltage in the wall outlet, time
> > > > of day differs by 1 minute), so it might be true :-)
> > >
> > > Hmm.. works here with 2.5.1-pre8.
> > >
> > > -Mike
> > > ...
> > > RAMDISK driver initialized: 16 RAM disks of 12288K size 1024 blocksize
> > > ...
> > > RAMDISK: Compressed image found at block 0
> > > Freeing initrd memory: 5161k freed
> > > MINIX-fs: mounting unchecked file system, running fsck is recommended.
> > > VFS: Mounted root (minix filesystem).
> > > Freeing unused kernel memory: 236k freed
> >
> > I'd like to try it, can you send a .config?
>
> .config?.. normal config with initrd+ramdisk+minix in kernel.
Yes. I want to take .config file from your kernel tree
for testing.
> > Have you tried it with minix initrd from
> >
> > http://port.imtp.ilyichevsk.odessa.ua/linux/vda/minix.gz
>
> No, I converted my 'fire department' initrd to minix and booted that.
I'll compile 2.5.1-pre8 here and try to boot my initrd.
If it boots ok, it would mean there is no problem with kernel
(i.e. my fault), if it won't, that will imply that _some_ minix initrds
are affected. Hope you got the idea...
BTW, is it possible for you to place your initrd on some publicly accessible
ftp/http server?
--
vda
On Sun, 16 Dec 2001, vda wrote:
> BTW, is it possible for you to place your initrd on some publicly accessible
> ftp/http server?
Point me at an ftp server that will allow put. Alternately, I can mail
you the .config and image if your mta accepts mondo messages.
I can't imagine how one fs image could load/work and another not unless
maybe your bootloader is screwing up placement. I use loadlin.
-Mike
I've been following this discussion with interest as I've also
been having initrd problems recently with a setup that used to
work perfectly.
I haven't completely tracked it down, but for me, it seems to
be the initrd *build* that is the problem, rather than the kernel
booting the initrd.
My initrd is ext2, uses busybox as init (not using linuxrc or
pivot_root) - it is booted over the network using the pxelinux
boot loader (part of Peter Anvin's syslinux package.)
I take the same set of files and convert them into an initrd
multiple times. Some of the images will boot (every time) and
some won't - ever.
When they don't boot, the last messages on the console are:
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1197k freed
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 388k freed
and then the system just hangs. When it works, the messages are
identical up to that point but continue...
init started: BusyBox v0.51 (2001.04.25-13:32+0000) multi-call binary
(etc.)
I have a complete set of files and dev nodes for the initrd in
./rootfs. They add up to about 3 MB. Nothing too unusual - busybox,
glibc 2.1.3, etc.
My build system kernel is 2.4.16, has the standard 4 MB ramdisk,
and I use the following script to create the initrd:
#!/bin/bash
rm -rf initrd.gz
umount /dev/ram
mke2fs -m0 /dev/ram 4000
mount -t ext2 /dev/ram /mnt/ramdisk
cp -a rootfs/* /mnt/ramdisk
umount /dev/ram
dd if=/dev/ram bs=1k count=4000 of=initrd
gzip initrd
If I run this script several times, the resulting "initrd.gz"
files are different each time (of course - different timestamps
and file ordering in the image). They are all about 1.2 MB.
Some of them boot and some of them don't. I can take a non-working
image, gunzip it, dd it back to the ramdisk, mount it, and
recursively diff it against the original rootfs and find nothing
wrong.
I thought this was a 2.4 kernel bug until I found that my older
2.2.19 kernel works or fails on the same initrd.gz files as the
new 2.4.16 kernel.
But I never used to have this problem when I built initial
ramdisks (using the *same* script and *same* files) under 2.2.19,
so maybe the problem is that creating initrd's on 2.4.x is buggy?
The other variable is I used to build them with Mandrake 7.2,
I've since upgraded to Mandrake 8.1. Perhaps the problem is the
version of gzip I use, or something else in the distribution.
Anyway, I hope to track this down today.
Very weird, and _very_ annoying. Wasted 4 hours on this Friday.
Torrey Hoffman
On Mon, 17 Dec 2001, Torrey Hoffman wrote:
> Some of them boot and some of them don't. I can take a non-working
> image, gunzip it, dd it back to the ramdisk, mount it, and
> recursively diff it against the original rootfs and find nothing
> wrong.
Check permissions/ownership. That doesn't show up in diff...
On Mon Dec 17, 2001 at 10:38:51AM -0800, Torrey Hoffman wrote:
>
> and then the system just hangs. When it works, the messages are
> identical up to that point but continue...
>
> init started: BusyBox v0.51 (2001.04.25-13:32+0000) multi-call binary
> (etc.)
Any particular reason you are using a version of busybox that is
quite old? You really should get a newer release -- I've fixed a
lot of bugs since then.
> I have a complete set of files and dev nodes for the initrd in
> ./rootfs. They add up to about 3 MB. Nothing too unusual - busybox,
> glibc 2.1.3, etc.
>
> My build system kernel is 2.4.16, has the standard 4 MB ramdisk,
> and I use the following script to create the initrd:
>
> #!/bin/bash
>
> rm -rf initrd.gz
> umount /dev/ram
> mke2fs -m0 /dev/ram 4000
> mount -t ext2 /dev/ram /mnt/ramdisk
> cp -a rootfs/* /mnt/ramdisk
> umount /dev/ram
> dd if=/dev/ram bs=1k count=4000 of=initrd
> gzip initrd
Can you sucessfully chroot into your rootfs dir?
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--