I have installed Haiku onto my laptop from the R1/beta4 release, and am trying to use that as a development platform for building the nightly version of Haiku. I got the git clones and ran configure to build the x86_64 variant, used jam to create an iso, and then burned that to the same USB stick that I’ve been using. Tried to boot it, and it puts up the seven (?) icons, but no ‘Haiku’ text, and then panics with the above said message. Did a little digging, and found that vfs_mount_boot_file_system is looking for a partition with the type ‘Be File System’ (by calling several other routines). I checked with drivesetup on the release version, and the partition on the USB stick that I installed my nightly build to does have that type. Can’t figure out why the boot loader won’t find it. This is all being done on a Dell Inspiron 15 3535, in case it matters.
This is normal and expected: by default the image is built without the (trademarked) Haiku name and logo, unless you enable them with the corresponding configure script option.
Either it didn’t see the USB drive for some reason, or the USB drive is not formatted correctly.
You say you created an “iso”, I assume you mean an anyboot image? That’s what you will need to boot from USB, a plain ISO image would not work. The anyboot has both an ISO filesystem (so it is bootable when written on a CD) and a MBR partition table with a BFS partition (so it is bootable also from USB).
Did you try putting a nightly build from https://download.haiku-os.org on your USB drive? If that works, the problem is in how you built you own image, if it also doesn’t work, there is a problem in how you write it to the USB drive, or some compatibility issue on your hardware.
I used ‘jam -q -j12 @nightly-anyboot’. Let me know if that wasn’t correct.
I downloaded the latest nightly image from the website you mentioned, and other than the fact that it has the nice color logo, it fails in exactly the same spot. As you said, there must be a problem writing to the USB stick - although I used the same ‘belena’ software and usb stick that I put R1/beta 4 on and it booted and installed without problem. Do you have a recommendation for software that will work with either Windows 11, Linux Mint, or Haiku R1/beta 4
take a picture of the kdl crash screen, maybe we can find some infos there
-on the crash screen, type syslog and see if there are, for example, USB (xhci or ehci or uhci) errors, if the usb drive itself is detected but not the partitions on it, etc.
It looks like 57342 was the last working version. The next one on that website is 57346, and it fails.
Please note that I am no longer confidant of the cause of the ‘hang’ in the failing images. In my early testing, I was trying various safe mode and debug options that I believe artificially injected the partition failure. I am uncertain how to debug the failure without setting these options, however, so I would appreciate any advice on this.
bootloader: Implement TSC calibration via hypervisor CPUID leaf.hrev57346
Augustin Cavalier
9 days
-23/+55
fs_shell: Use UINTPTR_MAX not LONG_MAX.hrev57345
Augustin Cavalier
9 days
-2/+2
Fix build on arm64 (and other 64 bit non x86 platforms, probably)hrev57344
JackBurton79
9 days
-1/+1
Debugger: implement ReadU24hrev57343
David Karoly
10 days
-0/+15
Only the first one in this list (the change to TSC calibration) looks like it could affect the boot sequence. So maybe @waddlesplash can take a look at your problem in case there are issues in that area?
The safe mode and debug options are not persistent and don’t write anything to disk, so even if you tried them, after a reboot you should be back to a clean state.
Unfortunately, I’m not familiar enough with the source to immediately spot the problem. Since there is already a ticket for this, I guess I’ll let it go for now and assume that it will get fixed through normal ticket tracking.
If there is more that I can do, please let me know. In the meantime, I’ll continue my playing around using hrev57345.
Indeed this change is supposedly the culprit of a different problem with the EFI loader on macOS, but exactly why is not clear at all. Furthermore the symptoms are very different: that fails at OS-kernel handoff, while this failure is much later.
@bcbarnes, are you booting via BIOS or EFI? Can you try reverting that one commit and see if it indeed fixes your problem?
I am booting via EFI. I’m not familiar with how to revert a commit, I do have the source for hrev57345 that I am currently in the middle of building on my laptop. I will post back here once the build is complete and I’ve tried to boot it.
Update: Built HEAD and tested. Hangs with 7 icons visible but dimmed out, as expected. Used ‘git revert’ to back out hrev57346. Started build again. I’ll post another update when it is done and tested.