Unable to boot

MrT10001

Hi all, worked perfectly for me. Yeah, it boots into scaled mode and not desktop. I did charge it up to 90% and unplugged the power cable. I have found with this tablet and a lot of other devices is to be patient on reboots - it can take some time.

muskist

@luksus said in Unable to boot:

In this case, take it out / pull the cable, try to turn it off with long press on power button and try a restart.

Doesn't work. Only "Lenovo" splash screen.

If this does not help, boot into fastboot, connect to pc and type in terminal: fastboot continue.

Doesn't work either. Says

$ fastboot continue
Resuming boot                                      OKAY [  0.006s]
Finished. Total time: 0.006s

but "Lenovo" splash screen remains.

If that is still not enough, disconnect and turn it off again.
Then boot into recovery and from there hit reboot again.

Same result.

Recovery lets me view a file named /cache/ubuntu_updater.log. Shows an number of error messages. Is this of interest?

Luksus

@muskist yes sure, please show the logs.

muskist

@luksus
Will do later. Will have to copy by hand.

muskist

@luksus

Hope it's readable.

UBports Recovery -> View logs -> /cache/ubuntu_updater.log

Luksus

@muskist hm, looks like there was an rc update, but I did not know that a new rc was already released.

I think your best option would be, trying to reinstall using the ubports installer and choosing the dev channel and bootstrap option.

dtarrant

@luksus
Just upgraded my TB-X605F on devel channel and all went smoothly.
Re-booted without a hitch.

fhendrikx

@keneda Thanks.. I've gone through UBports installer and it finished the update, and is now booting again.

Keneda

@fhendrikx
Wich channel ?

Lakotaubp

Not 100% sure this is for this issue but seems to be. From Alfred in Q&A group

"Same happened to the JingPad. The problem seems to stem from the fact that GSI ports overlay device-specific changes to the rootfs in a horrible way compared to traditional ports. GSIs do that at install-time of the update, meaning the rootfs-tarball can trump the device-tarball's contents.

Traditional ports on the other hand overlay changes at runtime, on the fly during boot"

fhendrikx

@keneda It's on RC

muskist

Succeeded installing rc using ubports installer.

Only one problem when adb didn't see the device after booting to recovery. Worked out at the second try.

Improvements:

Lomiri starting into staged mode
Immediately switching portrait/landscape mode when rotating the device. Was reacting kind of sluggish before
Display going dark immediately after pushing power button as opposed to before when it took about 5 seconds

Thanks @luksus!

Luksus

@lakotaubp said in Unable to boot:

The problem seems to stem from the fact that GSI ports overlay device-specific changes to the rootfs in a horrible way compared to traditional ports. GSIs do that at install-time of the update, meaning the rootfs-tarball can trump the device-tarball's contents.

But for me, that doesn't explain, why it works with the ubports-installer. It is actually doing the same. Except of, if the OTA was an incremental update, then something may be corrupted during the setup.
And there were no issues for the FP3, in this regard. So I doubt, that the GSI method was the root cause here.

I believe the X605 is very sensitive about touching the system-partition/rootfs.
For example, if you make the rootfs writable for changing some overlays or installing something through apt and you forget to mount it read-only again before rebooting, it will be stuck at bootlogo too, in most cases. No idea, whats happening there.

Lakotaubp

@luksus Maybe updates are landing on top of the existing system and not merging correctly, where as the installer reinstalls everything not just the updated files so all works. Just a thought.

Luksus

@lakotaubp Yes, that is what I meant by "incremental".
But I don't believe that this is the case for the first RC update for about a month.

arubislander

@luksus said in Unable to boot:

@lakotaubp Yes, that is what I meant by "incremental".
But I don't believe that this is the case for the first RC update for about a month.

It could well be incremental still, since it is only next one in number since the previous one.

I don't think the amount of time between updates matters, only the amount of updates skipped.

Luksus

@arubislander I think it matters, how much packages have changed.

arubislander

@luksus that is another possibility