Re: Initrd Question

Re: Initrd Question

[der.eremit]

> echo "Initial RAMDISK Loading Starting..."

Did you get this message when trying your initrd? If not, you probably
forgot to pass the kernel a root=/dev/ram0 boot option.

> insmod /lib/megaraid.ko
> insmod /lib/aic7xxx.ko
> insmod /lib/uhci-hcd.ko
> echo "Mounting proc..."
> mount -n -t proc none /proc
> echo 0x0100 > /proc/sys/kernel/real-root-dev

This makes no sense as you're using pivot_root. The old method requires
terminating the initrd script, then the kernel attempts to mount
real-root-dev. That never happens as your script doesn't exit, but execs
init instead.

> echo "Mounting real root dev..."
> mount -n -o ro /dev/sda2 /new_root

This doesn't even match with the 0x0100 above, now does it?

> echo "Running pivot_root..."
> pivot_root /new_root /new_root/initrd

You should cd into /new_root before running pivot_root, or does the
pivot_root from busybox somehow do this for you?

> if [ -c initrd/dev/.devfsd ]
>   then
>           echo "Mounting devfs..."
>           mount -n -t devfs none dev
> fi

Should you check for /dev/.devfsd on the real root here? I thought .devfsd
is created by the devfsd process, so wouldn't be on the initrd /dev?

-- 
Ciao,
Pascal

Re: Initrd Question

[der.eremit]

On Fri, 13 Feb 2004 15:20:13 +0100, you wrote in linux.kernel:
>>> echo 0x0100 > /proc/sys/kernel/real-root-dev
>> This makes no sense as you're using pivot_root. 
> this makes all sort of sense. Please check sources. It is required so
> that kernel will not attempt to mount root passed to it by loader.
> You are welcome to clean up the code :)

I'm not doing that and it works as expected. Note that the initrd code
in question never exits. It execs init. So when would the kernel do
this attempted mount of the root filesystem passed in by the bootloader?
My understanding is that the old, non-pivot_root method works by
exiting the initrd script - and *then* the kernel attempts to mount
real-root-dev.

In any case, if that wasn't clear, I expect the bootloader to pass
in root=/dev/ram0 anyway. ;)

>>> mount -n -o ro /dev/sda2 /new_root
>>
>> This doesn't even match with the 0x0100 above, now does it?
>
> so what? kernel happily ignores real-root-dev, it is possible that
> some user-level tools may be confused but I have not seen any so far.

Now you're saying the kernel ignores real-root-dev, while a moment
before you state that it is important to set real-root-dev because
otherwise the kernel does something. Which is it?

>>> pivot_root /new_root /new_root/initrd
>> You should cd into /new_root before running pivot_root,
> Huh? Why?
>
> SYNOPSIS
>        pivot_root new_root put_old

And just a couple of lines further down:

       Note that, depending on the implementation of pivot_root, root and  cwd
       of  the  caller  may or may not change. The following is a sequence for
       invoking pivot_root that works in either case, assuming that pivot_root
       and chroot are in the current PATH:
                            
       cd new_root
       pivot_root . put_old
       exec chroot . command

The pivot_root(2) manpage states the same, by the way.
                                                 
-- 
Ciao,
Pascal

Re: Initrd Question

[Jim Gifford]

So is the /proc/real-root-dev seems to be a necessary file after all for the
pivot_root to work, is that correct? If so the initrd.txt needs to be
updated.

Re: Initrd Question

[H. Peter Anvin]

Followup to:  <E1ArfAQ-00007f-7Z@localhost>
By author:    der.eremit@email.de
In newsgroup: linux.dev.kernel
> 
> Now you're saying the kernel ignores real-root-dev, while a moment
> before you state that it is important to set real-root-dev because
> otherwise the kernel does something. Which is it?
> 

You have to set root=/dev/ram0 in the boot loader, so that the kernel
will spawn /sbin/init with pid 1.  Otherwise it spawns /linuxrc with a
non-1 pid, for dumb historical reasons.

Thus, setting it in the script is too late to do any good.

	-hpa
-- 
PGP public key available - finger hpa@zytor.com
Key fingerprint: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
"The earth is but one country, and mankind its citizens."  --  Bahá'u'lláh
Just Say No to Morden * The Shadows were defeated -- Babylon 5 is renewed!!

Re: Initrd Question

["Andrey Borzenkov"]

>> echo 0x0100 > /proc/sys/kernel/real-root-dev
>
> This makes no sense as you're using pivot_root. 

this makes all sort of sense. Please check sources. It is required so that kernel will not attempt to mount root passed to it by loader. You are welcome to clean up the code :)

>> mount -n -o ro /dev/sda2 /new_root
>
> This doesn't even match with the 0x0100 above, now does it?

so what? kernel happily ignores real-root-dev, it is possible that some user-level tools may be confused but I have not seen any so far.

>> pivot_root /new_root /new_root/initrd
>
> You should cd into /new_root before running pivot_root,

Huh? Why?

SYNOPSIS
       pivot_root new_root put_old

