[haiku-development] Re: bootable cdrom/installer
- From: Richard Jasmin <jasminr@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 07 May 2009 22:30:10 -0400
I have the CDROM boot fix, if anyone is interested.Appears project FPOS
on google, which I am also maintaining, has the solution.
This has worked for some people off of a hard drive as well.
If you compile a HaikuOS elf kernel image and have the files laid out
appropriately, I can produce a bootable ISO given your files are where
they should be.
That being said, Haiku will boot and chainload through grub the Haiku
specific FS,furthermore, the rest of the OS.This avoids a customary boot
sector,which as we know has many issues, only some of which I have
discovered in the past.If I know which file or ramdisk specifically
loads the Haiku kernel, the cdrom WILL boot.Now as we know, GRUB can be
rebuilt to load Haiku/BeOS filesystems, even 2.6 kernels have the option
for mounting BFS filesystems as well.
I think for now, this would be the viable solution.Later you can remove
grub completely, as you already have the sources available to you for
GRUB.
Your are talking about maybe 512BYTES of information, and a few K of
chainloading for launch, really its not that critical to hand write the
routines yet.
Emulation testing is good, but I discovered a bug in grub that breaks
qemu on emulation. If you have an extended keyboard try it out.Linux
WILL break.
Just hit the entended enter key on the far right when booting any linux
based OS under emulation.It is not limited to qemu,either.My actual PC
hangs at this point if I did it when booting.This is only one of the
many unknown qemu bugs.
The main issues I see with the installer are related to boot sector
calculation while under emulation.If the boot sector got written to the
correct location the emulated PC and real PC would boot from the same
spot, this booting haiku natively.We need to look at qemu sources to see
where the calculation msfires, but if I'm not mistaken it has something
to do with CHS/LBA calculations.
Dont quote me on this, but I may have code from DaphineOS that can
help.It is not in C,rather in Delphi or Pascal[hence the name,FP-OS],
but it is at least understandable what the routine does, unlike some C
that I have seen to date.
If I'm reading the program correctly, CHS is calculated ok, but LBA is
off somewhere.Will look at the code and see what else I can point out,
but I am not an expert in C or C#.LBA is used on newer hard drives, so
when the boot sector is calculated, the math is off, and the Haiku part
of the bootsector is not written correctly.[The first part loads ok,
looks for the haiku specific part and fails with a message.]
My smallest drive comes from an xbox at 10gb, my test drive was
120.Above 4gb, was it? we started using LBA, above 32gb?? extended LBA
and above 120gb 48-bit LBA.
Basically whenever we had to update with drive software in the past
because the BIOS didn't support the drive size, this was where the
calculation changed.
I can help if you want, but you think I'm being a dick, I'll walk
away.For me,nothing boots and as we know, anything bootable is better
than nothing.
FPOS boots for me,though from ISO or cd, so I go with it.So far it is
the only Pascal derivative of Linux that has gotten this far.
Rich
On Thu, 2009-05-07 at 19:05 -0700, pete.goodeve@xxxxxxxxxxxx wrote:
> On Mon, May 04, 2009 at 01:16:20PM +0200, Ingo Weinhold wrote:
> >
> > > [...on changing script recognition] To me, it looks fine, but I have only
> > > a dim grasp of what I'm looking at.
> >
> > So do I. In r30626 I changed it accordingly anyway. ;-)
> >
> I got rather sidetracked for a while there, but I can now happily report
> that, with Ingo's fix and the required Haiku directory changes, xicon
> now works a treat!
>
> Thanks Ingo...!
> -- Pete --
>
>
Other related posts:
