Can you please give https://haiku.nz/files/r1b3/haiku_loader.efi a try.
This is a WIP patch that may resolve this issue.
Can you please give https://haiku.nz/files/r1b3/haiku_loader.efi a try.
This is a WIP patch that may resolve this issue.
My desktop actually sees this issue as well.
I was able to reproduce this issue locally within QEMU with the efi bios after installing to disk.
This updated EFI loader does indeed solve the issue for me.
Iâve fast-tracked hrev55216 into master since we are getting close to R1/beta3 (few weeks) and want plenty of testing time in the nightlies.
We can weigh + discuss ideal EFI / bootloader designs later after R1/beta3
Thanks, it boots!
But⌠loading screen is broken:
Itâs not broken, itâs not an official release boot loader.
The way Haiku does the loading screen, it only updates each icon, not the whole image. The official boot splash and the development boot splash have the row of icons offset, resulting in this appearance. Installing the official boot loader (once patch is merged) will provide the initial boot splash which will have the right row offset.
Ok, thanks very much.
Now I sill have the Wifi that doesnât connect automatically at boot. I have to connect manually every time (/dev/net/atheroswifi/0).
Sound not working even with OpenSound. More tests to do.
Webcam still not recognized.
Everything else working well.
successfully upgraded from b2 to b3 via pkgman on asus eeepc 1201T
Well I spent some time tonight working through various safe mode options on a slightly older nightly, until I finally got it to boot. Then I whittled them down more and more until it wouldnât - checked the same on TC1 and ended up with the same final result:
I can boot only if I check âIgnore memory beyond 4 GiBâ
Anything else I can do from here to provide some useful input as to why that may be? Iâve got 4x8GB 3000MHz sticks.
From personal experience I had this problem only when doing BIOS boot (after I upgraded my memory and became bigger than 4Gb). Changing to EFI boot resolved it. I donât know if you have that option.
While this may not be an issue for the RC I found something strange, got 2 laptops with AMD CPUâs, only way I can run them is disabling SMP in the bootmenu, ticket created at: https://dev.haiku-os.org/ticket/17053
TC2 / RC0 (not sure which just yet) should have the EFI fix and the webkit2 api changes included.
I have a copy of the webkit2 WebPositive on my system⌠it definitely runs a lot faster. Great job @pulkomandy and the WebPositive / webkit team!
New bugs are likely, but transitioning to WebKitâs new API (and the Haikuâs new network API) are some great things to get included in R1/beta3
Webkit2 for B3? I thought it was going to just be up to date webkit (1)?
As I understand it, weâre moving to the new / current webkit API from a legacy webkit API.
Benefits are mostly around being more multi-threaded (thus better performance). However, the new API also means our chances of getting our webkit port upstream are a lot higher.
For those not in the know, webkit is a massive and fast moving project (the source code is > 1GiB compressed). It takes a lot of effort to just re-base our changes on master⌠let alone get any improvements done.
I am running EFI already unfortunately. May try with 16GB installed tonight just to see if that makes a difference. Not sure why it would, but Iâm pretty sure this system used to boot without me choosing that option.
No we arenât.
Haikuwebkit 1.8.1 still uses the webkitlegacy api. There is a big chunk of work still needed before we can switch to webkit2, currently webkit2 does not compile at all for us.
Here are some noteworthy things that are actually in the port though:
This is all userfacing stuff i remember on the top of my head, webpositive also enjoyed severall improvements since beta2.
@kallisti5 Whilst it has been a couple of days since this was first announced, it might be a good idea to publish a news item on the website to get more people to test the RC.
This is also incorrect (in addition to what nephele already mentionned).
There is no requirement to use a particular API to upstream our changes. Whatâs needed is for someone to look at our changes, split them in nice small commits, and submit them to WebKitâs bugzilla for review. This will require adding tests for any changes to the core of WebKit, writing changelogs, making sure the code follows their coding guidelines (indentation, variables naming, âŚ), and handling comments from WebKit reviewers. At some point we will also need to provide a buildbot builder so they can easily check if their changes are breaking the Haiku port. We will probably also need to do more serious work on getting the test suite running reliably and in a reasonable time (not the 12+ hours it takes currently) so the bot can run the tests.
This is a lot of work, and the reason I have not been doing it is that I already spend a lot of time just keeping our webkit port up to date by merging changes from upstream. I simply donât have enough time to handle both things.
I have enough people testing for the moment The idea of the test candidate images is to find showstopper bugs. The handful of testers we have at the moment is more than enough. We donât want a wide audience using the test candidate images as âR1/beta3â
Good day,
Would it be possible for the installer just install the files related to the selected language? I mean, if I select to install everything in English, I would want to only end up having english files, not those in other languages.
This seems to happen only with the Betas, not with the Nightlies.
Regards,
RR
Thatâs actually a really good idea! We already have language selection on the installer window. We could add a check box to âonly install packages relevant for the selected languageâ
You should open an enhancement on https://dev.haiku-os.org
Yeah itâs what I tell to me everytime I update the system: 80% of the list of updates are user manuals in every languages.