initramfs: is it supposed to work?

initramfs: is it supposed to work?

[Michael Tokarev]

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

Re: initramfs: is it supposed to work?

[H. Peter Anvin]

Followup to:  <41D4A2A6.3060607@tls.msk.ru>
By author:    Michael Tokarev <mjt@tls.msk.ru>
In newsgroup: linux.dev.kernel
> 
> 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).
> 

You don't pivot_root initramfs, because initramfs *IS* rootfs.

Instead, use the run-init program from the klibc distribution, or
something similar.  It cleans up the initramfs contents and overmounts
it with the new root filesystem.

	-hpa

Re: initramfs: is it supposed to work?

[Andreas Jellinghaus]

Hi,

run-init seems to mount the new root, rm files in the old root,
mount, chroot, open the console, exec. any reason we can't do
that in shell script commands?
 
> You don't pivot_root initramfs, because initramfs *IS* rootfs.
> 
> Instead, use the run-init program

ok, but still: is it ok for the kernel to die?
after all pivot_root works fine, unless /initrd is unmounted.
what exactly is the kernel internal that makes pivot_root special?

Regards, Andreas

Re: initramfs: is it supposed to work?

[H. Peter Anvin]

Followup to:  <pan.2005.01.01.15.40.12.264342@dungeon.inka.de>
By author:    Andreas Jellinghaus <aj@dungeon.inka.de>
In newsgroup: linux.dev.kernel
>
> Hi,
> 
> run-init seems to mount the new root, rm files in the old root,
> mount, chroot, open the console, exec. any reason we can't do
> that in shell script commands?
>  
> > You don't pivot_root initramfs, because initramfs *IS* rootfs.
> > 
> > Instead, use the run-init program
> 
> ok, but still: is it ok for the kernel to die?
> after all pivot_root works fine, unless /initrd is unmounted.
> what exactly is the kernel internal that makes pivot_root special?
> 

Your /initrd here is rootfs, and by unmounting rootfs, you've pulled
the rug out from underneath the kernel any time it needs to spawn a
kernel thread.

	-hpa