The RCb1rc0 build I used was hrev56578+62, kernel Dec. 18 2022. I forgot to add before, the X8DTL-3f motherboard’s onboard Matrox G200eW graphics worked but only in VESA mode. I’ll update the survey to reflect that.
1 Like
Hmm do you have the matrox IDs for me? I worked on that driver. Currently only analog VGA is supported on that driver though.
2 Likes
just an FYI, if you have a windows 7 32-bit machine, Balena Etcher does not work. Use Win32diskimager. We might want to mention that on the install guide or download.
1 Like
I wanted to help here test on my hardware, but I could not find any downloadable ISO. The links in the original post don’t work. Are there alternative download locations?
These were pre-versions to test boot process. There are now release candidates available in this thread. Scroll down to last post if you want the “new” one (RC1).
1 Like
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?