Did not find any boot partitions

I looked through a similar thread here but did not find a solution.
When the HAIKU bootloader gets to the 4th icon there is a kernel panic that claims “Did not find any boot partition”

This is on a Lenovo ThinkPad P1 Gen3 trying to boot from an external SSD.

The syslog clearly shows that a partition with the Haiku GUID was found on this external disk, but for some reason it doesn’t seem to be able to boot from it.

The last errors in the syslog, I think indicate that it considered the main disk partitions after not being happy with the BFS partition.

The main disk has Windows 11 and recovery partitons… probably a 4-5 in total (counting Windows recovery, Lenovo recovery, Windows itself, Windows EFI boot, etc.

I’m guessing for that lines like this:

intel: pm_identify_partition(0, 3: 290455552, 509656170496, 512)

That the first two numbers are referring to a disk # and partition #, the rest being block start/end and block size?
Anyway, I noticed that line for (0,0: …) through (0, 5: …) which I think covers all the main disk partitions

Another notable logs message says:

0x0000000043eab438 Partition::_Mount check for file_system: BFS Filesystem
PackageVolumeInfo::SetTo()
PackageVolumeInfo::_InitState(): failed to parse activated-packages: No such file or directory

Which seems like if found the BeFS filesystem and then had some trouble with it.

I’m not sure how to proceed. Booting from a USB thumb drive made from the Haiku ISO worked fine… eventually I found the instructions for installing properly for EFI (those could be a lot clearer) and managed to at least get the external SSD starting up with the Haiku Bootloader, but now I’m stuck. I tried safe mode with most things disabled but the result was no different.

If there is any specific thing from the syslog that would be helpful let me know.

I would love to get this working. (I actually have an original PowerPc BeBox sitting somewhere in my basement that a friend gave me long ago, I never managed to get it to boot either come to think of it :slight_smile: )

2 Likes

I can confirm that indeed /system/packages/administrative/activated-packages does not exist on the partition I am trying to boot from.

Okay,replying to myself again… I see that the activated-packages file is not expected to exist on first boot. But this all seems to suggest that the partition that it claims to not find is found, or does it print the same error if the entire partition fails to mount?

What are the parameters of the partitions table on the external ssd?
DriveSetup screenshot ?

External ssd - work fine
UEFI and CSM/legacy bios

See also Could not find boot partition - #4 by javanx

Thanks @javanx , I did read that already and confirmed the correct GUID is used for the partition according to the syslog…

For normal loading, IPM must be used.

I created the EFI partition by following the instrucitons on the “UEFI Booting Haiku” page, by typing 64 for the size, 64MiB, then I created the main partion letting DriveSetup use the remaining space.
The partition scheme is GPT, the partition types and filesystems are the same as your screenshot, but in the opposite order (because:

The last disk in that screeshot, /dev/disk/usb/1/o/… I named things the same as the USB had them (simply because it was a working example). The USB that I’ve booted off is /dev/disk/usb/0/0/…

I ran checkfs on the BeFS partition and it did not complain.

Instructions at UEFI Booting Haiku | Haiku Project clearly state “* Choose a GPT disk system on the target device.”

Try using Intel Partition Map .

This smells like usb3 issue. Try your external disk on other computer to verify it is ok. If it boots ok, it is clearly your thinkpad. You can different thumbdrive, different usb port, etc.

1 Like

The disk itself appears to be working fine. I run checksums on the packages and compared to the same from the Haiku ISO. They matched.
I’m not sure how it could be my ThinkPad or USB3, since Haiku is using the same port to read and write to the SSD when installing from the ISO.

1 Like

I tried to use GPT, but that doesn’t work at all.
I followed the instructions at Installation Guide | Haiku Project
The laptop won’t even attempt to boot from it. When I select that drive from the firmware’s boot menu it simply goes right back to the boot menu screen.

(And really, Intel Partitions are obsolete, I’m not that nostalgic :slight_smile: )

I have a PC with UEFI that can’t use GPT. Maybe your laptop has the same “defect”? I agree that Legacy MBR sucks, but if GPT fails, maybe it is the solution?

Did you forget to copy Haiku efi loader on ESP partition (also called EFI partition sometimes)?
On the ESP partition, you must have a folder named EFI and a subfolder named BOOT. There you have to copy the haiku bootloader and rename it BOOTX64.EFI.

If you have boot Haiku on an USB key, you can find the file in /boot/system/data/platform_loaders folder where it is named it is named haiku_loader.efi.

Otherwise, you can also copy it from the ESP partition of the USB key.

A little warning, GPT partition scheme and MBR bootloader are both writing at same place at beginning of the disk. Since you chose to use GPT, you can not use MBR bootloader.

As I said, the Haiku Bootloader gets to the fourth icon and then there is a kernel panic as it complains about not being able to find the Haiku partition, despite the fact that the same bootloader has the partition listed in the syslog.
I have tried with just the Haiku Bootloader, and with it and rEFInd. both worked the same as far as booting Haiku was concerned.

MBR would only be the solution if it was possible to boot with it… it is worse than the GPT option because it doesn’t even get to the Haiku bootloader at all. Unless the instructions are wrong for it too and I still need the extra EFI partition and manual copy steps.
… Ah yes, they are. So the installer and instructions for installing are simply wrong. Someone should update Installation Guide | Haiku Project as those instructions are never going to result in something that works from what I can tell.

What good is the installer if it doesn’t actually install the required files?

Anyway… after creating a MBR partitioning scheme and creating the EFI partition and the BeFS partition, and manually copying the bootloader to the EFI partition, it still doesn’t work… exactly the same problem.
Though maybe worse this time, I can’t tell for sure. The syslog doesn’t list the partitions for the MBR partitioned device, so unlike with GPT, I can’t see if it could detect the Haiku partition or not.

The instructions to hold SHIFT to get a boot menu from the CD/USB also seem to be wrong, I saw somewhere else SHIFT+Space was mentioned, that worked.

I tried that and selected the SSD partition as the boot partition and got the same error. Funny that the boot menu was able to find the partition to present it as an option.

Also the “reboot” command from the kernel debugger doesn’t work. That just hangs the system.

It seems people will just comment with random unrealted booting problems…

Here the message we have is “cannot find boot partitions”. This means we are pretty far in the boot process already. The bootloader was found. The kernel was found, loaded, and started. This rules out pretty much all problems with partitioning and bootloader installation, otherwise the boot wouldn’t get this far.

I appreciate that everyone is trying to help, but please, take the time to read the description of the problem and think a bit about what it means, otherwise, you are just adding confusion.

Anyways, let’s look carefully at the logs that were shared in the initial post… a complete log would help.

This is the intel partition module trying to look inside each GPT partition to see if it contains an intel partition table. Not something you would find on a well-structured disk, but on Haiku, it is possible to read such things.

Anyway, just before that you should see efi_gpt_scan_partition called for each partition, and you will also see various filesystems scanning each partition (but not all of them have debug logs at this stage).

When all that is done, the kernel will print a complete, human-readable listing of the partitions, in there you can check the “type” and “content type” (both should be Be File System for your system partition).

After that there should be an “Identified boot partition by partition offset” and then the BFS partition will be mounted(bfs: mounted "System" (root node at xxx device=yyy)`

If you don’t get this, as extrowerk said, it could be a compatibility problem with the hardware, resulting in not finding the disk because, for example, it took too long to detect it (even if it works later on).

A complete copy of the syslog would be very useful for investigating, and will save time replying to people who suggest unrelated solutions for unrelated problems that you don’t have.

3 Likes

If I knew how I could get a copy of the syslog onto some media, I would have posted it. I can take pictures with my phone, but there are many many pages, it isn’t practical.

I’ve currently got it setup as MBR, the syslog doesn’t have anything that says “Identified boot partition” or “mounted”

I’m going to go back and reconfigure it as GPT again, but for some reason now the partitions refuse to unmount, even when forced. So I can’t use DriveSetup to repartition. Argh…

editing this post as I’ve reached the new user limit for posts on first day…

Okay… I got repartitioned as GPT after a reboot. This time I put the BeFS partition at the start of the drive and the EFI partition after it, just for fun. It didn’t help.

syslog | grep efi
shows three results, I know two are from the internal drive with Windows 11.

efi_gpt_scan_partition(cookie = 0x0000000043ea9568)
efi_gpt_scan_partition(cookie = 0x0000000043eab240) ← this appears to be for the external SSD
efi_gpt_scan_partition(cookie = 0xffffffff8300f620)

syslog | grep type shows:
[ 0] partition type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
[ 1] partition type: e3c9e316-0b5c-4db8-817d-f92df00215ae
[ 2] partition type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
[ 3] partition type: de94bba4-06d1-4d40-a16a-bfd50179d6ac
[ 4] partition type: de94bba4-06d1-4d40-a16a-bfd50179d6ac
[ 0] partition type: 42465331-3ba3-10f1-802a-4861696b7521
[ 1] partition type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b

Those last two are propery identified as my the partitions I have named “Haiku” and “haiku esp” (both with attributes: 0)

and then that grep for ‘type’ found:
get_boot_partitions(): boot method type: 0
after that the first set of partitions from the internal disk show up again, but nothing from the external SSD.

I see:
ucode_load: system/data/firmware/intel-ucode/06-a5-02
ucode_load: couldn't find microcode
Does that indicate that it tried to access the /system/data/firmware/ folder on the BeFS partition - as in, it found the partition and was reading from it? Or is that just that it wanted to find that path and we still don’t know if it mounted the partition?

The phrase “content type” does not appear in the syslog.

The syslog then dumps tons of PCI info, ACPI info,
There are a a couple lines of:
usb error xhci 0: ConfigureEndpoint() failed invalid max_burst_payload
usb error xhci 0: unabled to configure endpoint: Invalid Argument

usb hub 2: port 16 was warm reset
… all ports up to …
usb hub 2: port 25 was warm reset

usb hub 7: port 2: new device connected
usb error xhci 1: failed to enable slot: Operation timed out
usb hub 2: port 3: new device connected
get_boot_partitions(): boot volume message:
KMessage: buffer: 0xffffffff827a39f0 (size/capacity: 255/255), flags: 0xa
  field: "partition offset"  (LLNG): 20480 (0x5000)
  field: "packaged"          (BOOL): true
  field: "boot method"       (LONG): 0 (0x0)
  field: "disk identifier"   (RAWT): data at 0xffffffff827a3aa0, 79 bytes
get_boot_partitions(): boot method type: 0
intel: ep_std_ops(0x1)
intel: ep_std_ops(0x2)
intel: pm_std_ops(0x1)
intel: pm_std_ops(0x2)
dos_std_ops()
dos_std_ops()
sdhci_pci: supports_device(vid:8086 pid:1911)
sdhci_pci: Not the right subclass, and not a Ricoh device
sdhci_pci: supports_device(vid:8086 pid:15eb)
sdhci_pci: Not the right subclass, and not a Ricoh device
publish_device: node 0xffffffff80ae7e68, path disk/nvme/0/raw, module drivers/disk/nvme_disk/device_v1
nvme_disk: attached to NVMe device "SAMSUNG MZVLB512HBJQ-000L7 (S4ENNX3N649137)"
nvme_disk:      maximum transfer size: 2072576
nvme_disk:      qpair count: 32
nvme_disk: namespace 0
nvme_disk:      block size: 512, stripe size: 0

Note that this Samsung disk in the internal SSD, not the one I have installed Haiku to.
It goes on a bit and then re-lists the partitions from that internal disk…
a few filesystems complain about invalid super blocks for each of those partitions…

…and then the syslog is done.

I don’t know if I’ve included anything from the syslog that sheds any more light on the situation. As I say, if I knew a way to dump the syslog somewhere do I could post it, I would.
The syslog only contains one line that ever mentions BFS, that I included in my original post:
0x0000000043eab318 Partition::_Mount check for file_system: BFS Filesystem

Intel Partition Map is used in ISO Haiku R1Beta4.
The option of using Inyel Partition Map provides loading from the USB disk in two BIOS modes - uefi and CSM/legacy.
GPT partition scheme and MBR bootloader are both writing at same place at beginning of the disk. Since you chose to use GPT, you can not use MBR bootloader (CSM/legacy bios).