On Sat, 8 Sep 2007, Andy Green wrote:
> Somebody in the thread at some point said:
>
> > i've asked about this on the kernel newbies list, but i want to
> > ask it here in a slightly different, fedora-centric way.
> >
> > the short form: what is the precise sequence of kernel boot
> > regarding the initramfs (both the internal and external
> > possibilities)?
> >
> > the long form: i'm reading the docs and trying to understand
> > the intricacies of the boot sequence regarding how the kernel
> > deals with the initramfs. first, AIUI, every built kernel has an
> > *internal* compressed cpio initramfs image although, by default,
> > it's "empty."
> >
> > now, i opened up one of the internal cpio initramfs images that's
> > generated when i do my own kernel build, and it contained;
> >
> > drwxr-xr-x 2 root root 0 Sep 7 16:14 /dev
> > crw------- 1 root root 5, 1 Sep 7 16:14 /dev/console
> > drwx------ 2 root root 0 Sep 7 16:14 /root
> >
> > so it's not truly "empty" but it's pretty close. anyway, onward.
>
> New to me... but I do know that having an (external) initrd at all
> is completely optional.
absolutely. there's nothing that says you *need* any kind of initrd
or initramfs if the boot loader and the kernel can handle everything
themselves.
(as an aside, some of the docs i'm reading are:
http://www.timesys.com/timesource/march_06.htm
http://www.timesys.com/timesource/initramfs.htm
if you wanted a decent intro.)
> You can (and I think Debian does it this way; I certainly do it that
> way on embedded devices) get the kernel to mount the filesystem on
> the /root= partition directly and jump straight into the init
> program found on there. Maybe that is in fact done via this
> mysterious internal cyst of an initrd, I don't know.
i'm fairly sure that's not happening here since that default internal
initramfs just doesn't contain enough content to represent a jumping
off point for further booting -- it doesn't contain the essential
"init" program that the kernel is looking for. (and, as another
aside, does anyone what that internal initramfs contains as shipped in
kernels for fedora? is there a way to extract that from a compressed
kernel image?)
> > based on my reading, it appears that, when the (2.6) kernel
> > starts to run, it allocates a tmpfs-based "rootfs" (always,
> > without exception) and copies into it the contents of the internal
> > initramfs image (again, without excepton). is this correct so
> > far?
> New to me, I only ever used an external initrd. Sounds like it
> could be pretty cool in a pinch though.
it's just a quick way of supplying an initramfs even if the boot
loader can't deal with that, the way GRUB can. also, as i read it,
if you supply an internal initramfs, that will get loaded into that
initial rootfs but, if there's still no "init", the kernel will then
move on to look for an *externally-supplied* initramfs and will *add*
that to the current contents of the mounted rootfs. and if there's
*still* no "init" program to run in the mounted rootfs, the kernel
will finally give up and go back to the defaults or to the
command-line parms. but it's the exact logic there that i'm still
trying to follow.
> > once that's done, what happens if there's an executable "init"
> > file in the rootfs? does the kernel simply pass control to that
> > executable? if that's true, that means that there would be no way
> > to process regular kernel command-line parameters so, despite what
> > the documentation seems to suggest, i can't believe that's what's
> > happening.
>
> Not sure what you mean about "no way to process regular kernel
> command-line parameters", you can always cat /proc/cmdline from
> userspace.
what i meant was, if one of the two initramfs cpio images supplies an
executable "init" program, the docs i've read seem to suggest that, at
that point, the kernel will simply hand control over to that "init"
program and kick back.
but if that's true, who *exactly* will still be responsible for
processing kernel boot-time params such as "boot=". yes, you can see
those via /proc/cmdline from userspace, but what i'm asking what part
of the boot sequence above *processes* that parameter?
> > on the other hand, let's say there's no "init" in that internal
> > initramfs. then, AIUI, the kernel will check whether it's been
> > passed a second initramfs image (that would be the one identified
> > in /etc/grub.conf via the "initrd" directive). and in the case of
> > fedora, that's the one created by running "mkinitrd" during the
> > kernel installation process, which *does* have an "init" script
> > which fires up "nash" and takes over, etc, etc.
> >
> > but, once again, even if that happens, at what point in all of
> > that would a kernel boot-time parameter of, say, "root=" be
> > processed? surely *something* has to deal with that but in all of
> > the above, where is that being done? and do i have the order even
> > remotely correct?
>
> The "init" nash script in the fedora external initrd gets nash to
> sort out the real root device and to pivot_root into it, near the
> end of the init script.
there is no "pivot_root" in the fedora-supplied nash script but, near
the end, there are "setuproot" and "switchroot" commands. are you
suggesting that one of these is responsible for processing the "root="
option. after all, *someone* has to process it, i'm just trying to
figure out who.
rday
p.s. just for giggles, i've attached the "init" nash script that's
bundled into the external initramfs image that's created when a fedora
kernel is installed. note that that script contains numerous "echo"
commands. where is that echo output going so i can see it?
or does the boot-time parm "quiet" toss all that output?
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
#!/bin/nash
mount -t proc /proc /proc
setquiet
echo Mounting proc filesystem
echo Mounting sysfs filesystem
mount -t sysfs /sys /sys
echo Creating /dev
mount -o mode=0755 -t tmpfs /dev /dev
mkdir /dev/pts
mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts
mkdir /dev/shm
mkdir /dev/mapper
echo Creating initial device nodes
mknod /dev/null c 1 3
mknod /dev/zero c 1 5
mknod /dev/systty c 4 0
mknod /dev/tty c 5 0
mknod /dev/console c 5 1
mknod /dev/ptmx c 5 2
mknod /dev/rtc c 10 135
mknod /dev/tty0 c 4 0
mknod /dev/tty1 c 4 1
mknod /dev/tty2 c 4 2
mknod /dev/tty3 c 4 3
mknod /dev/tty4 c 4 4
mknod /dev/tty5 c 4 5
mknod /dev/tty6 c 4 6
mknod /dev/tty7 c 4 7
mknod /dev/tty8 c 4 8
mknod /dev/tty9 c 4 9
mknod /dev/tty10 c 4 10
mknod /dev/tty11 c 4 11
mknod /dev/tty12 c 4 12
mknod /dev/ttyS0 c 4 64
mknod /dev/ttyS1 c 4 65
mknod /dev/ttyS2 c 4 66
mknod /dev/ttyS3 c 4 67
echo Setting up hotplug.
hotplug
echo Creating block device nodes.
mkblkdevs
echo "Loading ehci-hcd.ko module"
insmod /lib/ehci-hcd.ko
echo "Loading ohci-hcd.ko module"
insmod /lib/ohci-hcd.ko
echo "Loading uhci-hcd.ko module"
insmod /lib/uhci-hcd.ko
mount -t usbfs /proc/bus/usb /proc/bus/usb
echo "Loading mbcache.ko module"
insmod /lib/mbcache.ko
echo "Loading jbd.ko module"
insmod /lib/jbd.ko
echo "Loading ext3.ko module"
insmod /lib/ext3.ko
echo "Loading scsi_mod.ko module"
insmod /lib/scsi_mod.ko
echo "Loading sd_mod.ko module"
insmod /lib/sd_mod.ko
echo "Loading libata.ko module"
insmod /lib/libata.ko
echo "Loading ahci.ko module"
insmod /lib/ahci.ko
echo Waiting for driver initialization.
stabilized --hash --interval 250 /proc/scsi/scsi
echo "Loading ata_piix.ko module"
insmod /lib/ata_piix.ko
echo Waiting for driver initialization.
stabilized --hash --interval 250 /proc/scsi/scsi
echo "Loading dm-mod.ko module"
insmod /lib/dm-mod.ko
echo "Loading dm-mirror.ko module"
insmod /lib/dm-mirror.ko
echo "Loading dm-zero.ko module"
insmod /lib/dm-zero.ko
echo "Loading dm-snapshot.ko module"
insmod /lib/dm-snapshot.ko
echo Making device-mapper control node
mkdmnod
insmod /lib/scsi_wait_scan.ko
rmmod scsi_wait_scan
mkblkdevs
echo Scanning logical volumes
lvm vgscan --ignorelockingfailure
echo Activating logical volumes
lvm vgchange -ay --ignorelockingfailure f8
resume /dev/f8/swap
echo Creating root device.
mkrootdev -t ext3 -o defaults,ro /dev/f8/root
echo Mounting root filesystem.
mount /sysroot
echo Setting up other filesystems.
setuproot
echo Switching to new root and running init.
switchroot
echo Booting has failed.
sleep -1
