Trying to try Kubunto...

[Ben Scott]

On 2/27/07, Brian Chabot <brian at datasquire.net> wrote:
>> Have you tried the CD in another system, just to make sure, for
>> sure, that the CD is good?
>
> It seems good.  Passed the md5 checksum on burn...

  That would be "no", then?

  I don't know if whatever checksum mechanism in use includes the boot
image on the CD, but if *not*, and the boot image is corrupted, you
could get exactly the behavior you describe (boot failures) and still
pass the checksum test.

  It would really suck if you went through all sorts of other problem
solving steps, only to discover you just had a bad CD.

  Boot the CD in another machine as a sanity test.  :)

>>   If you shut off all the GUI boot and frame buffer crap (I don't know
>> the details on this for *buntu, but most distros have a way to do it),
>> is there anything else that looks like an interesting error message?
>
> Just exactly what I retyped in the original post... about 5 lines is
> it.  Seems the buffers got cleared when BusyBox was loaded.

  I'd guess that it's actually some other thing (not BusyBox itself)
that's resetting the screen.  I know the framebuffer console has to do
a video reset when it initializes.  I've seen some kind of console
config utility that Red Hat uses also clear the scrollback buffer.  In
the past, I've had important messages lost due to such screen resets,
so it may be more than academic (or maybe this is a wild goose chase).

  I don't know about Ubuntu, but on Red Hat, the boot argument "nofb"
disables the framebuffer console.  Maybe try that?

  In plain old text mode, you should be able to scroll all the way
back to the kernel init banner ("Linux version 2.6.19-1.2911.fc6
...").

-- Ben