Discussion:
Beige PowerMac G3/266 trouble
(too old to reply)
Lawrence D'Oliveiro
2006-04-16 11:09:16 UTC
Permalink
I'm trying to figure out how to do a Debian install onto a beige (Old World)
PowerMac G3/266. I downloaded the minimal "netinst" install CD image from
<http://cdimage.debian.org/debian-cd/3.1_r1/powerpc/iso-cd/debian-31r1a-powerpc-netinst.iso>,
and burnt that onto a disc that I can read OK from the Mac. After looking
at the notes on <http://www.netbsd.org/Ports/macppc/models.html>, I
discovered that this model doesn't support Open Firmware booting from
either floppy or CD-ROM.

So then I found out about BootX <http://penguinppc.org/bootloaders/bootx/>.
I was able to get that to run OK. I copied the "vmlinux" and "initrd.gz"
files off the "install/powerpc" directory in the install CD into a "Linux
Kernels" folder in my System Folder, where BootX allowed me to select them.
The kernel initially seemed to load OK, and told me that it had found the
CD-ROM drive at hdc and the Zip drive (which doesn't work any more) at hdd.
At this point it threw up an error saying it couldn't open the root device
(which I hadn't specified properly as yet).

I was able to figure out which partition number on hdc to use for the root
filesystem by examining the CD on my Shuttle box (running OpenSuSE 10.0)
with parted. This listed two partitions, respectively
"type=Apple_partition_map" and "type=Apple_HFS". So I figured I had to tell
the kernel to use /dev/hdc2 as its root, which I duly entered into BootX.

However, it still doesn't get very far, though I no longer get the message
about not being able to open the boot device. The last few kernel messages
I can still see on the Mac screen are (copied by hand, E&OE :)):

Probing IDE interface ide1...
hdc: MATSHITA CR-587, ATAPI CD/DVD-ROM drive
hdd: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive
hdc: MDMA, cycleTime: 120, accessTime: 75, recTime: 45
hdc: Set MDMA timing for mode 2, reg: 0x00211526
hdc: Enabling MultiWord DMA 2
ide1 at 0xcb867000-0xcb867007,0xcb867160 on irq 14
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
RAMDISK: Compressed image found at block 0
crc error
VFS: Mounted root (cramfs filesystem) readonly.
Freeing unused kernel memory: 164k init 4k chrp 32k prep
Error -3 while decompressing!
c0558d50(-2665075)->c9c01000(4096)
Error -3 while decompressing!
c05599f8(-2668297)->c9c0c000(4096)
request_module: runaway loop modprobe binfmt-0000
request_module: runaway loop modprobe binfmt-0000
request_module: runaway loop modprobe binfmt-0000
request_module: runaway loop modprobe binfmt-0000
request_module: runaway loop modprobe binfmt-0000
equest_module: runaway loop modprobe binfmt-0000

Note the missing "r" on the last line--it appears that's been overwritten by
the cursor, which is sitting blinking at that position. And this is where
it freezes.

I also tried downloading vmlinux and initrd.gz from
<http://ftp.debian.org/dists/sarge/main/installer-powerpc/current/images/powerpc/cdrom/>,
with similar results.

Does it look like it's having problems with the initrd file? Is there
something I'm missing?

Thanks for any advice.
Manuel Tobias Schiller
2006-04-16 14:17:31 UTC
Permalink
Post by Lawrence D'Oliveiro
I'm trying to figure out how to do a Debian install onto a beige (Old World)
PowerMac G3/266. I downloaded the minimal "netinst" install CD image from
<http://cdimage.debian.org/debian-cd/3.1_r1/powerpc/iso-cd/debian-31r1a-powerpc-netinst.iso>,
and burnt that onto a disc that I can read OK from the Mac. After looking
at the notes on <http://www.netbsd.org/Ports/macppc/models.html>, I
discovered that this model doesn't support Open Firmware booting from
either floppy or CD-ROM.
So then I found out about BootX <http://penguinppc.org/bootloaders/bootx/>.
I was able to get that to run OK. I copied the "vmlinux" and "initrd.gz"
files off the "install/powerpc" directory in the install CD into a "Linux
Kernels" folder in my System Folder, where BootX allowed me to select them.
The kernel initially seemed to load OK, and told me that it had found the
CD-ROM drive at hdc and the Zip drive (which doesn't work any more) at hdd.
At this point it threw up an error saying it couldn't open the root device
(which I hadn't specified properly as yet).
I was able to figure out which partition number on hdc to use for the root
filesystem by examining the CD on my Shuttle box (running OpenSuSE 10.0)
with parted. This listed two partitions, respectively
"type=Apple_partition_map" and "type=Apple_HFS". So I figured I had to tell
the kernel to use /dev/hdc2 as its root, which I duly entered into BootX.
/dev/hdc2 is the HFS partition on the CD, which is used to hold some
data and the kernel image in a format that the Mac's firmware can
understand; the partition used as root during installation is located on
the ram disk, so entering /dev/ram is probably better. Remember to
change that root device setting once your system should boot from the
installed linux on your hard disk for the first time.
Post by Lawrence D'Oliveiro
However, it still doesn't get very far, though I no longer get the message
about not being able to open the boot device. The last few kernel messages
Probing IDE interface ide1...
hdc: MATSHITA CR-587, ATAPI CD/DVD-ROM drive
hdd: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive
hdc: MDMA, cycleTime: 120, accessTime: 75, recTime: 45
hdc: Set MDMA timing for mode 2, reg: 0x00211526
hdc: Enabling MultiWord DMA 2
ide1 at 0xcb867000-0xcb867007,0xcb867160 on irq 14
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
RAMDISK: Compressed image found at block 0
crc error
I haven't used BootX in a while (I have a beige G3, too, and I'm using
quik to boot my installed system and don't see anything of MacOS any
longer), but I believe you can specify the initrd file; the crc error
seems to point to something going wrong there. But I'd try first if you
really need to specify anything at all, just leave the initrd setting
blank and see if it works (with /dev/ram or something similar as root
device).
Post by Lawrence D'Oliveiro
VFS: Mounted root (cramfs filesystem) readonly.
Freeing unused kernel memory: 164k init 4k chrp 32k prep
Error -3 while decompressing!
c0558d50(-2665075)->c9c01000(4096)
Error -3 while decompressing!
c05599f8(-2668297)->c9c0c000(4096)
request_module: runaway loop modprobe binfmt-0000
request_module: runaway loop modprobe binfmt-0000
request_module: runaway loop modprobe binfmt-0000
request_module: runaway loop modprobe binfmt-0000
request_module: runaway loop modprobe binfmt-0000
equest_module: runaway loop modprobe binfmt-0000
Note the missing "r" on the last line--it appears that's been overwritten by
the cursor, which is sitting blinking at that position. And this is where
it freezes.
Well, if mounting the root device fails, my kernel usually just panics,
so there's not much I'd worry about as long as I'm not sure that the
initrd image was correctly mounted as root partition.
Post by Lawrence D'Oliveiro
I also tried downloading vmlinux and initrd.gz from
<http://ftp.debian.org/dists/sarge/main/installer-powerpc/current/images/powerpc/cdrom/>,
with similar results.
Does it look like it's having problems with the initrd file? Is there
something I'm missing?
Thanks for any advice.
If you think I can help, you can just e-mail me, because at the moment,
I don't think I'll have the time to follow the newsgroup regularly because
I have to learn for exams at university, so answers might take their time,
but I'll try to help. However, I can't test things out myself, because one
should never touch a running system, and I need this one running...

Regards,

Manuel
--
Homepage: http://www.hinterbergen.de/mala
e-mail: mala -at- hinterbergen -dot- de
OpenPGP: 0xA330353E (DSA) or 0xD87D188C (RSA)
Lawrence D'Oliveiro
2006-04-16 22:48:40 UTC
Permalink
Post by Manuel Tobias Schiller
/dev/hdc2 is the HFS partition on the CD, which is used to hold some
data and the kernel image in a format that the Mac's firmware can
understand...
It holds rather more than that. It also holds the installer and a
minimal set of kernels and packages. The "pool" directory alone is over
100MB, and the "install" directory is over 70MB.
Post by Manuel Tobias Schiller
... the partition used as root during installation is located on
the ram disk, so entering /dev/ram is probably better.
Do you understand the difference between the "initrd" and "root" kernel
parameters?
Post by Manuel Tobias Schiller
But I'd try first if you
really need to specify anything at all, just leave the initrd setting
blank and see if it works...
Already tried that. It hangs even earlier in the boot process.
Post by Manuel Tobias Schiller
Well, if mounting the root device fails, my kernel usually just panics...
I get that if I specify an invalid root device (like "/dev/hdc" instead
of "/dev/hdc2").
Manuel Tobias Schiller
2006-04-16 23:27:36 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
/dev/hdc2 is the HFS partition on the CD, which is used to hold some
data and the kernel image in a format that the Mac's firmware can
understand...
It holds rather more than that. It also holds the installer and a
minimal set of kernels and packages. The "pool" directory alone is over
100MB, and the "install" directory is over 70MB.
Exactly. I just wanted to say that this fs is not needed to boot up the
installation system, it will later be mounted by the installer when the
data is needed.
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
... the partition used as root during installation is located on
the ram disk, so entering /dev/ram is probably better.
Do you understand the difference between the "initrd" and "root" kernel
parameters?
I think so. I'll tell you what I believe to remember about it and you
correct me if I'm wrong. I'm always happy to learn... ;)

Basically, the initrd parameter gives the kernel an image with which it
can fill a ram disk. I believte that initrd is in fact a boot loader
parameter, because the kernel does not know yet how to reach the image one
specifies; the boot loader (BootX) in your case will load that image into
RAM and tell the kernel where to find it. If you want the ram disk that
is constructed from the initrd image (which is usually compressed and
needs to be decompressed before usage if I remember correctly) to become
the root fs so you can boot from it, you need to specify /dev/ram or
something similar to get that ram disk as root device.
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
But I'd try first if you
really need to specify anything at all, just leave the initrd setting
blank and see if it works...
Already tried that. It hangs even earlier in the boot process.
Sorry, I believed I remebered some kernels which had an initrd appended
just after the kernel image in the same file - might have been on a
different system, or I may be wrong there which is quite easily
possible. I've done too many tricky installations on too many trick
machines to remember a single one exactly.
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
Well, if mounting the root device fails, my kernel usually just panics...
I get that if I specify an invalid root device (like "/dev/hdc" instead
of "/dev/hdc2").
All the better. That's what I would expect. Still, booting directly off
the CD fs and not from the initrd image seems to be a bad idea to me
because the loader on the CD which would boot the installer if the open
firmware implementation on your beige G3 supported it would also load
that initrd image first and use the resulting ram disk as root device;
I'm pretty sure about that.

Kind regards,

Manuel
--
Homepage: http://www.hinterbergen.de/mala
OpenPGP: 0xA330353E (DSA) or 0xD87D188C (RSA)
Lawrence D'Oliveiro
2006-04-17 11:46:49 UTC
Permalink
Post by Manuel Tobias Schiller
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
/dev/hdc2 is the HFS partition on the CD, which is used to hold some
data and the kernel image in a format that the Mac's firmware can
understand...
It holds rather more than that. It also holds the installer and a
minimal set of kernels and packages. The "pool" directory alone is over
100MB, and the "install" directory is over 70MB.
Exactly. I just wanted to say that this fs is not needed to boot up the
installation system, it will later be mounted by the installer when the
data is needed.
And where exactly would you find the installer, if not on the
installation system?
Post by Manuel Tobias Schiller
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
... the partition used as root during installation is located on
the ram disk, so entering /dev/ram is probably better.
Do you understand the difference between the "initrd" and "root" kernel
parameters?
Basically, the initrd parameter gives the kernel an image with which it
can fill a ram disk. I believte that initrd is in fact a boot loader
parameter, because the kernel does not know yet how to reach the image one
specifies; the boot loader (BootX) in your case will load that image into
RAM and tell the kernel where to find it.
So far, correct.
Post by Manuel Tobias Schiller
If you want the ram disk that
is constructed from the initrd image (which is usually compressed and
needs to be decompressed before usage if I remember correctly) to become
the root fs so you can boot from it, you need to specify /dev/ram or
something similar to get that ram disk as root device.
initrd, if present, _is_ initially mounted as / (root), and the
filesystem spedified as "root" is mounted in a directory off it. Then
later, after the initrd has served its purpose, a pivot_root call is
done to move the proper root to /, after which the initrd filesystem can
be deleted.
Post by Manuel Tobias Schiller
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
But I'd try first if you
really need to specify anything at all, just leave the initrd setting
blank and see if it works...
Already tried that. It hangs even earlier in the boot process.
Sorry, I believed I remebered some kernels which had an initrd appended
just after the kernel image in the same file - might have been on a
different system, or I may be wrong there which is quite easily
possible.
You're thinking about initramfs. That's another mechanism present in
newer kernels, as an alternative to initrd (which is still supported).
Post by Manuel Tobias Schiller
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
Well, if mounting the root device fails, my kernel usually just panics...
I get that if I specify an invalid root device (like "/dev/hdc" instead
of "/dev/hdc2").
All the better. That's what I would expect. Still, booting directly off
the CD fs and not from the initrd image seems to be a bad idea to me...
Which is not what I'm doing. I've copied the kernel (and initrd) to the
hard drive, which is where BootX is finding them.
Manuel Tobias Schiller
2006-04-17 13:09:33 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
/dev/hdc2 is the HFS partition on the CD, which is used to hold some
data and the kernel image in a format that the Mac's firmware can
understand...
It holds rather more than that. It also holds the installer and a
minimal set of kernels and packages. The "pool" directory alone is over
100MB, and the "install" directory is over 70MB.
Exactly. I just wanted to say that this fs is not needed to boot up the
installation system, it will later be mounted by the installer when the
data is needed.
And where exactly would you find the installer, if not on the
installation system?
You'll find a kind of first stage of the installation system on the initrd
ram disk. It's responsible to load all kernel modules needed for the
hardware in the system, finding the correct installation medium (a CD or
a DVD in most cases) and a few other things. So, the system starts in fact
from the ram disk, and some "application" (from the kernel's point of view)
will then change the root device and run a few other "applications" on the
new root fs. The fact that a user of the installation program does not
notice that bit of magic does not mean that everything comes off the CD.
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
Post by Manuel Tobias Schiller
... the partition used as root during installation is located on
the ram disk, so entering /dev/ram is probably better.
Do you understand the difference between the "initrd" and "root" kernel
parameters?
Basically, the initrd parameter gives the kernel an image with which it
can fill a ram disk. I believte that initrd is in fact a boot loader
parameter, because the kernel does not know yet how to reach the image one
specifies; the boot loader (BootX) in your case will load that image into
RAM and tell the kernel where to find it.
So far, correct.
Fine - mutual understanding achieved; as you might have noticed, I'm
sometimes slow on the uptake or not quite exact in the terms I use.
Sorry for the inconvenience. Mea culpa ;)
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
If you want the ram disk that
is constructed from the initrd image (which is usually compressed and
needs to be decompressed before usage if I remember correctly) to become
the root fs so you can boot from it, you need to specify /dev/ram or
something similar to get that ram disk as root device.
initrd, if present, _is_ initially mounted as / (root), and the
filesystem spedified as "root" is mounted in a directory off it. Then
later, after the initrd has served its purpose, a pivot_root call is
done to move the proper root to /, after which the initrd filesystem can
be deleted.
Reading /usr/src/linux/Documentation/initrd.txt (kernel 2.4.32), I gather
that you still have to mount /dev/ram as root fs to make use of the
initrd. 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. (When in doubt, have a look at the
pivot_root man pages in section 8 and 2, and also at initrd.txt).
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
But I'd try first if you
really need to specify anything at all, just leave the initrd setting
blank and see if it works...
Already tried that. It hangs even earlier in the boot process.
Sorry, I believed I remebered some kernels which had an initrd appended
just after the kernel image in the same file - might have been on a
different system, or I may be wrong there which is quite easily
possible.
You're thinking about initramfs. That's another mechanism present in
newer kernels, as an alternative to initrd (which is still supported).
You may be right there, as I said, I'm not sure about this bit.
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
Well, if mounting the root device fails, my kernel usually just panics...
I get that if I specify an invalid root device (like "/dev/hdc" instead
of "/dev/hdc2").
All the better. That's what I would expect. Still, booting directly off
the CD fs and not from the initrd image seems to be a bad idea to me...
Which is not what I'm doing. I've copied the kernel (and initrd) to the
hard drive, which is where BootX is finding them.
Fine, that's how things work. Still, if you specify the CD as root
device, init is searched on the cd, which is not what it was made for,
because some program on the initrd is supposed to gain control first.
That's why you get these strage messages.

Manuel
--
Homepage: http://www.hinterbergen.de/mala
OpenPGP: 0xA330353E (DSA) or 0xD87D188C (RSA)
Lawrence D'Oliveiro
2006-04-18 00:27:22 UTC
Permalink
Post by Manuel Tobias Schiller
You'll find a kind of first stage of the installation system on the initrd
ram disk.
Which is the part that's not loading properly for me.
Post by Manuel Tobias Schiller
Reading /usr/src/linux/Documentation/initrd.txt (kernel 2.4.32), I gather
that you still have to mount /dev/ram as root fs to make use of the
initrd.
Quote from initrd.txt:

3) initrd is mounted read-write as root
4) /linuxrc is executed ...
5) linuxrc mounts the "real" root file system
6) linuxrc places the root file system at the root directory using the
pivot_root system call

