Re: mount weirdness
- From: Nix <nix-razor-pit@xxxxxxxxxxxxx>
- Date: Thu, 29 Mar 2007 08:18:12 +0100
On 26 Mar 2007, Unruh uttered the following:
gordon@xxxxxxxxxx (Gordon Henderson) writes:
In article <slrnf0e4v4.6hn.h@xxxxxxxxxxx>,
Tony Houghton <h@xxxxxxxxxxx> wrote:
Does mount ignore the entry for / in /etc/fstab, leaving whatever the
kernel was booted with as /, but when you run `mount' tell you what's in
fstab rather than what's really mounted?
No. Maybe you should tell us the problem.
Er, that is, `yes', mostly: the first call to mount, just after boot
time, fills in /etc/mtab if empty with a plausible entry for / derived
from /etc/fstab; but of course / is already mounted at this point so
that entry might be entirely fictional. mount then tells you what's in
/etc/mtab.
Running mount on its own should read the contents of /etc/mtab. This is
often cleared at boot time.
And filled in with whatever is mounted.
And filled in with whatever is in the / line in /etc/fstab. There's no
guarantee that your root filesystem corresponds to anything visible in
the currently-mounted /dev at all.
It is of course very hard to run forensics from here. Grub and lilo mount
the root partition, which contains /etc/fstab. They then mount what is in
there onto the system.
Nope. grub and lilo load the kernel, but do no mounting of any kind (grub
can understand some filesystem layouts, but it only uses this to locate
the kernel).
The kernel, once loaded, then mounts the root filesystem or loads code
to do it (see linux-*/init/do_mounts.c). The rules are very complex and
full of ugly special cases, but currently consist roughly of
- first, main.c runs the initcalls to handle all sorts of very-early
initialization. One class of initcalls is the `rootfs initcalls'.
The only current rootfs initcall runs
linux/init/initramfs.c:populate_rootfs(), which endeavours to unpack
a .cpio.gz'ed filesystem image onto the rootfs (the first entry in
/proc/mounts, an always-mounted ramfs which the real / is mounted on
top of). It unpacks and merges gzipped CPIO archives from the
initramfs sections in the kernel image, from the initrd region passed
from the bootloader, and from the file /initrd.image (the latter two
may also be raw filesystem images). It then makes the rootfs the /
filesystem via the in-kernel equivalent of mount --move (before then,
there *is* no root filesystem, and large parts of the VFS are
nonfunctional).
- main.c then runs /init to complete filesystem mounting. This is the
recommended way to boot; most distro kernels and all systems with /
on non-autoassembled RAID, LVM, or something more complex like
CLVM-over-NBD boot this way. It's endlessly flexible, and H. Peter
Anvin has been working for some time on moving all the rest of the
in-kernel mount rubbish into userspace so that this can become the
*only* in-kernel /-mounting code.
- If an initramfs didn't exist, the kernel runs
linux/init/do_mounts.c:prepare_namespace(), which is the old in-
kernel automatic root mounter. It and functions it calls do everything
else I describe here.
- optionally wait before continuing mounting if the rootdelay= kernel
parameter so specifies.
- run MD array auto-assembly (which is semi-deprecated these days)
- if the root= parameter specifies a name starting with `mtd=', try to
mount root on /root now (without even creating a device!)
- try to convert the name specified in root= into a dev_t. The rules
for this are a truly horrific historic mess and need have no
resemblance at all to anything in any /dev on the system: I very
much doubt you have a /dev/nfs, for instance. See
do_mounts.c:name_to_dev_t(), but bring a bucket.
- try to load an initrd from the newly-created device /dev/ram0 and
run /linuxrc if it exists. Otherwise,
- try to mount the root device hardwired into the kernel image with
the long-obsolete rootdev command. If it's major number 0, try to mount
an NFS root filesystem off the fake device /dev/root (created for the
purpose on the rootfs, which is already mounted: populate_rootfs()
above did that).
- if there's a ramdisk located on a floppy, load that.
- create the /dev/root device from the computed root filesystem
device number.
- mount it with the specified rootfstype= and rootflags= (if any),
otherwise fall back to mount autodetection.
- finally, move /root over / via mount --move and chroot to it.
What a mess. Reemember, friends don't let friends use the kernel
auto-root-mounter or old-style /linuxrc initrds :) initramfses are *so*
much neater.
Now exactly what happens if the / in /etc/fstab
differs from the root partition in grub/lilo, I am not althogether sure.
It should be clearer now. Note that nothing above even notes that fstab
exists. (Some initramfs build systems may copy /etc/fstab into the
initramfs linked into the kernel image to help in finding / more
reliably; mine does, for instance.)
--
`In the future, company names will be a 32-character hex string.'
--- Bruce Schneier on the shortage of company names
.
- References:
- mount weirdness
- From: Tony Houghton
- Re: mount weirdness
- From: Gordon Henderson
- Re: mount weirdness
- From: Unruh
- mount weirdness
- Prev by Date: Re: Printing via Gimp vs printing via Firefox
- Next by Date: Re: Converting an OOo writer file to CSV file
- Previous by thread: Re: mount weirdness
- Next by thread: Re: mount weirdness
- Index(es):
Relevant Pages
|
|
