Beige PowerMac G3/266 trouble - Powerpc

This is a discussion on Beige PowerMac G3/266 trouble - Powerpc ; 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 , and burnt that onto a disc that I can read OK from ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Beige PowerMac G3/266 trouble

  1. Beige PowerMac G3/266 trouble

    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
    ,
    and burnt that onto a disc that I can read OK from the Mac. After looking
    at the notes on , I
    discovered that this model doesn't support Open Firmware booting from
    either floppy or CD-ROM.

    So then I found out about 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: MAT****A 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
    ,
    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.

  2. Re: Beige PowerMac G3/266 trouble

    On 2006-04-16, Lawrence D'Oliveiro wrote:
    > 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
    >,
    > and burnt that onto a disc that I can read OK from the Mac. After looking
    > at the notes on , I
    > discovered that this model doesn't support Open Firmware booting from
    > either floppy or CD-ROM.
    >
    > So then I found out about 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.

    >
    > 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: MAT****A 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).

    > 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.

    > I also tried downloading vmlinux and initrd.gz from
    >,
    > 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)

  3. Re: Beige PowerMac G3/266 trouble

    In article ,
    Manuel Tobias Schiller wrote:

    >/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.

    >... 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?

    >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.

    >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").

  4. Re: Beige PowerMac G3/266 trouble

    On 2006-04-16, Lawrence D'Oliveiro wrote:
    > In article ,
    > Manuel Tobias Schiller wrote:
    >
    >>/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.

    >>... 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.

    >>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.

    >>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)

  5. Re: Beige PowerMac G3/266 trouble

    In article ,
    Manuel Tobias Schiller wrote:

    >On 2006-04-16, Lawrence D'Oliveiro wrote:
    >> In article ,
    >> Manuel Tobias Schiller wrote:
    >>
    >>>/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?

    >>>... 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.

    >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.

    >>>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).

    >>>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.

  6. Re: Beige PowerMac G3/266 trouble

    On 2006-04-17, Lawrence D'Oliveiro wrote:
    > In article ,
    > Manuel Tobias Schiller wrote:
    >
    >>On 2006-04-16, Lawrence D'Oliveiro wrote:
    >>> In article ,
    >>> Manuel Tobias Schiller wrote:
    >>>
    >>>>/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.

    >>>>>... 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

    >>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).

    >>>>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.

    >>>>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)

  7. Re: Beige PowerMac G3/266 trouble

    In article ,
    Manuel Tobias Schiller wrote:

    >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.

    >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.

    >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, 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.

  8. Re: Beige PowerMac G3/266 trouble

    On 2006-04-18, Lawrence D'Oliveiro wrote:
    > In article ,
    > Manuel Tobias Schiller wrote:
    >
    >>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.
    >
    >>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.


    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.

    >
    >>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.

    >>>>>>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)

  9. Re: Beige PowerMac G3/266 trouble

    In article ,
    Manuel Tobias Schiller wrote:

    >Next time, please read the whole [initrd.txt] 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 --


    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.

  10. Re: Beige PowerMac G3/266 trouble

    On 2006-04-19, Lawrence D'Oliveiro wrote:
    > In article ,
    > Manuel Tobias Schiller wrote:
    >
    >>Next time, please read the whole [initrd.txt] 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 --

    >
    > 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.

    > 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, I might have been wrong there. Sorry if my tone grew a bit harsh.

    >>>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.


    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...)

    >>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.


    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.

    >>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)

  11. Re: Beige PowerMac G3/266 trouble

    In article ,
    Manuel Tobias Schiller wrote:

    >On 2006-04-19, Lawrence D'Oliveiro wrote:
    >> In article ,
    >> Manuel Tobias Schiller wrote:
    >>
    >>>>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.

    >
    >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
    ). Thus, what starts out as a
    kernel-only process turns into a full regular userspace process.

    >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...

    >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.


    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
    , 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.

  12. Re: Beige PowerMac G3/266 trouble

    On 2006-04-19, Lawrence D'Oliveiro wrote:
    > 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

    > 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.

    > 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)

+ Reply to Thread