>> if [ -c initrd/dev/.devfsd ]
>>   then
>>           echo "Mounting devfs..."
>>           mount -n -t devfs none dev
>> fi
>
> Should you check for /dev/.devfsd on the real root here? I thought .devfsd
> is created by the devfsd process, 

you are wrong here, sorry. .devfsd is created by devfs.

-andrey

Re: Initrd Question

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

On Fri, 13 Feb 2004 17:14:25 +0300, =?koi8-r?Q?=22?=Andrey Borzenkov=?koi8-r?Q?=22=20?= said:

> > Should you check for /dev/.devfsd on the real root here? I thought .devfsd
> > is created by the devfsd process, 
> 
> you are wrong here, sorry. .devfsd is created by devfs.

I see the confusion - .devfsd gets created in the directory that is
/dev at the time devfs starts up.  However, after pivot_root, that directory
has a new name, and that's where we need to check for .devfsd.

It gets even more confusing in some configurations where we end up unmounting
/initrd/dev and then re-mounting /dev just to get it into the right place..

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

RE: Initrd Question

[Robert White]

In a modern kernel you can safely multiply mount file systems.  In
particular, if you are going to pivot_root you might be better off and
happier if you mount devfs and procfs (and sysfs) in both the old and new
locations before the pivot.

So mount /dev and /proc and /sysfs (etc) as needed before the pivot.
Mount /new-root.
Then mount /new-root/dev /new-root/proc /new-root/sysfs /new-root/dev/devpts
(etc) as you expect to need it after the pivot
Do the pivot.
Then unmount the unneeded /old-root/dev etc.

This should make things much more convenient.

Mount what you need, but don't mount things that init scripts will mount
later.  There isn't much harm to be had in mounting something over itself
(e.g. "mount -t devfs devfs /dev" twice in a row) but it keeps things like
/proc/mounts nice and tidy if you keep it all straight.

Rob.

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of
Valdis.Kletnieks@vt.edu
Sent: Friday, February 13, 2004 6:23 AM
To: Andrey Borzenkov
Cc: der.eremit@email.de; linux-kernel@vger.kernel.org
Subject: Re: Initrd Question 

On Fri, 13 Feb 2004 17:14:25 +0300, =?koi8-r?Q?=22?=Andrey
Borzenkov=?koi8-r?Q?=22=20?= said:

> > Should you check for /dev/.devfsd on the real root here? I thought
.devfsd
> > is created by the devfsd process, 
> 
> you are wrong here, sorry. .devfsd is created by devfs.

I see the confusion - .devfsd gets created in the directory that is
/dev at the time devfs starts up.  However, after pivot_root, that directory
has a new name, and that's where we need to check for .devfsd.

It gets even more confusing in some configurations where we end up
unmounting
/initrd/dev and then re-mounting /dev just to get it into the right place..

Initrd Question

[Jim Gifford]

I wrote the initrd hint for the Linux from Scratch. I have followed the
initrd.txt exactly to the letter. The problem I have noticed is with one of
the commands, and I checked other mkinitrd scripts and they have the
workaround in it.

According to initrd.txt the  echo 0x301 >/proc/sys/kernel/real-root-dev is
for the old change root mechanism, but I have tried to elminate that from my
script and it fails everytime saying it can't find the root, the infamous
Kernel panic: VFS: Unable to mount root fs on xx:xx. Here is my linuxrc
script that is built from my mkinitrd script which can be viewed at
http://cvs.jg555.com/viewcvs.cgi/scripts/system/mkinitrd.

I use busybox for my script so I can keep the size down. My current size is
only 387k.

#!/bin/sh

echo "Initial RAMDISK Loading Starting..."
insmod /lib/megaraid.ko
insmod /lib/aic7xxx.ko
insmod /lib/uhci-hcd.ko
echo "Mounting proc..."
mount -n -t proc none /proc
echo 0x0100 > /proc/sys/kernel/real-root-dev
echo "Mounting real root dev..."
mount -n -o ro /dev/sda2 /new_root
echo "Running pivot_root..."
pivot_root /new_root /new_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
echo "Initial RAMDISK Loading Completed..."



----
Jim Gifford
maillist@jg555.com

Re: Initrd Question

[Chris Lingard]

On Friday 13 February 2004 3:12 am, Jim Gifford wrote:
> I wrote the initrd hint for the Linux from Scratch. I have followed the
> initrd.txt exactly to the letter. The problem I have noticed is with one of
> the commands, and I checked other mkinitrd scripts and they have the
> workaround in it.

With regards to the initrd.txt hint. (2.4.x kernels)

It does not work with the     "  root=/dev/rd/0   (with devfs) "
unless         { "rd/0",     0x0100 },   is added to the root_dev_names[] 
__initdata array; (init/do_mounts.c)

You need to use "root=/dev/ram0" with or without devfs. (or change 
init/do_mounts.c).  Patches to either code or documentation if you want.

Chris

initrd question

[Kelledin Tane]

Concerning the new way initrd works in 2.4...

I'm trying to get the system to the point where I can free the memory
used by the initrd.  I'm quite well aware of how to do this in a bash
script, but I want to know how to do the same from a C program.
Currently, something's keeping /dev/ram0 busy, so I know I'm doing
something wrong.

Kelledin