For what it’s worth, ImageUSB (by Passmark Software) should also do the job.
Hello. I tried beta3 and beta4. Beta3 works on my laptop [Asus A9RP/A9000RP], managed to boot to a working desktop with VESA. Beta4 doesn’t work at all. It either gets stuck at the black debug screen (enabled debug output to screen, otherwise it will hang) or KDL. Using safe mode & VESA brings me to a desktop but the Tracker quits and everything hangs. I filled up the survey form already. Currently looking for a long term stable operating system to use on this laptop since there’s no support from from hardware and software manufacturers even when the laptop is still usable.
1 Like
Hello,
It is too late for the survey form since the release is already shipped. For remaining problems, please submit tickets at dev.haiku-os.org.
Thank you. I’ll visit that link.
I fixed the build error issue by installing zstd_devel, not
zstd_x86_devel even I used x86 platform.
Read the Haikuporter wiki
Haven’t build Haiku inside Haiku for a while, but @rxg could be wright here as in: you need the gcc2 package to be able to build it (for zstd)?
Thanks for the information. Here is my trial - do the fresh installation of x86 R1/beta4 hrev56578 and upgrade it to hrev56761, then buid with the same current source but still get zstd header files missing error. Maybe the commit works for x86_64 platform?
@rxg:
I think that commit only makes sure that package gets added to the “Optional Packages” on newly build nightly images. As you’re installing from a fresh (original) beta4 ISO that does NOT has that file already… it just won’t be there.
(I could be wrong, thou, but…)
You might need to install from a fresh nightly image to see that fixed. Or just manually install zstd_devel, of course 
So, I managed to get the R1 beta 4 booting on my late 2012 MacMini (Core i5, 16GiB RAM, installed on a hard drive not SSD.) But things are a bit weird:
- needs to use OpenCore to boot. Using the Apple boot picker it just hangs.
- no access to the boot menu
- had to use another machine to blacklist the intel_extreme driver
- setting up the EFI boot works to boot the OS, but it KDLs on loading Tracker/desktop which there is a screenshot of on this thread.
The USB key I’m using boots just fine and will install the OS, but using the same EFI boot data as it on the key it KDLs as listed above.
Here is the weird part - if I delete the BFS partition from the key, and use its EFI entry to boot, it will boot to a stable OS from the hard drive install. So the question is - why? I can live with this, but I’d love to get it natively booting.
I also tried the latest HREV as of a day or so ago - and it does the exact same thing. The BOOTX64.EFI is a different size, but neither make it boot to a desktop from the hard drive.
One last thought - I have a MacBook Pro with essentially the same hardware, and it KDLs booting from the USB key at about the same point.
That kernel panic does not look related to boot setup, it happens quite late in the boot process, when loading translators for the translation kit.
So, what could be the chain of events leading to this specific code failing? Did the firmware overwrite some memory we’re using for example?
That could be the case. It is just weird that the exact same setup boots with the EFI code on a USB stick, but not from the drive via SATA. The only difference is where the EFI bootloader is located.
The MacMini has two SATA ports, and the hard disk is on the second port (haiku sees it as /dev/scsi/0/1/ iirc, and the main drive is /dev/scsi/0/0, MacOS agrees they are disk0 and disk1.) I could try messing with the EFI on the main drive but it has OpenCore on it and without that MacOS will not boot, so I am obviously reluctant to mess with it too much.
I can file a bug, but is there any useful information I could gather on top of this?
Your screenshot is a good start, we can see:
- A page seem to think it is concurrently accessed by thread 128
- There is no thread 128
- I’m not sure the dumped info about the page makes sense
- I think the “cache _cache” command was not run because the previous command failed, can you run it again?
Sure - I removed the EFI from the installed disk because otherwise I got 2 entries in the boot “menu” under OpenCore and it was slightly confusing. I just need to boot back in and put it back. I will see if I have time this afternoon, if not it will be an evening this week.
I replied to your other thread: there is already a ticket about this problem, it affects a lot of Mac hardware and has for many years.