Note that the /linuxrc executable is found in the initrd. That path only
works if the initrd is mounted as /. Which it is in step 3.
Post by Manuel Tobias Schiller
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.
Post by Manuel Tobias Schiller
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
Well, if mounting the root device fails, my kernel usually just panics...
I get that if I specify an invalid root device (like "/dev/hdc" instead
of "/dev/hdc2").
All the better. That's what I would expect. Still, booting directly off
the CD fs and not from the initrd image seems to be a bad idea to me...
Which is not what I'm doing. I've copied the kernel (and initrd) to the
hard drive, which is where BootX is finding them.
Fine, that's how things work. Still, if you specify the CD as root
device, init is searched on the cd, which is not what it was made for...
No, initrd and the root device are quite separate, as all the above
should have made clear by now.
Manuel Tobias Schiller
2006-04-18 16:41:45 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
You'll find a kind of first stage of the installation system on the initrd
ram disk.
Which is the part that's not loading properly for me.
Post by Manuel Tobias Schiller
Reading /usr/src/linux/Documentation/initrd.txt (kernel 2.4.32), I gather
that you still have to mount /dev/ram as root fs to make use of the
initrd.
3) initrd is mounted read-write as root
4) /linuxrc is executed ...
5) linuxrc mounts the "real" root file system
6) linuxrc places the root file system at the root directory using the
pivot_root system call
Note that the /linuxrc executable is found in the initrd. That path only
works if the initrd is mounted as /. Which it is in step 3.
Next time, please read the whole file. It says somewhere further down:

