Re: Can GRUB Boot Haiku?

[Andrei Borzenkov]

В Mon, 15 Jun 2015 03:01:04 -0600 (CDT)
"Jay F. Shachter" <address@hidden> пишет:

> 
> Esteemed Colleagues:
> 
> Part of this posting is perhaps better suited to a Haiku mailing list
> than to a GRUB mailing list, but there does not seem to be any Haiku
> mailing list that is not utterly dead.  I joined the Haiku mailing
> list specifically to ask this question, but, not only did I not
> receive an answer to my question, but also, I did not even get my own
> question sent back to me.
> 
> Recently I acquired a laptop with an old BIOS, although I did not
> suspect just how old, until it was too late.  This laptop's BIOS is
> so old ("how old is it?") that it can only access the beginning of the
> internal disk.  Historically this was the main reason for the custom,
> on Linux, of placing /boot in a separate slice of disk toward the
> start of the disk, while the bulk of the filesystem went elsewhere
> (another reason was wanting to put the root filesystem on a logical
> volume, back in the days when GRUB could not boot from LVM) -- because
> on such computers, not only the BIOS, but also GRUB, cannot access the
> entire disk.  Thus, placing GRUB at the beginning of the disk is
> insufficient; the operating system that GRUB loads into memory must
> also entirely reside toward the beginning of the disk.
> 
> I did not suspect that my computer was that old, until after I had
> already partitioned its disk, and already installed FreeBSD
> 11.0-CURRENT, and LinuxMint 17.1, and OpenSUSE 13.2, and Haiku
> alphaR4, in approximately that order ("approximately" because the two
> Linux systems were installed on LVM volumes, and you never know
> exactly where LVM is going to put those things, but I did create the
> LinuxMint volume before creating the OpenSuSE volume).  I have already
> invested a huge amount of effort on some of those operating systems,
> especially FreeBSD, which is never even minimally useful until you
> invest a huge amount of effort in it, really sometimes I wonder why I
> bother, but I digress.  The point is that I am not now going to
> repartition the disk and reinstall the operating systems differently,
> I have to make the best of what I have.
> 
> Haiku resides toward the end of the disk, in what, on Linux, would be
> called sda8 (I reserved sda7 for SkyOS, not yet installed), and GRUB
> cannot boot it (this is Grub2, of course).  GRUB does not even know
> that sda7 and sda8 -- or, as GRUB would say, (hd0,7) and (hd0,8) --
> even exist, it only knows about slices up to sda6; if you try to say
> 
>    chainloader (hd0,8)+1
> 
> it complains about a "nonexistent partition", or words to that
> effect.
> 
> I had a similar (but even harder to diagnose) problem with OpenSuSE,
> which was actually partly within and partly beyond the reach of GRUB.
> I solved this problem by repurposing /dev/sda5, also known as (hd0,5),
> which was originally the shared swap area for my Linux systems, and
> turning it into a boot area instead; swap is now another LVM volume
> within sda6.  The OpenSuSE vmlinuz program was copied to the
> newly-repurposed boot area, and GRUB is able to find it there.
> 
> It occurs to me that I might be able to do the same thing with the
> Haiku kernel.  Linux comes with knowledge of befs and is able to read
> the Haiku filesystem.  I could conceivably copy the Haiku kernel to
> the (hd0,5) bootloader region (an ext2 filesystem) and then instruct
> GRUB to boot it, perhaps with legacy_kernel if multiboot does not
> work, providing it the equivalent of a root= argument so that it knows
> where its root filesystem is.
> 
> Is this possible?  Whenever I have booted Haiku in the past, I have
> used Haiku's own bootloader, instructing GRUB to do nothing more than
> chainloader.  I do not even know the name of the Haiku kernel, and I
> do not know what the Haiku bootloader does, perhaps it is something
> that GRUB cannot be made to do, something, perhaps, far more
> complicated than loading a single program into memory and transfering
> control to its entry point.
> 
> The real solution, of course -- and this is not a question only for
> readers of a Haiku mailing list, it is a question for all of you -- is
> to obtain a bootloader that can access the entire disk.  Is there
> another bootloader able to load programs from a region of the disk
> that the BIOS cannot see?  Or is there a module that GRUB could insmod
> that would render it able to do so?

On PC BIOS platform GRUB2 offers native disk drivers (PATA and AHCI) as
alternative to biosdisk that may be able to do it. But it is unlikely
to help - they make chainloading impossible for two reasons: a)
chainloaded module needs BIOS disk number which is not present in this
case and b) chainloaded module is using BIOS interface itself, so it
will not be able to read kernel. So unless someone writes
Haiku-specific loader you are likely stuck.

If Haiku is opensource it should be possible to look at what its boot
block does and do the same in grub. But note, that it will work only as
long as binary loaded by bootblock does not use BIOS disk access itself.
So you may need to check what this binary does etc until you come to
the point where disk drivers are loaded.

>                                     I do not see any reason why this
> should not be the case.  When GRUB loads one of my Linux operating
> systems, the operating system that GRUB loads, after GRUB brings it
> into memory, is able to see the entire disk, including the parts that
> the BIOS cannot see; why should not another bootloader, or indeed GRUB
> itself, be able to do the same?  I do not require that GRUB know the
> filesystem on which the booted OS resides; I only want to be able to
> boot operating systems like Haiku and SkyOS and IcarOS that are
> equipped with their own minimal bootloaders at the beginning of their
> disk slice, hence I need nothing more than "chainloader +1"
> capabilities.

As already explained - you cannot implement full disk driver in 440
bytes of boot block, so whatever you load in this way will have to use
BIOS as well and will not be able to find its data. You will need to
actually access filesystem, load necessary files in memory (including
disk driver) and pass control to them.

It /may/ be possible to avoid knowledge of filesystem - after all, 440
bytes cannot realistically implement it too, so boot block likely reads
from some standard offset. So grub could read boot block, extract
location of whatever it needs, load and jump to it. As poof of concept
such location could be passed in as argument.

>              As always, thank you in advance for any and all
> replies.  If this question is not of general interest (perhaps because
> it was discussed in the past and everyone except me already knows the
> answer to it) please reply to my personal e-mail, shown below.
> 
> 
> 
>                         Jay F. Shachter
>                         6424 N Whipple St
>                         Chicago IL  60645-4111
>                                 (1-773)7613784   landline
>                                 (1-410)9964737   GoogleVoice
>                                 address@hidden
>                                 http://m5.chicago.il.us
> 
>                         "Quidquid latine dictum sit, altum videtur"
> 
> 
> _______________________________________________
> Help-grub mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-grub