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@xxxxxxxxx
