Opened 16 years ago

Last modified 8 years ago

#3545 new enhancement

bootman : implement multi-drive support

Reported by: mmadia Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: System/Kernel Version:
Keywords: Cc: umccullough
Blocked By: Blocking: #2477, #13026
Platform: All

Description (last modified by axeld)

Summarizing a thread from [haiku-development]

1) the boot loader needs to make a connection between drive ID and disk in a way that the OS can recognize it again. IIRC BeOS uses a sum/hash of the contents of a few blocks until it has enough to differentiate all (BIOS) drives. The name, or serial number is probably not reliably available from the BIOS, but I haven't really tried that yet.

2) it would need to store that information in the kernel_args structure.

3) when the OS detects the drives, it would see in that structure how it can recognize the drive again, and can then store the BIOS ID of that drive internally, so that B_GET_BIOS_DRIVE_ID can work as expected.

Change History (17)

comment:1 by mmadia, 16 years ago

Another thread from [haiku-development] that might be useful.

comment:2 by idefix, 16 years ago

See also ticket:2477.

comment:3 by umccullough, 15 years ago

Cc: umccullough added

comment:4 by axeld, 15 years ago

Description: modified (diff)
Owner: changed from axeld to nobody

comment:5 by mmadia, 15 years ago

Blocking: 2477 added

comment:6 by scottmc, 13 years ago

Milestone: R1R1/beta1

comment:7 by pulkomandy, 10 years ago

An alternative solution would be to override interrupt 13 in the boot manager to swap the drives. Smart Boot Manager does this, for example: http://sourceforge.net/p/btmgr/code/HEAD/tree/manager/myint13h.asm

This allows booting from another drive without cooperation from the booted OS. Makes it possible to boot things other than Haiku from other drives.

Is there a strong desire to keep bootman, or would it be acceptable to ship with Smart Boot Manager instead? It seems there is little interest in improving bootman so maybe we should just ship something that works instead. And with UEFI this will soon be irrelevant anyway.

comment:8 by axeld, 9 years ago

Milestone: R1/beta1Unscheduled

While it would be nice to be able to boot from a second HD, I don't think this is really that important. Smart Boot Manager is too fancy for me, I would rather like to see someone improve bootman. I currently don't even remember how we detect the boot volume, so I would expect that the int 13 hack might not even work for us.

comment:9 by pulkomandy, 9 years ago

Technically this is needed for feature completeness vs. BeOS R5, which is why this was in the beta1 milestone. But it seems no one is interested in actually implementing it.

The int13 hack will probably work, seeing that it works in Smart Boot Manager :)

comment:10 by axeld, 9 years ago

No, it wouldn't. We don't have to fool Haiku about the BIOS ID, we'll have to be able to map the drives to BIOS IDs within BootManager (formerly known as bootman).

I just had a look at the sources, and AFAICT we already support 1-3) from Matt's points in the summary. Only the BootManager has to be adapted to make use of that information.

Version 0, edited 9 years ago by axeld (next)

comment:11 by pulkomandy, 9 years ago

B_GET_BIOS_DRIVE_ID returns B_NOT_SUPPORTED, which seems to be the core of the problem. As far as I can see, everything is ready in BootManager, both the setup app and the bootloader itself.

comment:12 by humdinger, 8 years ago

Blocking: 13026 added

(In #13026) Good catch, bbjimmy. I knew there was one, but didn't find it ...

comment:13 by CodeforEvolution, 8 years ago

I think I found the problem, no drivers implement the B_GET_BIOS_DRIVE_ID command for ioctl, seems simple enough to implement, find ioctl handler hook in driver, add new case handler for B_GET_BIOS_DRIVE_ID, figure out on that specific device how to identify the bios drive id.

Last edited 8 years ago by CodeforEvolution (previous) (diff)

comment:14 by axeld, 8 years ago

Yes, the boot loader already passed information on how to identify the drives. Implementing B_GET_BIOS_DRIVE_ID is the main part of the remaining work. However, IIRC also BootManager does not try to make use of it yet.

comment:15 by pulkomandy, 8 years ago

Yes, as it was documented in comment:10.

The problem with getting the drive ID is that these are not stored anymore, and once our ATA stack has taken over the BIOS for disk control, we have no way to get it anymore. It is important that the IDs are correct for the bootmanager menu to work properly (and boot things on the right drive).

IIRC, this was discussed on the mailing lists some time ago, and a possible solution is that the bootloader should provide the kernel with enough information to identify the drives. I think it was mentionned that BeOS would read sectors from the disk and compute a checksum, until it found an offset where the checksum would be different for all drives. It then provided a map from the checksum to the drive IDs, and the kernel could compute the same checksum and use the map to know the drive ID.

Another option for identifying the drives is asking them for their internal data (serial number, etc) and using that, hoping that we don't find two drives with identical serial numbers.

comment:16 by axeld, 8 years ago

As I tried to said before, IIRC the boot loader already does that mapping, and provides that information to the kernel. It's now just a matter of making use of it.

comment:17 by pulkomandy, 8 years ago

Right, this seems to be there in the kernel args already (only for the BIOS_ia32 platform but this is the only one where bootman works currently): https://github.com/haiku/haiku/blob/master/headers/private/kernel/boot/platform/bios_ia32/bios_drive.h

And the list seems to be generated here: https://github.com/haiku/haiku/blob/master/src/system/boot/platform/bios_ia32/devices.cpp#L522

We need to find the way to compute the same "identifier" on the kernel side, and match it with the drive IDs stored in the kernel arguments.

Note: See TracTickets for help on using tickets.