Grub Manual

[Les Mikesell]

Lamar Owen wrote:

>> Those things aren't really related to grub, which is why they aren't in
>> the grub manual.  They are related to how a running fedora system finds
>> the place from a linux perspective to make updates that grub will find
>> on the next boot.  The reasons you have to get that part right don't
>> have anything to do with grub itself, just conventions within fedora.
> 
> Is there perhaps a Fedora Wiki page on the Fedora boot process and on how to 
> fix or change things at this level? 

I've never seen it if such a thing exists.

> Something that describes the full boot up to the point of logging in would be 
> quite useful for troubleshooting why it broke.  Something that describes how 
> grub passes the boot off to the kernel,

Up to that point it is grub doing all the work - and it can boot things 
other than linux.

 > how (and why) the kernel starts nash,
> what nash does, how nash does what it does, and how init gets control and 
> starts running rc.sysinit, what that does, and how the various /etc/init.d 
> scripts get called (Ubuntu does it differently; a Fedora-specific doc is 
> needed). 

Traditionally, unix like systems always have the kernel start init as 
the only special case (which  is why it gets proccess id 1).  All other 
processes are created by fork() from an existing parent, and in 
sysV-like systems the initial set are from directions in /etc/inittab 
where you find the default run level, the scripts to get to each, and 
some things that automatically restart that may be tied to specific devices.

 > Something that describes the contents of initrd, how to change those
> contents (like you need to do when you need to change the driver for the root 
> filesystem's controller, if the controller's driver is modular).  
> A 'Fedora-Boot-HOWTO' if you will.

There's a script to build a new initrd called mkinitrd and a man page 
for it.

> The man pages for each piece are pretty good, if incomplete, but I've not 
> found (doesn't mean that it doesn't exist, it just means I haven't found it) 
> a complete system overview that shows where each piece fits and how it does 
> its individual job in the context of the complete system.

One piece I'd like to know is what has to happen in udev based systems 
during a rescue-mode boot to make the devices appear on the 
freshly-mounted hard disk's version of /dev.  If your /etc/fstab matches 
  your partitions exactly, the scripted startup will mount the 
partitions under /etc/sysimage, magically make the devices show up, and 
suggest a chroot command to use to repair things.  However, if the thing 
you need to fix is /etc/fstab, this doesn't happen.  On pre-udev 
versions you could manually mount the partitions and the device files 
would already be there.  With current versions, if you mount the 
partitions manually and try the chroot, nothing else will work because 
you have no devices.  What's the missing step?

-- 
   Les Mikesell
    lesmikesell at gmail.com