Hi, im not sure if its me, or its a bug:
I have 2 disks in my computer, one with haiku and other with lnx. In the release of Beta4, the boot loader dont detect my other hd instalation. I try with one of the latest nightlis but same behabord. I download the hrev 54815 and the hd instalation is listed:
So, its a bug? or this change is expected?
Thanks!
Haiku bootloader can only boot from a partition on the same hdd as the bootloader.
Thanks @lelldorin! But, in the past (hrev 54815) the bootloader lists my partitions with haiku in other disks.
That’s actually a limitation in the BootManager not limitation in the bootloader, but sometimes it doesn’t work for unknown reason, maybe a 32 bit vs 64 bit issue and vice versa?
Yes at the beginning up to alpha 4 we use the beos bootloader, but the new one can not do this anymore
It still works for me with as recent as the latest nightlies, i can boot another haiku install on another disk.
I think only the EFI loader can detect installations properly on disks besides the one it’s running on? But maybe I’m not remembering properly.
I just did a quick test, i have 1 haiku 32 bit and 1 haiku 64 bit on the first drive and 1 haiku 64 bit on the second drive all mbr.
The 64 bit haiku on the second drive can boot all of them, the 64 bit on the first drive can’t boot any of them,
the 32 bit on the first drive can only the 64 bit on the same drive.
I don’t think so. The current detection code removed detection of that and some new limits in boot VFS IIRC.
The BIOS bootloader should not have any problems with that, in BIOS it’s easy to enumerate hard disks and read them all.
We have a limitation in the BootManager installer (not the bootloader, and not even BootManager itself): the problem there is that the installer does not know how to map a disk path (/dev/disk/…) to the corresponding BIOS drive ID (which is a value starting at 0x80 for the first hard disk, then 0x81, 82 etc for the next ones).
The only part that’s missing is implementing the B_GET_DRIVE_ID ioctl in our disk drivers. The problem is, the OS has no way to know this once booted. In BeOS, what was done was the bootloader computed a checksum of the first few sectors of each drive, and gave the OS a mapping between the checksums and the drive IDs. Then the OS could do the same checksum, and find the corresponding ID in the map.
Bootman and its installer are ready to use this info when it becomes available.
Something change between hrev54815 and hrev56612. Both, pendrive and hd installs are 64bits, with hrev54815 (in the pendrive) the hd installation is listed in boot menu… if i use in the pendrive hrev56612 only the pendrive volume is listed. So, my question is… this is expected or its a bug?
Why would this be “expected”? Why would we decide to not show other disks? Of course it’s a bug.
It could be expected by a decision to not support this anymore. It could also be expected by the implementation of a new code that has not yet implemented this functionality. In short, it could be expected by an infinity of possibilities. It is clear now that then it is a bug… Thanks!
The Haiku image that I did put on my USB stick had the EFI system partition ESP on the SECOND partition. I don’t think this is really UEFI compatible. If I’m right (not 100% sure about it), this would mean that it works on some PCs/VMs and doesn’t work on others.
Might this have caused the problem? (edit: I’m refering to dsizzle’s problem.)
Greetings
Peter
