initramfs: is it supposed to work?

From: Michael Tokarev
Date: Thu Dec 30 2004 - 19:51:50 EST


I tried to play with initramfs (aka cpio "image") and 2.6.10
kernel, and have several questions, main of them is whenever
it is supposed to work at all at this stage.

By replacing "standard" initrd filesystem (be it romfs, cramfs,
or even ext2), when it works with /sbin/init started with pid=1
and does pivot_root() after mounting real root, with a cpio image
containing all the same files (plus /init which is just a link
to /sbin/init), I managed to get it to boot just fine (I used a
little shell script to generate the cpio archive, quite similar
to what usr/gen_init_cpio.c does -- fun excersise in shell
programming). So far so good.

But now, the only problem left is that the kernel does not want
to do the last step: to umount the /initrd (which is initramfs
after pivot_root) after booting: kernel enters an endless loop
inside umount() syscall somewhere (system locks up completely
and starts "eating" cpu which is quite visible on a laptop:
the fans starts rotating after about half a minute after entering
the umount() call), not even responding to sysrq requests.

Maybe I did something wrong when creating the initramfs image
(it is normal cpio archive, and gen_init_cpio.c does the same
thing given the same set of files). I tried both with and
without the root entry in the archive (gen_init_cpio.c does
not include the entry for /, and there's nothing in docs,
in early-userspace/buffer-format.txt, about this one) -- the
same effect, endless loop when trying to umount(/initrd).

After looking at this more closely (but still "outside" the
kernel), I noticied several more "issues" (or is it the same?).
Namely, /proc/mounts contains different things when using one
of the 3 different "boot methods":

o When booting the "old way", with root=real_root, and when
/linuxrc gets executed with pid != 1, /proc/mounts contains
just one entry for root, which is the right one:
/dev/hda1 / ext3 rw 0 0

o When booting the "new way", whth root=/dev/ram0 and /sbin/init
from initrd running with pid = 1 and doing pivot_root and execing
real /sbin/init, there are 2 entries for root in /proc/mounts:
rootfs / rootfs rw 0 0
/dev/hda1 / ext3 rw 0 0
or, sometimes, it is like
rootfs / rootfs rw 0 0
/dev/root / ext3 rw 0 0
-- this one probably is due to devfs. (on debian with their initrd
stuff it looks even worse, something like
rootfs / rootfs rw 0 0
/dev2/root2 / ext3 rw 0 0
).
o And finally, when booting the "right way", using initramfs where
/init gets executed with pid=1 and should do the same pivot_root
and things like that, before the umount loop mentioned above,
it looks almost right:
rootfs /initrd rootfs ro 0 0
/dev/hda1 / ext3 rw 0 0
(this is where eg umount from busybox chokes, also entering
endless loop.. but tha's a different story, it's an obvious
bug in busybox.. however in order to fix it properly one have
to know which cases like the 3 mentioned above are possible).

When the "rootfs" thing enters into the game?
In which cases which lines will be present in /proc/mounts?
And, is initramfs supposed to work now?

Thank you.

/mjt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/