These are almost RC images; they are missing a few major tweaks that should come in the next few days. But the major difference between the previous images and these is the EFI bootloader.
Note that the EFI loader (1) is on the 64-bit anyboot only, (2) does not install itself automatically when installing Haiku to a partition; you must install the haiku_loader.efi to your system EFI partition and add it to whatever EFI loader you use manually, and (3) cannot boot from CDs, only from hard disks or USB drives.
Also note there are still some unresolved bugs in the wpa_supplicant and Mesa, so you may run into these.
THIS IS NOT THE FINAL R1/BETA1, but it is very close to what it will be.
The target ship date for the final version is now within a week or less; I am pretty busy with other matters over the next few days as is @kallisti5, but we’ll see what happens.
Awesome news! This is just plain exciting; I hope to test one of these builds (and if it’s okay with the community, do another batch of screenshots). Haiku is at last beginning to reach its beta after so long!
Dropping the .efi loader into your system EFI partition and then adding it manually to your boot menu works great; that’s how I run Haiku on my main laptop. You just have to do that manually for now. (If you run Windows or something else that doesn’t have an EFI boot menu and need to install one, I recommend rEFInd.)
Yeah currently I’m using EasyBCD with the fancy windows 10 GUI bootmenu turned off… and just adding Haiku to the windows boot menu. Which gives me a nice text boot menu and doesn’t mess up PS/2 support by loading windows (the graphical windows bootloader does mess up PS2).
It would be nice to have a guide for the EFI setup… I’ve avoided EFI on all my systems so far… though I’ve repaired a few EFI paritions from a windows recovery shell it’s still a bit alien.
One concern I have is that the USB image is partitioned into 2 partitions
an 800Mb OS image
a 2Mb UEFI image
empty (unused disk space)
Ideally, the 2Mb UEFI image should be created first, then the 800 MB OS Image. This way, if the user decides destroy the OS image and reparition to utilise the full disk size (say 32Gb or 64Gb), they end up with a hole. Final outcome becomes:
2Mb UEFI image
32/64Gm Haiku image
Note - a configuration with 1) 800 Mb empty, 2) 2Mb UEFI and 3) 32/64Gb Haiku will KDL, but with Haiku in first partition then it works
Any chance the 2Mb UEFI image be installed as the first partiton, this way the remaining USB disk space can be fully used for Haiku. The 800Mb empty gap is wasted.
Having said that, I haven’t experienced non debug Haiku for over a decade, and the speed of this image (compared to my nightly image I’ve been using for the last decade) is incredible - Haiku really flies with no debug code …
Testing on the Lenovo x140e, x131 and Hp Envy x360 ryzen and 1700x desktop I have will update this post as I test:
x140e:
realtekwifi crashes and hangs the boot with a black screen… perhaps blacklist it isn’t it isn’t functional anyway? Untill it gets updated to work correctly? I saw that it was hanging by blacklisting radeon_hd then it showed that the actual hang was realtekwifi in the debug output. Everything else seems to work once realtekwifi is blacklisted. I acutally have a partually ported verison of the merged realtek wifi driver that I want to test I think the last bit I need to do is update glue.c I’ll be on IRC later this week I’m sure I’ll have questions about this. Will have to test with Csm disabled later my power on password came back…so can’t turn off can at the moment.
x131e:
Went in the bios enabled EFI + disabled CSM and booted straight up off USB + I am posting from the realtek wifi ironically. This is the first time I’ve seen it work in Haiku. Will have to retest the x140e with the same EFI + disabled CSM. Note this is the same exact wifi card model as the one crashing above!?
x360 Ryzen 2500u\Vega8 graphics:
Crashes similarly regardless of options in the bootloader.
Ryzen 1700x \ Asrock x370 ITX \ Vega FE:
Note this system actually boots up with the non uefi and vesa only.
Tested on Surface Pro 4, with some trial and error I managed to find the right combination of settings:
Secure Boot must be turned off in Surface UEFI (obvious)
Debugging over serial (or on screen debugger) must be enabled, otherwise a weird timing issue causes the OS to KDL with “get_boot_partitions failed”
Failsafe graphics mode must be enabled, otherwise the OS hangs on “rocket” icon, intel_extreme driver breaks apparently
Safe mode must be enabled, otherwise the OS hangs on “rocket” icon
NVMe controller, Wi-Fi, Bluetooth, touch screen, pen, battery status, webcam - not working (not surprised). Type Cover works fine, both keyboard and touchpad. I haven’t tested audio.
Bear in mind that Haiku doesn’t support HiDPI screens, so everything is super tiny on native 2736x1824 resolution. Bumping up font sizes to 24 and restarting tracker and deskbar makes it kinda usable, though not all UI elements are scaled along with font size changes.
Very interesting. Can you please report a ticket about that, and include a copy of your syslog if possible?
Please paste the output of listdev somewhere so I can disable the chipset.
If you enable onscreen debug output + failsafe graphics driver, what line does it fail on?
We have no driver for NVMe yet. Once you post the listdev output, I can take a look at Wi-Fi and Bluetooth (these are usually the same chip; but if you’re booted in safe mode that may be the only issue), touch screen / pen are also interesting, possibly some sort of USB failure; webcams don’t work generally right now. No battery status is also interesting.
Maybe try booting with ACPI disabled (instead of “safe mode”?) The results of that might be interesting.
Wi-Fi and Bluetooth is supported under Linux using mwifiex driver. There is no FreeBSD driver for this chipset. Touch screen and pen requires an IPTS (Intel Precise Touch) driver. Webcam doesn’t even work on Linux to be honest and most things require a patched kernel.
Interesting observation with: " Debugging over serial (or on screen debugger) must be enabled, otherwise a weird timing issue causes the OS to KDL with “get_boot_partitions failed” ".
I have noted that a few users had mentioned in posts having encountered issues with finding/getting the boot partition on other systems. Maybe these issues are all related. Maybe enabling the debugger is a workable way to reach the desktop for the time being.
Also, I have not yet encountered a notebook for which enabling fail safe graphics mode was not needed to reach the desktop stage.
Probably why my laptop failed last night (Dell m6700)(ATi FireGL Mobile)
I’ll have to try the image in safe mode tonight.
I’m excited to see the progress over the last few years!
Update as I can’t reply to this thread for some reason:
Tested 32 & x64 builds last night on my laptop (Dell m6700 - i5, 16Gb, SSD, FireGL)
Both builds behaved the same and there was no apparent difference between a USB2 and USB3 boot stick.
Normal boot from USB: reached rocket stage and booted to a black screen - wifi light on the status strip was on solid.
Shift boot from USB: reached rocket stage and booted to a black screen - wifi light on the status strip was flashing constantly.
For comparison Nightly falls over with “Panic: Did not find any boot partitions!” but that might just have been trying to boot off a USB3 disk.
Given there’s no KDB firing off in the RC candidate images and no boot to desktop, whats the best way to get some debugging info so I can raise a bug ticket?
This is the one thing that have been keeping me from running Haiku on my laptop! Will install as soon as I have time again… With its fast boot and shut-down time Haiku/BeOS had been my default OS for any quick work on a laptop in the past (before EFI). Having to run it in Virtual Machine missed the strong point of using Haiku for me (speed).
It means you don’t have to use legacy BIOS emulation which not all EFIs even implement… the wifi in my laptop actually works when booted from EFI and doesn’t when booted with the Legacy CSM enabled.
The point of EFI itself was to have a modern codebase for developing system firmware… BIOS of old is literally a bunch of unmaintainable binary blobs. While to the end user it isn’t that big a deal unless your computer suports coreboot… it still means it boots faster than a BIOS could and potentially can have more and better features.