-- 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
system.)
-- end quote --

Well, the fact that they call the executable /linuxrc is nice to know,
but not essential. It just plays the role of init, and that is what
matters.
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
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). The kernel itself
will mount the initrd image as root fs, and that's what needs to be
specified on the kernel command line.
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
Well, if mounting the root device fails, my kernel usually just panics...
I get that if I specify an invalid root device (like "/dev/hdc" instead
of "/dev/hdc2").
All the better. That's what I would expect. Still, booting directly off
the CD fs and not from the initrd image seems to be a bad idea to me...
Which is not what I'm doing. I've copied the kernel (and initrd) to the
hard drive, which is where BootX is finding them.
Fine, that's how things work. Still, if you specify the CD as root
device, init is searched on the cd, which is not what it was made for...
No, initrd and the root device are quite separate, as all the above
should have made clear by now.
This is wrong - the initrd is the root device for some time - see 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.

Manuel
--
Homepage: http://www.hinterbergen.de/mala
OpenPGP: 0xA330353E (DSA) or 0xD87D188C (RSA)
Lawrence D'Oliveiro
2006-04-19 01:28:32 UTC
Permalink
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
^^^^^^^^^^^^^^^
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
system.)
-- 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
<http://lxr.linux.no/source/init/do_mounts.c>. Note the separate calls
to initrd_load, and further down mount_root?

initrd_load is here
<http://lxr.linux.no/source/init/do_mounts_initrd.c>. 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
<http://lxr.linux.no/source/init/do_mounts_initrd.c>.
It just plays the role of init, and that is what matters.
No it doesn't. It is launched by init.
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
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 <http://lxr.linux.no/source/init/main.c> (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.
Manuel Tobias Schiller
2006-04-19 11:50:53 UTC
Permalink
Post by Lawrence D'Oliveiro
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
^^^^^^^^^^^^^^^
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
system.)
-- 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"?
Old is not bad in itself when it works. ;)
Post by Lawrence D'Oliveiro
See the prepare_namespace routine
<http://lxr.linux.no/source/init/do_mounts.c>. Note the separate calls
to initrd_load, and further down mount_root?
initrd_load is here
<http://lxr.linux.no/source/init/do_mounts_initrd.c>. 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, I might have been wrong there. Sorry if my tone grew a bit harsh.
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
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
<http://lxr.linux.no/source/init/do_mounts_initrd.c>.
It just plays the role of init, and that is what matters.
No it doesn't. It is launched by init.
Well, it's launched somewhere in the init subdirectory of the kernel
sources, you're right about that. Still, the init process whose
executable is /sbin/init has got nothing to do with it, and that is what
I meant. By the way, on my debian sarge installation DVD, they do
nevertheless use the following kernel parameters for yaboot, so I'd give
them a try, especially the "init=/linuxrc" bit, I assume they know what
they're doing... ;)

