Le 04/05/2015 16:48, Steve Litt a écrit :
> Hi all,
>
> I just documented the boot process, from Grub through init.
>
> See http://troubleshooters.com/linux/diy/howboot.htm
>
> Hope you like it.
>
> SteveT
>

     Dear Steve, I have a few comments, more or less important to 
understand how things work:

     It is pretty seldom, I think, that /bin and /sbin are symbolic 
links to /usr/bin and /usr/sbin. I have never seen it in a major distro 
up to now.

     The root= argument to kernel is usefull also when using an 
initramfs. In this case the the argument is ignored by the kernel but it 
is available to the initramfs init program. Note that custom initramfs 
may ignore it and have other ways to find the root partition.

     The initramfs init does a few things before it pivot-root and 
passes control to the ondisk init. It mounts /proc, /sys, /dev, creates 
device files, mounts the disk root partition, then mounts proc, sys and 
dev on this partition. On Debian, it mounts /run on tmpfs. When the 
ondisk init starts, there are quite a few things ready.

     Processes are created with a process-id which is incremented for 
every new process, until it reaches the maximum and restarts from the 
begining. If init has pid 1, it is because it is just the first one 
created. There is no other process started by the kernel before init. If 
the second init (after pivot-root) also has pid 1, it is because it is 
just the same process, running a different program. I'm not sure what 
happens if init crashes after other processes have been started, wether 
the kernel panics or other processes continue without init - not a very 
good situation.

     The initramfs is a live OS and you can make it a friendly debugging 
environment to help understand what is going on. As Laurent mentionned 
some time ago, it is not even necessary to pivot-root; you could keep 
/bin and /sbin  in ramfs and just mount the rest. Of course upgrading 
the files in /bin and /sbin would involve re-creating the whole initramfs.

     A ramfs or tmpfs is not exactly like the old initrd. The Linux VFS 
keeps data in buffers and filesystems periodically swap the data in 
these buffers with hardware backup stores, that is disks. A ramdisk is 
when the backup store is in some fixed location in ram. The ramfs is a 
filesystem simply *without* a backing store - very nice idea which 
emerged around 10 years ago I think, which shows that simplicity is not 
given, it is an achievement. tmpfs is like ramfs, except it can expand 
to the swapping area. I think that ramfs and tmpfs have been completely 
merged a few years ago.

     Hope this helps and there are no errors :-)

     Didier