Beta3 on Thinkpad

I seem to have put my Haiku Thinkpad T450s out of business, by upgrading to beta3. It appears to go through the boot OK, but the UI screen doesn’t come up.

The fan comes on, so possibly a tight loop. Runs this way normally, from either hard disk installed via upgrade, or USB from downloaded ISO; both x86_64.

I tried checking all the boot screen options and with logging on screen. At the end, it’s in various places dealing with the packages, often at the end of “active package” inventory and verified that /boot/home/config is consistent. Anyone have an idea what to do to get more clues?

So the installer starts and works but the installed system not?
Is this legacy or uefi?

1 Like

The installer does not start. That would be on the USB copy - I mean, its intended use is to run the installer. It doesn’t finish booting. On the “hard disk”, I have beta3 upgraded via pgkman, with the same problem.

Started UEFI, switched priority to Legacy first for most of my experiments. When I switched back to UEFI while considering your question, now I find that I can boot beta3 - but, curiously, only with the USB ISO plugged in. If I pull the USB drive, it’s back to the old infinite loop. With the USB image, I can boot beta3 on either the SSD hard drive, or the USB image with installer.

So I guess something about the ISO boot loader and its parameters is different from what I have on the hard disk? That doesn’t totally add up - in Legacy I had the same symptoms when booting from the USB - but I don’t really know anything about UEFI/Legacy.

Please read the release notes. The installer doesn’t installs the EFI loader automatically yet, you have to do it manually. It is easy.
Hope it helps.

1 Like

But you can also enable fail-safe video mode / select a specific resolution / enable other diagnostic mode, etc. in the legacy bootloader too, that could also help. Check the user guide / faq / release notes for more info.

1 Like

Yes, I missed the opportunity to partition my disk according to that EFI scheme. (So it isn’t easy, now - I’d need to do some kind of image backup so that I could repartition the disk.)

So prior to upgrading to beta3, I guess I was essentially in Legacy mode - it was set to try both, with UEFI priority but presumably falling back to Legacy. That stopped working, because Legacy doesn’t work with beta3 on this hardware.

But beta3 does work in UEFI, if I can get the boot loader from the USB image.

I think i had a similar issue, tested on my hp elitebook, and lenovo thinkpad, both would show the boot screen, then go to a blank screen
appears to be an intel graphics issue, starting in safemode worked like a charm

Yes, the pretty likely cause is the intel video driver having some regressions. In that case, selecting “failsafe video driver” in the boot menu would get you booted. You can make this setting permanent from the kernel settings file, until the driver is fixed.

1 Like

(@PulkoMandy ) This is probably the DPMI ON before setting mode issue :wink:

I did try failsafe video, but I think that can’t really be the problem - because beta3 runs fine, once I can get through the boot, and surely it’s using the same video driver then.

The boot fails somewhere fairly late in the process and probably involves an infinite loop. The problem seems to be that unlike beta2, beta3 can’t successfully boot on my hardware in “Legacy” mode, only in UEFI, but I don’t have an EFI partition, so I need the USB image to get to the bootloader. It’s weird that UEFI/Legacy would matter that far into the boot, but I know nothing about UEFI. I guess this is well enough characterized that I might as well file a bug report.

The key difference could be that the splash screen will be either handled by VESA or UEFI framebuffer, and they are a bit different. This can have consequences when handing over control of the display to the “native” driver, if that’s in use.

The issue is identified and I think you have a patch for it, did you put it on Gerrit yet?

@PulkoMandy : Ah you mean the patch posted in the ticket? No, I did not do that, I’d need to find out howto first (rookie with that I must confess :slight_smile: )
Can I do this without to much hassle for a beginner? how? any simple pointers?

EDIT:
https://dev.haiku-os.org/attachment/ticket/17163/reverted-55253-plus-status.patch

  • Start from a git branch that’s in sync with the current master branch
  • Apply and commit the patch
  • Use git push to submit it. To create a gerrit change instead of pushing directly to master, you need to push to a special branch called “refs/for/master”. If you have the patch just applied and committed in your working directory, you can do this:
    git push origin HEAD:refs/for/master

Git will tell you that it is a new change, and give you the URL where it has been submitted for review.

If you don’t want to remember this command, you can also set up the git-review tool from git-review — git-review documentation

It needs some configuration, but then the patch submission process becomes even simpler:

    git review

Ah, I see. I can try that hopefully later today (@work currently)… Thank you.

Ok, it’s there: https://review.haiku-os.org/c/haiku/+/4362.
Hope I did it right :slight_smile:

@PulkoMandy: An addition question. Now I did the local commit and push to gerrit: how would I go about working normally again with the now updated sourcetree on my system? Can I just update i.e. the intel driver and commit and push to master without causing trouble because of the gerrit commit and push?

1 Like

You can remove the commit from your local branch and work on something else, if that’s what you mean.

So that’s why you thought the failsafe video option would help? (It doesn’t.)