Allen Curtis wrote: >>>I was wondering if someone could clarify this behavior. >>> >>>Recently I created a custom kernel which calls a custom "init" >> >>script. While >> >>>debugging the "strange" behavior I discovered that Linux processed >>>/etc/fstab and mounted the root file-system specified before "init" was >>>called. This was unfortunate since I was trying to reformat the >> >>device that >> >>>was now mysteriously mounted. >> >>Well, consider that the kernel has to be able to *find* /etc/fstab >>in the first place, which means the filesystem containing /etc >>must be mounted for the kernel to fully boot. > > > Perhaps I need to be a little clearer. The boot parameters specified > root=/dev/ram0. (which is what rdev does without a recompile) As you > mentioned this indicates that the kernel knew what root was and therefore > could read /etc/fstab. The /etc/fstab specified a different device as being > root but I didn't expect it to be mounted before init was called. I wanted > to work with the device, unmounted first. Although mount reported the new > device as root I don't believe that it is the "real" root. No pivot_root or > chroot was performed. I believe that the device was unformatted at one time > and therefore must have been still using the ram disk image. So for the most > part this was an annoyance and an unexpected problem to solve. Ah. Much clearer, and I don't know why you'd see this behavior :-( I guess there's some code in the kernel that pivots the root to whatever is specified in /etc/fstab on the rdev'd root? I've just grepped the 2.4.18 tree and didn't find any likely-looking culprit, though... -- Joe -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
