Repost :umount: /initrd: not mounted
Andy Green
fedora at warmcat.com
Sun Jan 18 22:46:37 UTC 2004
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 18 January 2004 22:19, Alexander Dalloz wrote:
> /initrd exists? chowned by root.root and chmod 755.
I know a little about what /initrd is for. I don't know the answer to the
original question tho, nor do I fully understand all the steps. Also this is
from memory :-) But its basically right.
In /boot there is a compressed ext2 initrd filesystem to match the kernel
version. The kernel commandline in Redhat is set so that after the kernel
has completed its startup action (the scrolling text even when using rhgb) it
will unzip the compressed initrd filesystem and jump into it.
The kernel looks for an executable file called linuxrc in the initrd and runs
it. linuxrc has a #!/bin/nash or similar at the top in Redhat, so it runs
nash, a kind of ultra-simplified bash/busybox kind of interpreter and goes
through the steps listed in this linuxrc script.
One of the first jobs is to load up the jbd (Journalled Block Device) and ext3
modules. The kernel is compiled with ext3 as a module, without this step
during the initrd phase the kernel could not handle an ext3 partition later.
Then it sets up some things /dev, mounts /proc, and then mounts the root
filesystem readonly at a mountpoint which is IIRC /sysroot inside the initrd
filesystem. Then it does a pivot_root which makes /sysroot the new /, and
the original initrd / is meant to end up at what used to be /sysroot/initrd
but is now /initrd. (Note for this reason if you delete the initrd
mountpoint in your root filesystem, you won't be able to boot)
Then the boot process finishes with linuxrc and should start with /sbin/init
using the root filesystem as / as set up by the pivot_root. init then goes
on to check / for errors, remounts it rw and then does the rhgb / [OK] part
of the boot that we know and love.
One the pivot_root is done and the intended root filesystem is appearing at /,
there is no need subsequently for the original initrd to appear any longer at
/initrd, so I guess that is when it is unmounted. If for some reason it is
already unmounted, or the pivot_root somehow failed to deliver it to the root
filesystem /initrd (while successfully doing the pivot of the initrd /sysroot
to become the new root) then I guess that doesn't affect anything. Would be
interesting to know why tho!
- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFACwzNjKeDCxMJCTIRAp3SAJ4g4CXDiS2fUYH2lnw2GGoyFu2gRQCfRLMN
46EJsvD0HcYcA+Akya6lBc0=
=c4JO
-----END PGP SIGNATURE-----
More information about the fedora-list
mailing list