Re: 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)\n", 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)\n", what);
if (lstat(what, &st))
return errno;
@@ -134,6 +136,7 @@
int rv;
int err = 0;
+ fprintf(stderr, "- nuke(%s)\n", 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
Reply to: