Opened 7 weeks ago
Last modified 7 weeks ago
#19219 new bug
On ThinkPad T450s, nightly build hrev58291 works, R1/beta5 does not
Reported by: | bergamot | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | System | Version: | |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
Upon installing Haiku on the target computer (Lenovo T450s, which is x86_64), it will successfully start up when my install media is based around the hrev58291 nightly build which uses gcc 13.2.0, but not so with the latest stable beta. Maybe if I were to start in failsafe graphics-mode or some other adjustment(s) that'd be the right thing to do, but regardless as to whether my install media is based on R1/beta5, or if I upgrade from within the nightly build, starting up on that machine never gets as far as the splash screen lighting up, only the greyed out version.
Attachments (2)
Change History (9)
by , 7 weeks ago
Attachment: | syslogpaste.txt added |
---|
comment:1 by , 7 weeks ago
Keywords: | install startup removed |
---|---|
Platform: | x86-64 → All |
The syslog looks normal.
I'm a bit confused as to what you are saying here. Does the nightly build always work, whether from the live image or installed to the machine, and the beta5 does not? Or do neither work when installed to the machine, and only the nightly works on the install media?
comment:2 by , 7 weeks ago
Does the nightly build always work, whether from the live image or installed to the machine, and the beta5 does not?
Yes, exactly. I'm not sure what it is about the R1/beta5 that impedes the boot process
comment:3 by , 7 weeks ago
There have been multiple fixes to the early boot process since beta5 so it's entirely possible that this is just a bug that was fixed. You can try with an older nightly hrev from around the time beta5 was released and see if this is the case.
comment:4 by , 7 weeks ago
Are you suggesting that hrev58126, commited on September 12th of this year (in other words one day before the release of beta5) would be a more reliable system than hrev58291? I am very confused. I'm not surprised that a more recent build (58291 is more recent than 58126, after all) would be more likely to work. But I'd be willing to give it a shot, all the same.
I'm not asking for the most recent nightly to be committed, asking for a hypothetical beta6, or anything like that, and I know that putting together an OS must be a ton of work for everyone involved. I'm just wondering what I can do to make my install more reliable as well as reporting that this beta which is considered very stable (and probably rightly well touted) doesn't work on this particular machine.
comment:5 by , 7 weeks ago
I'm asking to test with an earlier hrev of the nightly builds to see if they fail the same way as beta5, in order to confirm whether the fixes on the nightlies since beta5 are responsible for things working now, or whether there's some other configuration difference on beta5 that's responsible.
I would test with hrev57937 as that's the hrev that was branched to beta5 (there were many commits after that which were merged into the beta branch before the release, but that was the branch point.)
What is unreliable about hrev58291? I'm still not clear from your descriptions if there are any problems with the nightly build for you.
comment:6 by , 7 weeks ago
Sorry for my lack of clarity, and apologies if I'm testing your/others' patience. I'm not totally sure what's wrong with the nightly I'm using, if there's anything to speak of, although I have gotten "transport" errors (no idea what that means).
I am comparing it to beta5 because I was under the impression that the latter would be a better choice to use.
comment:7 by , 7 weeks ago
What "transport errors" are you getting? Where do they show up?
beta5 is a better choice if it boots on your hardware, but if the recent fixes in the nightlies are necessary to get things to work for you, then obviously it isn't the better choice.
/var/log/syslog paste