image=/install/powerpc/vmlinux
label=install-powerpc
alias=install
initrd=/install/powerpc/initrd.gz
append="devfs=mount,dall init=/linuxrc --"
initrd-size=10240
read-only

(taken from /mnt.dvd/install/yaboot.conf; the mount point for the dvd
will probably be different on your system...)
Post by Lawrence D'Oliveiro
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 <http://lxr.linux.no/source/init/main.c> (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.
In init.c it says:

static void rest_init(void)
{
kernel_thread(init, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNAL);
unlock_kernel();
current->need_resched = 1;
cpu_idle();
}

So I think it's fair to say that init is "forked" off in the kernel,
even if they do not use the fork system call. The kernel spawns a new
thread which will eventually run /sbin/init (or something else if the
init kernel parameter is given or initrd is used) and the initial thread
will proceed to the idle loop in good *nix tradition. At least, it looks
like that to me. ;)
Post by Lawrence D'Oliveiro
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.
Sorry to hear that, I still hope you get it up and running, no matter
what the kernel version is...

Manuel
--
Homepage: http://www.hinterbergen.de/mala
OpenPGP: 0xA330353E (DSA) or 0xD87D188C (RSA)
Lawrence D'Oliveiro
2006-04-19 23:01:09 UTC
Permalink
Post by Manuel Tobias Schiller
Post by Lawrence D'Oliveiro
Post by Manuel Tobias Schiller
Post by Manuel Tobias Schiller
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
<http://lxr.linux.no/source/init/do_mounts_initrd.c>.
Post by Manuel Tobias Schiller
It just plays the role of init, and that is what matters.
No it doesn't. It is launched by init.
Well, it's launched somewhere in the init subdirectory of the kernel
sources, you're right about that. Still, the init process whose
executable is /sbin/init has got nothing to do with it, and that is what
I meant.
That is in fact the same process. The kernel init thread looks for an
"init" executable (under various names) and execs that (see bottom of
<http://lxr.linux.no/source/init/main.c>). Thus, what starts out as a
kernel-only process turns into a full regular userspace process.
Post by Manuel Tobias Schiller
By the way, on my debian sarge installation DVD, they do
nevertheless use the following kernel parameters for yaboot, so I'd give
them a try, especially the "init=/linuxrc" bit, I assume they know what
they're doing... ;)
image=/install/powerpc/vmlinux
label=install-powerpc
alias=install
initrd=/install/powerpc/initrd.gz
append="devfs=mount,dall init=/linuxrc --"
initrd-size=10240
read-only
(taken from /mnt.dvd/install/yaboot.conf; the mount point for the dvd
will probably be different on your system...)
Yes, I did see those settings. I tried copying the "append" settings
into the kernel command line, and also giving BootX the RAM disk size as
per the "initrd-size" setting, but that didn't make any difference that
I could see. (Remember I can't use yaboot itself, as that's
New-World-only.)

I'm beginning to suspect a problem with BootX not loading things
properly into RAM.

Have you tried miboot? I copied the miboot image onto a floppy, and it
did boot my Mac, but I wasn't sure how to configure it or anything. Time
to study more source, I guess...
Post by Manuel Tobias Schiller
static void rest_init(void)
{
kernel_thread(init, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNAL);
unlock_kernel();
current->need_resched = 1;
cpu_idle();
}
So I think it's fair to say that init is "forked" off in the kernel,
even if they do not use the fork system call. The kernel spawns a new
thread which will eventually run /sbin/init (or something else if the
init kernel parameter is given or initrd is used) and the initial thread
will proceed to the idle loop in good *nix tradition. At least, it looks
like that to me. ;)
Certainly that's true. But the thread of control doing the forking of
the init thread becomes the per-CPU "idle" thread for the first or only
CPU (see the sched_init routine in
<http://lxr.linux.no/source/kernel/sched.c>, which ends by calling
init_idle on current). These idle threads are special: they have no PIDs
and are not visible to other processes, do not appear in ps listings (or
in /proc), etc.
Manuel Tobias Schiller
2006-04-20 20:42:37 UTC
Permalink
Post by Lawrence D'Oliveiro
Yes, I did see those settings. I tried copying the "append" settings
into the kernel command line, and also giving BootX the RAM disk size as
per the "initrd-size" setting, but that didn't make any difference that
I could see. (Remember I can't use yaboot itself, as that's
New-World-only.)
Hmm, I can't seem to remember how I did that when I first installed the
box two years ago. In some book I read they made the remark that setting
up *nix systems was some kind of black art and that it is said that the
sysadmins sometimes even have to speak a few magic words to get it up
and running - I remember that it was an old book (late 70s or early
80s), but they seem to have a point ;)
Post by Lawrence D'Oliveiro
I'm beginning to suspect a problem with BootX not loading things
properly into RAM.
I remember that I used to fiddle with initrd images as well (on an older
machine with only 32 MB of RAM, initrd was a no-go thing). I believe I
copied the stuff to a 100 MB zip disk (external SCSI model) and used
that as root. Installation might have required some shell intervention
(setting up swap space by hand early in the process), but it worked.
Might have been on a different distro, though. Anyway, if you've got the
hardware, that's usually a quick thing you can try - but don't forget to
modify the fstab if there's one on the initrd image or it'll call you
ugly things... ;)

