We can disable some of these checks, but it could lead to more dangerous problems (memory and eventually filesystem corruption) later on.
So it’s safer to just crash hard and reboot in a clean state, however annoying. And, we are interested in getting a bugreport for these things (preferrably from a nightly, as they include more debugging information…)
That is good news.
Personally I am waiting for a bit longer until the real “official” .iso is out
there rather than the beta1 (my tinker days I am gone; I am no longer
a 20-years old curious person, sadly enough; and reallife also requires
of me that things have to work) - but I have a spare computer here and
I’d like to put Haiku on it eventually.
Hopefully any bugs and showstoppers will be ironed out in the coming
months! My main three prerequisites are (a) works for common tasks
on real hardware without crashes (b) I have to get the programming
language ruby working on it (no idea how easy that is but I will find
out eventually) © internet connection must work somehow, either
via ethernet cable (I got a spare one here); or even better in
addition to that via WLAN too on a laptop (but the latter is not so
vital, as long as ethernet works fine). Reason for © is mostly that
I can search for help and problems online, but I can not do so when
the internet connection does not work. © is not the most important
part since I can use Linux to resolve problems too (my internect
connect to my local PCs works on linux fine), but it is more a convenience
thing if this would work on a fresh Haiku install too. I mention this
because it did NOT work on ReactOS out of the box and I gave up
precisely because I was too lazy to try to fix that. On Linux I typically
just run dhcpcd and things work past that time - no idea how to fix
this on ReactOS, and no either how to do so on Haiku IF I were to
have a connection-related problem.
Keep the good spirits up! I am sure there may be an influx of new folks
when Haiku works smoothly on “the real thing”.
HP Zbook Gen 1 - Haiku OS 64 bit installed without a problem.
I have a T420 - what’s your guess as to whether it’s 100% supported?
It should be more or less supported according to this http://aspeers.blogspot.com/2012/06/test-notebook-lenovo-thinkpad-t420.html. Please mind it was tested on really old Haiku rev thougth.
OK. Fun times begin!
Sorry, just another question: can one make a Live-CD kind of thing with R1 Beta?
So the installation CD works as a Live CD?
It says so at Get Haiku! | Haiku Project
Fun fact, UEFI boot only works when you dd it to a USB stick. UEFI doesn’t work when you burn the ISO to a cd.
Web+ is still crashy as all get out but qupzilla rocks.
I have a Sager notebook and the only thing the x64 release does on boot is draw some colored retangles on the upper left corner of the screen then black out. This machine has a GTX 950M. No hope for my computer?
EDIT: I removed the HDMI cable from the port and I get the Haiku loading splash screen, but when it gets to launch it loses image again. How come? Any fix/hack I can apply or am I out of luck?
Probably the nvidia accelerant is broken there you can hold shift while booting to get to the debug menu and black list it or try failsafe video from there then continue booting.
Also you can enable logging to screen and siable paging to print out the syslog during boot it could be another device causing a hang.
Probably have to blacklist your graphics driver. To test whether this is the case and see if you can reach the desktop:
This should enable you to see if only the graphics driver is the problem.
I think the minimum requirements haven’t been tested. I tried multiple times to start and install Haiku (32-bit) with 256MB RAM, but it’s just not enough.
Even 384 MB RAM are not enough:
By the way, what’s with that hotmail.com? 
I did that and I managed to get through. Working well with software graphics, I installed the bootloader and the OS on an empty partition to play around.
I have no idea how to blacklist the driver, though…
You can configure Haiku to always boot using the fail-safe video driver by enabling ‘fail_safe_video_mode’ in ~/config/settings/kernel/drivers/kernel
For blacklisting:
https://www.haiku-os.org/guides/daily-tasks/blacklist-packages/
Was your boot device read-only? I seem to recall that not having any possibility for virtual memory when RAM is small… is a problem.
There are very low chances that someone does a fresh install and Haiku already has a swapfile available somewhere on the drive, so it can work with virtual memory. But my screenshots pretty much indicate the real problem: “Out of memory” in different stages of the install, so the data could be written.
I womder what is causing the increase in required ram… Does having all the packages activated use more ram…so could the installer stage just activate fewer?