[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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)\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.



Reply to: