Florent Carpentier wrote:
--- En date de : Lun 14.7.08, Hugo Vanwoerkom <[EMAIL PROTECTED]> a écrit :
De: Hugo Vanwoerkom <[EMAIL PROTECTED]>
...
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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
