Re: Beige PowerMac G3/266 trouble

In article <slrne4a5m9.m07.mala@xxxxxxxxxxxxxxxxxx>,
Manuel Tobias Schiller <mala@xxxxxxxxxxxxxxx> wrote:

Next time, please read the whole [initrd.txt] file. It says somewhere further

-- begin quote --
Finally, you have to boot the kernel and load initrd. Almost all Linux
boot loaders support initrd. Since the boot process is still compatible
with an older mechanism, the following boot command line parameters
have to be given:

root=/dev/ram0 init=/linuxrc rw

if not using devfs, or

root=/dev/rd/0 init=/linuxrc rw

if using devfs. (rw is only necessary if writing to the initrd file
-- end quote --

There are no such parameters in the /boot/grub/menu.lst on my Shuttle.
Do you understand the significance of the phrase "older mechanism"?

See the prepare_namespace routine
<>. Note the separate calls
to initrd_load, and further down mount_root?

initrd_load is here
<>. Yes, there is a
provision for leaving the initrd located at /dev/ram0. But this is only
if the initrd is going to be used as your real root device. Which I was
not doing, and which is not commonly done.

Well, the fact that they call the executable /linuxrc is nice to know,
but not essential.

It is the default name of the executable run by handle_initrd

It just plays the role of init, and that is what matters.

No it doesn't. It is launched by init.

The pivot_root call is used to change the root fs to some other
fs mounted under some other mount point, so someone or something obviously
needs to mount that fs (the CD, in your case), and that something is
contained on the initrd image.

According to initrd.txt, that's the job of linuxrc in the initrd image.

Well, how the executable is named is hardly the point, the point is
that this executable mounts the fs on the CD and not the kernel before
forking off init (or /linuxrc for the initrd case).

init is not forked off. It is the primordial process, with PID 1. It is
the one that does the forking off of all other processes (including
linuxrc). See <> (2.6.11 sources),
where on line 374, in the routine rest_init, a call to kernel_thread is
made passing the init routine that starts on line 625. That's where the
init process starts. That routine in turn calls prepare_namespace, which
does the stuff described above.

Maybe they do it differently in 2.6.x kernels, but for 2.4.x, my claim
is true if I can trust the initrd.txt file.

I was using a 2.6 kernel. I did try a 2.4 one at one point, with no luck.