On Sat, Apr 18, 2015 at 12:02:23PM -0400, Steve Litt wrote:
> On Sat, 18 Apr 2015 00:08:54 -0400
> Jude Nelson <judecn@???> wrote:
>
>
> > The init program in example/initramfs/init goes into
> > /usr/share/initramfs-tools/init, not /sbin/init :) The initramfs's
> > init script is fundamentally different from the init program
> > in /sbin. That also explains your inability to reboot.
> >
> > Basically, when the bootloader loads the initramfs, the kernel mounts
> > it as the root device and starts /sbin/init. /sbin/init, in turn,
> > runs the script at /init (which you can see from the initramfs shell
> > with "ls /"), which is copied into the initramfs image by the
> > update-initramfs and mkinitramfs tools from the
> > file /usr/share/initramfs-tools/init.
>
> Hi Jude,
>
> Your description above differs from what I thought happens at boot.
> Until reading your description, I had thought:
>

> 1) Boot loader runs kernel via the kernel device/path/name, passing it
>    the root partition device, and device/path/name locations of the
>    init program and the initramfs (if any).

This is incorrect; the bootloader loads kernel and initrd/initramfs into
memory, passing along any extra kernel options and a pointer to the
initrd/initramfs.
For initramfs, the kernel mounts a ramfs or tmpfs filesystem on /,
decompresses and extracts the initramfs onto it (which *apparently*
involves a loop so that multiple initramfs archives can be concatenated).
The initramfs archive is a cpio 'newc' archive, typically compressed with
gzip (though the kernel supports xz, bzip2, and I think a couple other
formats).

For initrd, what was loaded was a raw ext2 filesystem, set up as a
ramdrive, so the kernel need not do anything.

> 2) Using the passed info, the kernel mounts the initramfs (if any) as
>    /, and then runs the initramfs' /sbin/init. Any processes started by
>    the initramfs init program are kernel process surrounded by square
>    brackets in the ps command.

No, they are regular processes.
Kernel processes are *part* of the kernel, not userland processes that got
started at the right time.

I'm not sure exactly what the priority is, but the kernel searches
/sbin/init, /init, and /linuxrc at least.
/init is tried *before* /sbin/init, a fact which I know due to some
experiments with toybox.
I've seen a reference to a kernel option that changes the "init" on the
initramfs recently on this list; I'm not positive what it is, but it may
be rdinit.

> 3) If the initramfs init program completes, the kernel runs the init
>    program whose location was passed to it by the bootloader. However,
>    in Manjaro's initramfs init, the last line of the initramfs' init
>    program runs the on-disk init program whose location was passed to
>    the kernel by the bootloader. When the init program whose location
>    was passed to the kernel runs, it runs as PID 1, and can spawn (or
>    manage if desired) other programs.

As far as I know, if the initramfs init program completes, the kernel
panics.
It needs to mount the new / on a mountpoint (traditionally /mnt), move
/dev to /mnt/dev if using a dynamic /dev, change the root (pivot_root()
is the typical syscall, usually used via switch_root or pivot_root
commands), and exec the new init.

HTH,
Isaac Dunham