Re: [gentoo-mips] Question - Kumba LiveCD RC6

["Mike Martin" <mikemartin@linux.ca>]

[-- Attachment #1: Type: text/plain, Size: 3077 bytes --]

Thanks for your help. I will try another burn. I'm using cdrecord and am
using (I believe) good media. What command parameters for cdrecord would you
recommend?

For fun I tried booting with a different external CD-ROM drive ... with
identical results.

I will also try the disk out on a R4600 Indy.

Thanks for your hard work.
MikeMartin

On 1/22/07, Kumba <kumba@gentoo.org> wrote:
>
> Mike Martin wrote:
> > I recently downloaded and attempted to boot an Octane with this disk. It
> > died mounting the root partition:
> >
> > mount: Mounting /newroot/dev/loop0 on /newroot/mnt/livecd failed:
> > Invalid argument
> >
> > Not sure what happened. I assume I burnt the disk correctly else it
> > wouldn't have made it that far. Any suggestions?
> >
> > MikeM
>
>
> It's really hard to say.  I tested it on all of my systems before
> uploading, and
>   with the Octane, this means an external drive (funny enough, an O2 CD
> drive
> jammed into a Sun 411 case).  And that booted fine on both my Octane and
> Indy.
>
> "Invalid Argument" from mount could mean a wide array of things (yay for
> Unix's
> legacy of non-descriptive, ambiguous errors).  The process that occurs on
> an SGI
> bootcd for us is a rather complex one:
>
> 1. arcload boots from the DVh partition of the CD
>         (yes, these CDs have partitions)
> 2. arcload finds and boots a kernel
> 3. kernel loads, and executes /init in an embedded initramfs file linked
>         into the kernel
> 4. /init does some prep work, and launches `getdvhoff` to scan the CD
>         for the offset of the next partition (where / lives), and passes a
>         number representing this offset back to `losetup`.
> 5. losetup uses this number to "point" /dev/loop0 at this offset, which
>         effectively makes /dev/loop0 a block device with data on it.
> 6. mount tries to mount /dev/loop0 and pivot_root into the real Gentoo
>         filesystem.
>
>
> Quite likely, step #5 might've failed somewheres along the line.  The
> offset has
> to be exact to the bit, so maybe something got whacked in the burn and the
> detected offset is invalid.  Hard to say without more information.  Thus,
> when
> it got to step #6, boom.
>
> I'd try re-burning the disk at a slower speed, use only CD-R's of decent
> quality
> (TDK, Memorex, Sony, Ricoh/Ritek, etc,.. brands), and use cdrecord (or
> whatever
> license-unencumbered version is out there.  stupid license wars).  A few
> people
> reported getting it to work with a windows burn tool, but we have little
> data on
> that, thus why cdrecord is the suggested tool.
>
> Mostly, you were able to read the kernel into memory, which is ~8MB.  It's
> possible the disc you burned was good enough to get those 8MB off to boot
> the
> kernel, but when it went looking for the meat, it got denied and pwned.
>
>
>
> --Kumba
>
> --
> Gentoo/MIPS Team Lead
>
> "Such is oft the course of deeds that move the wheels of the world: small
> hands
> do them because they must, while the eyes of the great are
> elsewhere."  --Elrond
> --
> gentoo-mips@gentoo.org mailing list
>
>

[-- Attachment #2: Type: text/html, Size: 3913 bytes --]