initrd, pivot_root and initctl woes...

Hans Zarkoff · 12-21-2002, 12:49 PM

I've done a search for initrd and initctl and could not find any relevant messages. If I've missed one relating to this topic, please tell me.

OK, I better give you a bit of a background before I start...

I have an hpt374 raid card. It works fine when booting from a standard IDE drive. All you do is boot, insmod hpt374, then mount sda{1-4}. But, because the driver is in module form only, I have to create a root disk using an root disk image to install hpt374. This all works too.

The problem is occuring after the pivot_root. The root drive is mounted, the card is found and the partitions on the array recognized. After the pivot, I try to run init on the "real" root disk. At first it complained that it didn't exist, so I created it once with 'mkfifo -m600 /dev/initctl.' That returned, "timeout opening/writing control channel /dev/initctl." I recreated it with, "mknod /dev/initctl p" with the same result.

Is there a step in my linuxrc file I missed to create the file? I've 'grep -r /etc' and there's no mention of the initctl file. Nothing in /usr/src/Documentation or /usr/doc/* either.

This is all on Slack 8.1. 2.4.18 kernel. No native support for hpt374. The module source is located at http://www.highpoint-tech.com

Any help would be greatly appreciated. Thank you.

Hans Zarkoff · 12-21-2002, 12:52 PM

I forgot to mention...

I want to boot from the actual raid device. Of course, in order to mount the root disk, you must have drivers loaded. But you can't have drivers loaded until you mount the device. Catch-22. Hence my need for a RAMdisk.

Dunno if this helps...

nxny · 12-21-2002, 02:22 PM

According to my limited knowledge, init/telinit always assumes it is already running on root filesystem. /dev/initctl is a FIFO that init listens to. When you ask init/telinit to let's say switch runlevels for example, it is fed to init via this FIFO. So if init isnt already running using the *same* root filesystem, nobody is at the other end of the pipe to pickup this information. Hope that explains the timeout.

For the same reason, you may not manually chroot to your mounted root filesystem from a rescue cd(or another hard drive in your case) and call init as root. Because, the /dev/initctl under the new root is not alive.

Have you considered using an initrd with the necessary module? That way, the kernel would have access to the module and hence the SCSI root device would be available when the kernel is about to call init. That would catch the catch 22 by the ba**s.

In redhat, the mkinitrd shell-script will take care of things for you, but for slackware I recommend reading the Root raid howto . It has rather detailed intructions to help you make an initrd and boot from it, from a first glance. The document seems a l'il outdated.. I read loadlin and slackware 3.4 a couple of times, but the concept is what matters, I guess.

HTH

Hans Zarkoff · 12-22-2002, 11:17 PM

Quote:

Originally posted by nxny
According to my limited knowledge, init/telinit always assumes it is already running on root filesystem. /dev/initctl is a FIFO that init listens to. When you ask init/telinit to let's say switch runlevels for example, it is fed to init via this FIFO. So if init isnt already running using the *same* root filesystem, nobody is at the other end of the pipe to pickup this information. Hope that explains the timeout.

Makes sense.

Quote:

Have you considered using an initrd with the necessary module? That way, the kernel would have access to the module and hence the SCSI root device would be available when the kernel is about to call init. That would catch the catch 22 by the ba**s.

[/B][/QUOTE]

Unless I misunderstand you, I think I'm doing this now. I have successfully pivot_rooted from the initrd to the actual root disk, /dev/sda1. I would *assume* (and yes, I know what assuming does

) that pivot_root would properly initialize initctl on the real root disk, or at least allows init to communicate with a manually-created initctl.

Thank you for replying.

nxny · 12-23-2002, 12:32 PM

Quote:

Originally posted by Hans Zarkoff
Unless I misunderstand you, I think I'm doing this now. I have successfully pivot_rooted from the initrd to the actual root disk, /dev/sda1. I would *assume* (and yes, I know what assuming does

) that pivot_root would properly initialize initctl on the real root disk, or at least allows init to communicate with a manually-created initctl.
[/B]

Somehow I got the impression from you first message that you are booting your system from an ide hard drive, 'insmod'ing your RAID module and trying to chroot to the RAIDed HDD before calling init.

I have a few questions..

1) what distro do you have on the SCSI HDD?
2) How did the /dev/initctl disappear before you manually created it? Or why wasnt it already there?
3) Have you already presented this issue before the kernel mailing list?

Hans Zarkoff · 12-23-2002, 02:15 PM

Ah, sorry about that. I only mentioned the IDE drive to indicate that the raid card and the rest of the system is working properly. Sorry 'bout that. I want to be able to boot from the raid drive.

1. Slackware 8.1.

2. It was never there. I don't know why--Apart from rudimentary lilo.conf entries, I've not done any lower-level booting administration.

3. No. This looks to me like a user problem, not a system problem. At least, not yet... I'll go search the archives though...

Honestly, I don't believe it's technically a kernel question. The machine boots just fine, the kernel loads, my linuxrc* script runs but dies at the 'chroot . /sbin/init q <dev/console >dev/console 2>&1' line with the 'timeout opening/writing control channel /dev/initctl.'

From my reading on the 'Net, it looks like init can create initctl, but it doesn't.

I'll figure this out yet!

nxny · 12-23-2002, 07:39 PM

I cant see how a reinstall might help you here, all it does is destroy evidence. And you dont sound like "I need it running by yesterday", which is a very good attitude for solving problems and thereby learning things.

I agree that this doesn't seem to be a kernel issue at all. I suggested a kernel mailing list because the people who usually hang out and answer questions at those places have hardcore knowledge of the kernel internals to give you an authoritative answer like "Nope, pivot_root with this kind of setup is just not possible unless you do this" than something tentative like try this or try that. Chances are that someone might've seen this happen a couple hundred times. Does that sound reasonable?

nxny · 12-31-2002, 05:52 PM

Quote:

Originally posted by Hans Zarkoff
I've done a search for initrd and initctl and could not find any relevant messages. If I've missed one relating to this topic, please tell me.

OK, I better give you a bit of a background before I start...

I have an hpt374 raid card. It works fine when booting from a standard IDE drive. All you do is boot, insmod hpt374, then mount sda{1-4}. But, because the driver is in module form only, I have to create a root disk using an root disk image to install hpt374. This all works too.

The problem is occuring after the pivot_root. The root drive is mounted, the card is found and the partitions on the array recognized. After the pivot, I try to run init on the "real" root disk. At first it complained that it didn't exist, so I created it once with 'mkfifo -m600 /dev/initctl.' That returned, "timeout opening/writing control channel /dev/initctl." I recreated it with, "mknod /dev/initctl p" with the same result.

Is there a step in my linuxrc file I missed to create the file? I've 'grep -r /etc' and there's no mention of the initctl file. Nothing in /usr/src/Documentation or /usr/doc/* either.

This is all on Slack 8.1. 2.4.18 kernel. No native support for hpt374. The module source is located at http://www.highpoint-tech.com

Any help would be greatly appreciated. Thank you.

Were you able to solve this issue?

Hans Zarkoff · 01-01-2003, 05:19 PM

No, I'm still stuck at that point. But then, I haven't posted to the kernel mailing list or reinstalled the OS.

I did find that the hpt374 chipset is supported in 2.4.20, but it doesn't support the raid extensions, as far as I can tell. So I could move the newer kernel onto to drive and be able to use it as a regular IDE controller but that wouldn't be sporting.

I will continue to bang my head against it before inevitably asking the folks at kernel.org for help. I will be sure to post any solution to the list for future reference.

Richard

watersb · 01-11-2003, 05:51 PM

I am having exactly the same problem with pivot_root.

I created an initrd as a minix filesystem (very low overhead) that I mount as an initial ramdisk.

Here is the linuxrc file for the system that I got to actually work:

Code:

#!/bin/sh
PATH=/sbin:/bin:/usr/bin:/usr/sbin
/bin/mount -n -t proc none /proc

echo "Mounting encrypted filesystem..."
losetup -e twofish -k 256 /dev/loop/5 /dev/ide/host0/bus0/target0/lun0/part4

echo "0x705" > /proc/sys/kernel/real-root-dev

It's that last line that does a pivot_root sort of thing -- you poke the char-major and char-minor of the actual root device (formatted as two hexdecimal bytes) into the magic file, /proc/sys/kernel/real-root-dev.

This kludge only works with pre-2.5 kernels, and is supposed to go away with the next kernel release. It works for me under 2.4.18.

Now, here is the code that I tried to get to work, and ran into exactly the same problem with /dev/initctl:

Code:

#!/bin/sh
PATH=/usr/sbin:/usr/bin:/sbin:/bin

mount -oremount,rw /
mount -n -t proc none /proc

# Create the new root FS
mkdir /newroot

# Mount the cryptoloop
echo "Mounting encrypted filesystem..."
losetup -e twofish -k 256 /dev/loop/5 /dev/ide/host0/bus0/target0/lun0/part4

echo "...cryptoloop on /newroot ..."
mount /dev/loop/5 /newroot
cd /newroot

umount /proc
pivot_root . initrd
exec chroot . /sbin/init </dev/console >/dev/console 2>&1

watersb · 01-11-2003, 06:19 PM

I have found an excellent write-up on linux boot procedures at

http://www.isg.rhul.ac.uk/~nessim/pa...nux-current.ps

which I found from

http://www.isg.rhul.ac.uk/~nessim/rh...iant_1500.html

If I can get my problem licked, I certainly let everyone know!

nxny · 01-12-2003, 04:59 AM

Very interesting. Sounds like you're close to getting initctl bend over backwards!! Thanks for updating us here!! I'll try to do this myself from a rescue disk when I get a chance.

echan4 · 03-04-2003, 04:35 AM

Hello,

I have the same problem with linuxrc , pivot_root and chroot. The problem was linuxrc did not run with PID==1 ( its needs to as init
requires it to be )/

And solved it by
doing the following:

in my kernel command line:
root=/dev/ram0 rw init=linuxrc

in linuxrc

mkdir new_root
mount -t ext2 /dev/hda1 /new_root # change hda[ 1:10] to suit
cd /new_root
if [ -d initrd ] ; then
:
else
mkdir initrd
fi
pivot_root . initrd # same as in initrd.txt
chroot . /sbin/init</dev/console 2>/dev/console # same as in initrd.txt

And linuxrc runs with PID == 1; I got all the above info from reading another forum.

Regards.
edc

echan4 · 03-04-2003, 04:53 AM

my apologies;

on (post #13) the kernel command line it should read:

root=/dev/ram0 rw init=/linuxrc

and in linuxrc

exec chroot . /sbin/init </dev/console >/dev/console 2>&1

regards,

edc

nxny · 03-04-2003, 06:22 AM

Quote:

Originally posted by echan4
Hello,

I have the same problem with linuxrc , pivot_root and chroot. The problem was linuxrc did not run with PID==1 ( its needs to as init
requires it to be )/

And solved it by
doing the following:

in my kernel command line:
root=/dev/ram0 rw init=linuxrc

in linuxrc

mkdir new_root
mount -t ext2 /dev/hda1 /new_root # change hda[ 1:10] to suit
cd /new_root
if [ -d initrd ] ; then
:
else
mkdir initrd
fi
pivot_root . initrd # same as in initrd.txt
chroot . /sbin/init</dev/console 2>/dev/console # same as in initrd.txt

And linuxrc runs with PID == 1; I got all the above info from reading another forum.

Regards.
edc

Welcome to LQ, echan4!

Good job. And thanks for posting it here. Can't tell you how much I appreciate it. Most people dont worry about it once they solve the problem.

Yeah, I'd posted this issue to the LKML a while ago and it was replied to by Miquel Van Smoorenberg ( the author of init himself ) who said init behaves like telinit unless it is PID 1. That was the giveaway. Well it is written explicitly in the man page of init, but I'm surprised it didnt gather too much attention.

BTW, why did you have to use that explicit command line? When you use an initrd with a kernel choice, the bootloader should generate this command line implicitly is what I thought. Please post your bootloader configuration file here.

In case you didn't know ( I noticed your follow-up post ), you can edit your previous posts.