BootX is usually pretty good at booting the machine in my experience,
but it might get confused by some MacOS extension (I seem to recall
having read something, but I'm not sure), so maybe you could try again
with extensions disabled.
Post by Lawrence D'Oliveiro
Have you tried miboot? I copied the miboot image onto a floppy, and it
did boot my Mac, but I wasn't sure how to configure it or anything. Time
to study more source, I guess...
I tried miboot once, but it was on a different system (a NuBUS-based
machine with a 601 processor, I forgot the model), and miboot was way to
new for it, so I had to stick with the Apple MkLinux booter on that
machine. Compared to BootX, the MkLinux booter is really ugly; it might
be worth a try though, even if they need a strange header in front of
the kernel image; and initrd has to become a real fs on a real device,
if I remember correctly... Requires quite a bit of tweaking to make
things work. By the way, the MkLinux booter does also boot more modern
kernels which are not mach-based as the first ones for NuBus machines
were, just in case you read any old docs on the net which say
differently.

I've got another idea: strictly speaking, I didn't install debian sarge
back then, I installed woody and upgraded to sarge only later. So you
might try to install the woody base system only and upgrade that to sarge
(which would have been amazingly painless on my system if I hadn't
upgraded glibc by compiling it from the newest and greatest sources;
after removing the new self-compiled version, things worked like a
charm ;). Only then you would try to install the other packages you
wish to have on your machine.

Anyway, don't lose your patience with it - when the box eventually
works, it's a nice workhorse one can rely on.

Manuel
--
Homepage: http://www.hinterbergen.de/mala
OpenPGP: 0xA330353E (DSA) or 0xD87D188C (RSA)
Loading...