Re: No HFS driver, and "change install priority" menu option missing -- and other bugs found while testing 2.4 boot floppies on OldWorld PowerMac
On Fri, Oct 01, 2004 at 09:56:37AM +0200, Geert Uytterhoeven wrote:
> On Thu, 30 Sep 2004, Rick_Thomas wrote:
> > On Thu, 2004-09-30 at 05:18, Sven Luther wrote:
> > > On Wed, Sep 29, 2004 at 11:11:49PM -0400, Rick Thomas wrote:
> > > > Now, is the loss under 2.6 of the HFS ".finderinfo" and ".resource"
> > > > pseudo-directories a bug, or a feature?
> > >
> > > You probably need to load the hfs+ driver ?
> > >
> > > If that doesn't solve it for you, please fill a bug report againstz our 2.6
> > > powerpc kernel packages.
> > Well... I tried the hfsplus driver. It refused to accept the hfs
> > filesystem on the floppy image. told me I should use "hfs" instead.
> IIRC, HFS+ is not compatible with HFS. So if the floppy uses HFS, you should
> use the HFS driver, not the HFS+ driver.
Thanks for the info. Keep in mind i am w total neophyte about HFS filesystems.
I suppose we would need to bring the HFS driver in 2.6 upto speed, or create
an HFS+ filesystem instead.
That said, this should not be the problem, since i was able to boot it with
the umax apus 2000 box here 3 consecutive times, before it again failed after
i used the floppy drive to write a new set of floppies, and it refused to work
forever after, even with the same floppies, while 2.4 floppies work reliabily.
So, i have a feeling that it either is something related with defective
floppy hardware, or unreliable ones, altough the fact that 2.4 works reliabily
contradicts this idea, or some problem with the 2.6 kernel.
Geert, you can probably help us here, the current scenario is :
- 2.4 floppies, either work fine, the frambuffer takes over and we see the
kernel boot info, or fail because of miboot problems, and we see a red
cross over the miboot stuff.
- 2.6 floppies, they load and then just before the framebuffer takes over,
we see a the small miboot icon changing color (like inverted video). When
it worked it would stay like that for a second or two, and then the
frambuffer device takes over and we see the log message. When it doesn't
work, we don't see the red cross, but we see the inverted video mode
(which meens the kernel booted, and the fbdev device is trying to take
over the video output), but then nothing, which i believe means the kernel
died in this step.
This is using the valkyrie fbdev driver. What is strange is that the same
kernel when booted with bootx (or miboot) has absolutely no problem.
I won't have time in the next 2 weeks, but it would be interesting to get the
early console info on the serial log. One thing is that at first it didn't
work, and that it started working when i tried to redirect /dev/ttyS1 to the
serial console, and added that option to miboot.