FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 07-13-2008, 10:01 PM
Florent Carpentier
 
Default run-init: nuking initramfs contents: Directory not empty

Hello,

I have observed the following symptoms when booting a vanilla 2.6.25.10 kernel with an initramfs (created with `mkinitramfs -o /boot/initrd.img-2.6.25.10 2.6.25.10') on an etch (on a PC).

...
mount: Mounting /dev on /root/dev failed: Invalid argument
...
run-init: nuking initramfs contents: Directory not empty

The last error causes the end of the boot process with a kernel panic.

I found several messages on the internet (especially on Ubuntu forums) describing the same symptoms.

I ended up adding traces to run-init from the klibc 1.4.34 package. This showed there was a problem when trying to remove /dev/.static/dev/.

It appears that scripts/init-bottom/udev executes
mount -n -o bind /root/dev /dev/.static/dev
This is most likely the immediate cause for the run-init failure to remove this directory, which in turn causes the kernel panic.

I do not know if this is actually related to the version of the kernel. I do not know the fundamental issue. As a consequence, the following solution is probably more of a hack than a real fix. However, some people might find it useful.

You can try to prevent scripts/init-bottom/udev from executing the problematic mount command by changing a configuration option the following way:

# Unpack the initramfs
cd
mkdir initrd-2.6.25.10
cd initrd-2.6.25.10
gunzip -c /boot/initrd.img-2.6.25.10 | cpio -idv

# Add the option
echo 'no_static_dev=1' >> etc/udev/udev.conf

# Create the new initramfs archive and install it
find | cpio --quiet --dereference -o -H newc | gzip -9
> ../initrd.img-2.6.25.10
su
cp -p /boot/initrd.img-2.6.25.10 /boot/initrd.img-2.6.25.10.orig
install -oroot -groot -m644 ../initrd.img-2.6.25.10 /boot/

This allowed the OS to boot and work flawlessly. However, I obviously cannot guarantee this will work in all set-ups.

FC

Note: I did not subscribe to the debian-user list.


__________________________________________________ ___________________________
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-14-2008, 11:50 AM
Hugo Vanwoerkom
 
Default run-init: nuking initramfs contents: Directory not empty

Florent Carpentier wrote:

Hello,

I have observed the following symptoms when booting a vanilla 2.6.25.10 kernel with an initramfs (created with `mkinitramfs -o /boot/initrd.img-2.6.25.10 2.6.25.10') on an etch (on a PC).

...
mount: Mounting /dev on /root/dev failed: Invalid argument
...
run-init: nuking initramfs contents: Directory not empty

The last error causes the end of the boot process with a kernel panic.

I found several messages on the internet (especially on Ubuntu forums) describing the same symptoms.

I ended up adding traces to run-init from the klibc 1.4.34 package. This showed there was a problem when trying to remove /dev/.static/dev/.

It appears that scripts/init-bottom/udev executes
mount -n -o bind /root/dev /dev/.static/dev
This is most likely the immediate cause for the run-init failure to remove this directory, which in turn causes the kernel panic.

I do not know if this is actually related to the version of the kernel. I do not know the fundamental issue. As a consequence, the following solution is probably more of a hack than a real fix. However, some people might find it useful.

You can try to prevent scripts/init-bottom/udev from executing the problematic mount command by changing a configuration option the following way:



<snip>

Very interesting. A couple of questions:

Why use `mkinitramfs -o /boot/initrd.img-2.6.25.10 2.6.25.10' instead of
letting the kernel install process do that, or is that what you mean?


How did you add traces to run-init?

BTW I run vanilla 2.6.25.9 because I cannot get Debian's 2.6.25 to boot
right, why do you run vanilla 2.6.25.10?


Hugo


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-15-2008, 10:52 AM
Florent Carpentier
 
Default run-init: nuking initramfs contents: Directory not empty

--- En date de : Lun 14.7.08, Hugo Vanwoerkom <hvw59601@care2.com> a écrit :

> De: Hugo Vanwoerkom <hvw59601@care2.com>

...

>
> Very interesting. A couple of questions:
>
> Why use `mkinitramfs -o /boot/initrd.img-2.6.25.10
> 2.6.25.10' instead of
> letting the kernel install process do that, or is that what
> you mean?
>

What do you call the kernel install process? Using make-kpkg and
installing the packages it generated? I never used make-kpkg.
Maybe I should give it a try. It could save some time (after
learning it) and it is probably better to install a kernel package
than installing files all around without any control.

I guess I chose the hard way (compiled and installed the kernel
and modules using the official 2.6.25.10 kernel, created the
initramfs with the Etch mkinitramfs).

>
> How did you add traces to run-init?
>

I do not think it is possible to configure run-init to show
precisely what it is removing during the `nuking initramfs
content' phase.

It might be possible (I did not try) to add strace to the
initramfs and change the last line of /init to
exec strace -e trace=file run-init ${rootmnt} ${init} "$@" <${rootmnt}/dev/console >${rootmnt}/dev/console
However, this would probably have to be used only to debug the
boot process. I wonder what would happen afterwards during a
successful boot.

I simply added print statements to
klibc-1.4.34/usr/kinit/run-init/runinitlib.c, after applying the
Debian patches to klibc, compiled the whole thing, and installed
the static version of run-init to the initramfs.

diff -ru klibc-1.4.34/usr/kinit/run-init/runinitlib.c klibc-1.4.34.new/usr/kinit/run-init/runinitlib.c
--- klibc-1.4.34/usr/kinit/run-init/runinitlib.c 2007-02-07 18:54:45.000000000 +0100
+++ klibc-1.4.34.new/usr/kinit/run-init/runinitlib.c 2008-07-15 11:54:35.000000000 +0200
@@ -77,6 +77,7 @@
int xlen;
struct stat st;

+ fprintf(stderr, "- nuke_dirent(%s/%s)
", dir, name);
xlen = snprintf(path, bytes, "%s/%s", dir, name);
assert(xlen < bytes);

@@ -98,6 +99,7 @@
int err = 0;
struct stat st;

+ fprintf(stderr, "- nuke_dir(%s)
", what);
if (lstat(what, &st))
return errno;

@@ -134,6 +136,7 @@
int rv;
int err = 0;

+ fprintf(stderr, "- nuke(%s)
", what);
rv = unlink(what);
if (rv < 0) {
if (errno == EISDIR) {



>
> BTW I run vanilla 2.6.25.9 because I cannot get
> Debian's 2.6.25 to boot
> right, why do you run vanilla 2.6.25.10?
>

I needed a 2.6.25 kernel to use a Wifi adapter (and I wanted to
stick to Etch). I did not think of looking for it in
etch-backports. Anyway, I also needed to apply a small patch to
the kernel, so I could probably not have got away with the
etch-backports package.

Florent


__________________________________________________ ___________________________
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-15-2008, 12:31 PM
Hugo Vanwoerkom
 
Default run-init: nuking initramfs contents: Directory not empty

Florent Carpentier wrote:

--- En date de : Lun 14.7.08, Hugo Vanwoerkom <hvw59601@care2.com> a écrit :


De: Hugo Vanwoerkom <hvw59601@care2.com>


...


Very interesting. A couple of questions:

Why use `mkinitramfs -o /boot/initrd.img-2.6.25.10
2.6.25.10' instead of
letting the kernel install process do that, or is that what

you mean?



What do you call the kernel install process? Using make-kpkg and
installing the packages it generated? I never used make-kpkg.
Maybe I should give it a try. It could save some time (after
learning it) and it is probably better to install a kernel package
than installing files all around without any control.



Yes, I create .debs for 2.25.9 with:

make-kpkg --revision 1 --initrd kernel_image

and when I install the .deb the initrd.img gets created and installed in
/boot


Hugo




I guess I chose the hard way (compiled and installed the kernel
and modules using the official 2.6.25.10 kernel, created the
initramfs with the Etch mkinitramfs).


How did you add traces to run-init?



I do not think it is possible to configure run-init to show
precisely what it is removing during the `nuking initramfs
content' phase.

It might be possible (I did not try) to add strace to the
initramfs and change the last line of /init to
exec strace -e trace=file run-init ${rootmnt} ${init} "$@" <${rootmnt}/dev/console >${rootmnt}/dev/console
However, this would probably have to be used only to debug the
boot process. I wonder what would happen afterwards during a
successful boot.

I simply added print statements to
klibc-1.4.34/usr/kinit/run-init/runinitlib.c, after applying the
Debian patches to klibc, compiled the whole thing, and installed
the static version of run-init to the initramfs.

diff -ru klibc-1.4.34/usr/kinit/run-init/runinitlib.c klibc-1.4.34.new/usr/kinit/run-init/runinitlib.c
--- klibc-1.4.34/usr/kinit/run-init/runinitlib.c 2007-02-07 18:54:45.000000000 +0100
+++ klibc-1.4.34.new/usr/kinit/run-init/runinitlib.c 2008-07-15 11:54:35.000000000 +0200
@@ -77,6 +77,7 @@
int xlen;
struct stat st;

+ fprintf(stderr, "- nuke_dirent(%s/%s)
", dir, name);
xlen = snprintf(path, bytes, "%s/%s", dir, name);
assert(xlen < bytes);

@@ -98,6 +99,7 @@
int err = 0;
struct stat st;

+ fprintf(stderr, "- nuke_dir(%s)
", what);
if (lstat(what, &st))
return errno;

@@ -134,6 +136,7 @@
int rv;
int err = 0;

+ fprintf(stderr, "- nuke(%s)
", what);
rv = unlink(what);
if (rv < 0) {
if (errno == EISDIR) {




BTW I run vanilla 2.6.25.9 because I cannot get
Debian's 2.6.25 to boot
right, why do you run vanilla 2.6.25.10?




I needed a 2.6.25 kernel to use a Wifi adapter (and I wanted to
stick to Etch). I did not think of looking for it in
etch-backports. Anyway, I also needed to apply a small patch to
the kernel, so I could probably not have got away with the
etch-backports package.




--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 12:55 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org