From: Michael Tokarev <mjt@tls.msk.ru>
To: linux-kernel@vger.kernel.org
Subject: initramfs: is it supposed to work?
Date: Fri, 31 Dec 2004 03:51:50 +0300 [thread overview]
Message-ID: <41D4A2A6.3060607@tls.msk.ru> (raw)
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
next reply other threads:[~2004-12-31 0:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-31 0:51 Michael Tokarev [this message]
2004-12-31 8:06 ` initramfs: is it supposed to work? H. Peter Anvin
2005-01-01 15:40 ` Andreas Jellinghaus
2005-01-01 20:31 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41D4A2A6.3060607@tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox