initrd + busybox error

Pedro Salazar pedro-b-salazar at ptinovacao.pt
Mon Jul 7 04:38:08 PDT 2003


Greetings,

thanks for help and I'm answering now because I didn't access my emails
during the weekend.

> At a guess, things are going wrong here. /bin/sh is a link to busybox,
> which will be called with argv[0]="linuxrc". If you did not comment
> out #define BB_FEATURE_LINUXRC in busybox-*/Config.h busybox will
> try to run init.
> 
> I think you did comment out #define BB_INIT, so linuxrc crashes.
> 
> Last time I checked (busybox-0.60.5) busybox assumed linuxrc runs as
> process 1. This has not been true since linux 2.4.20, you cannot test
> an initial ramdisc with BB_INIT.
> 

I had the #define BB_INIT commented in - I commented it out and it
appears to give more messages, I don't know if it's better or worst, but
now I didn't get the "Kernel Panic: Attempted to kill init". 

I'm using the latest kernel, 2.4.21.

> Things will get a bit unpredictable at this point because I do not know
> which root device is specified on the command line. As you are
> following ancient documentation, you probably specified the initial
> ramdisc as root. These days you should specify the required final
> root device. If you did not specify on the command line, you will get
> the device set into the kernel image with rdev.
> 

Well, I have no problems to use the real root device instead  the
/dev/ram0, however I must understand the procedure. See note below.

> The documentation you read about linuxrc applies to kernels before
> 2.4.20. Modern ones do the work for you. Now my custom init scripts
> start doing things:
> 
> <6>Adding Swap: 1150968k swap-space (priority -1)
> ...
> 
> 
> Back to you linuxrc:
> 
> > echo "Initial RAMDISK Loading Starting..."
> > insmod /lib/scsi_mod.o
> > insmod /lib/sd_mod.o
> > insmod /lib/usbcore.o
> > insmod /lib/usb-storage.o
> > insmod /lib/usb-ohci.o
> > insmod /lib/ehci-hcd.o
> > echo "Initial RAMDISK Loading Completed..."
> > mkdir /new_root
> not needed
> 
> > echo "Mounting proc..."
> > mount -n -t proc none /proc
> I hope /proc exists
> 
> > echo 0x0100 > /proc/sys/kernel/real-root-dev
> I prefer root=... in grub's menu.
> 
> 
> > echo "Mounting real root dev..."
> > mount -n -o ro /dev/sda1 /new_root
> not needed
> 
> > umount /proc
> might help, depened is /initrd/ exists.
> 
> 
> delete the rest:
> > cd /new_root
> > echo "Running pivot_root..."
> > pivot_root . initrd
> > if [ -c initrd/dev/.devfsd ]
> >         then
> >                 echo "Mounting devfs..."
> >                 mount -n -t devfs none dev
> > fi
> > if [ $$ = 1 ]
> >         then
> >                 echo "Running init..."
> >                 exec chroot . sbin/init dev/console 2>&1
> >         else
> >                 echo "Using bug circumvention for busybox..."
> >                 exec chroot . sbin/linuxrc dev/console 2>&1
> > fi
> > "

I didn't understand your approach. 
Shouldn't exist a switch of root devices? 

Well, I keep the linuxrc like it was, but run with the new busybox
option (BB_INIT).

1) If I put the root=/dev/ram0, I don't see any initrd message (loading
modules, ...), and the script ends with this message:

Bummer, could not run '/etc/init.d/rcS': No such file or directory.

And after I must press "enter" to go to busybox shell.

2) If I put the root=/dev/sda1, I can see the loading modules and other
messages on screen. However, I'm getting problems in the insmod of
modules! The problem is about scsi_mod.o as you can see in the shell:

root:/# depmod -ae
depmod: *** Unresolved symbols in
/lib/modules/2.4.21/kernel/drivers/scsi/scsi_mod.o
depmod:         req_finished_io


I'll recompile the kernel...

But after the error messages, I got the same message that ends the
script to the busybox shell when I press "enter".

Bummer, could not run '/etc/init.d/rcS': No such file or directory.

Maybe here, the problem could be also generated by the scsi_module,
since the real root device couldn't be mounted (or switched).

For now, I'll try to solve the modules dependences (I don't know if the
script error is also dependent), but I would like to understand tour
approach about the root filesystem mounting.

Thanks,
Pedro Salazar.

-- 
PS
pedro-b-salazar at ptinovacao.pt
PGP:0E129E31D803BC61

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-support' in the subject header of the message



More information about the blfs-support mailing list