[Resolved] Haiku installation...gone!

I hadn’t bothered to update Haiku in a while. I noticed that the last entry in the boot menu was sometime in October, 2022. I figured it was time to freshen things up, so I did a full update last night. About 193 packages were downloaded and installed, no problem. Upon reboot, the Haiku bootloader can no longer see the Haiku drive! Also, this is on bare metal, on my System76 laptop.

I managed to get Qemu to run with EFI and load /dev/sda as the disk. It loaded the Haiku bootloader, but also, no Haiku disks. To make sure I wasn’t mistaken, I tried booting /dev/sda with legacy boot, and as expected, nothing happened (Qemu’s firmware complaining about no bootable disks, expected since the laptop is EFI only).

I’m assuming the only thing to do is re-install Haiku. But what could have caused this? I’m not really concerned about data loss, but would like to not have it happen again. Once booted a live image of Haiku, is there a repair thing I should try?

You can run checkfs or look at the drive in DriveSetup and I think there is a bfsrecover app somewhere if you’ve lost data that you want back.

@bbjimmy was complaining in IRC the other day that his installation stopped booting and that DriveSetup showed the partition as unformatted BFS. I think he installed an older hrev over his Haiku installation.

The last time this happened to me, I had to boot using the Beta 4, then copy the Beta 4 EFI boot information to my existing EFI partition. So, try booting from Beta 4 USB, mount the EFI partition, mount your original EFI partition, then copy the files from the Beta 4 to your old one.

Did the bootloader change? I probably should have read some docs :slight_smile:

Not recently, but if your install is old, it’s difficult to tell which version you had. So that seems to be the first thing to try, see if you can boot with a newer bootloader

I had the same issue. Download haiku_loader.efi file:

and replace the old one, in my case with arcolinux:

/dev/sda1 300M 2,9M 297M 1% /boot/efi


and voila. Thanks for @3dEyes for his help with it.
I suppose it should be fixed in next releases ?

If no one reports nothing to the bug tracker, it won’t get fixed. Is there a ticket about it?

EFI was working and attempting to boot, but the partition was hozed.

I had also the same a couple of months ago. Solved it by updating my EFI boot loader from the live image, as mentioned above.

Same here, updated Bootx64.EFI file on my desktop PC with Haiku original nightly install from Jul 2020 (with updates every 2 months or so), and after updating EFI today, all is good now. Interesting that fresher install on Dec 2021 laptop did not have this issue.

I’ll probably need to do the same on an older (2014) MacBookPro, that box has Haiku original nightly from Mar 2016 and I also regularly update every 2 months or so (last update Nov 2022). This laptop is a testament to the quality of nightly images (and Haiku in general), since I have a Haiku install which was originally done 7 years ago, and it’s still ticking away, with regular updates. I think I updated EFI twice already on that box.

1 Like

I guess packages in haiku repo use zstd compression at least from hrev56688. The bootloader seems to support that since hrev55536 (oct 2021). Given that for EFI you have to update the bootloader manually, you may have an older one and have trouble booting.

1 Like

Yes, indeed, this is what happened: after the beta4 release, the nightlies were switched to use zstd compression for packages, which the EFI bootloader only supports since sometime last year, so if you had an earlier bootloader installed, it wouldn’t be able to load the packages.

Ultimately the bootloader should be able to update itself, but that currently isn’t possible because we ship the EFI loader inside haiku.hpkg (which is compressed) and not haiku_loader.hpkg (which is uncompressed, for precisely this reason among others.)

That shouldn’t matter. We can’t put either package into the ESP and have to copy it either way.

We will have to figure out a way to automatically update a versioned efi binary in the esp.

The point is that the driver in the ESP could probably update itself, by extracting the loader from an uncompressed package file.

that seems rather complicated, and wouldn’t account for the possibility of us using something orher than bfs. Or the loader taking a version from a wrong install and such.

For now, how about the updater just checking for this, and prompting the user to update the boot files ?

Thanks all for the suggestions. I was able to extract the EFI loader from the esp.image file in the ISO, and now my machine boots Haiku once again!