Discussion:
Thinkpad X13s boot loop after dist-upgrade
(too old to reply)
Lionel Élie Mamane
2023-05-30 11:20:01 UTC
Permalink
I initially successfully installed Debian some time ago on my Thinkpad
X13s using (a previous version of) the linaro instructions at
https://docs.google.com/document/d/1WuxE-42ZeOkKAft5FuUk6C2fonkQ8sqNZ56ZmZ49hGI

This installed kernel 6.0.0-rc3-custom.

Today I decided to upgrade a bit, so I added the OpenSuSE-hosted
linaro sid repo (as per the new version of the instructions...)
deb https://download.opensuse.org/repositories/home:/ndec/Debian_Unstable/
removed the old "people.linaro.org" repo which had been removed, and I
also installed the contents of
https://people.linaro.org/~manivannan.sadhasivam/x13s_upgrade/
which in particular added a slightly different repository
deb https://download.opensuse.org/repositories/isv:/linaro:/sid/Debian_Unstable ./
and added sections non-free non-free-firmware to my debian.org
sources.list line.

I upgraded "the minimum amount of stuff" and rebooted into the 6.2.0
kernel from
https://people.linaro.org/~manivannan.sadhasivam/x13s_upgrade/
it worked.

I then upgraded "everything". Now the system won't boot anymore :-(
not with the 6.2.0 kernel and not with the 6.0.0-rc3-custom kernel.
It goes into grub alright, but after Grub it displays (having removed the
"quiet" parameter from the Linux boot line):

EFI stub: Booting Linux kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...

and then reboots; I get a black screen, then the red Lenovo logo with
"press enter to interrupt normal boot" (I don't press enter) then grub
again.


Anyone has a clue how I can debug this? This is my first EFI machine,
my first upgrade from my now becoming rather ancient amd64
architecture BIOS machines, so I'm a bit clueless as to the exact boot
process.


I admit that on the pure Debian side I'm using mostly testing, having
given bookworm higher priority than sid. But the Linaro repos are at the same
priority than bookworm (not lower priority like sid), so anything in
there should have overridden the pure Debian stuff just has well as if
I had not mucked with apt pinning.

I gave sid's kernel (src:linux-signed) and firmware (src:firmare-free
and src:firmware-nonfree) packages the same priority as bookworm and
linaro, but that should also not have made any trouble as far as I
understand.


Thanks in advance,

Lionel
Lionel Élie Mamane
2023-05-30 12:50:01 UTC
Permalink
Post by Lionel Élie Mamane
I then upgraded "everything". Now the system won't boot anymore :-(
It goes into grub alright, but after Grub it (..) reboots;
Something had changed the "debian" EFI boot option to load directly
grubaa64.efi instead of DtbLoader.efi.

I added another boot option "Debian-LEM" that loads DtbLoader.efi and
I'm now successfully booted into my system using Linaro's kernel
linux-image-6.2.0-aarch64-laptops-02306-g9f9a1903a65e
(I had previously, while trying to debug the problem, chrooted into my
install from the rescue system of the install USB stick from
people.linaro.org, and copied that kernel's dtb file into
/boot/efi/dtb/f249803d-etc-etc.dtb)


Now the questions are:

* what mucked with the boot entry like that (maybe something linked
to efibootmgr and/or some grub automagic)

* how do I avoid that in the future

* how do I get an EFI shell without having to use the install USB
stick
Lionel Élie Mamane
2023-05-30 17:10:01 UTC
Permalink
Post by Lionel Élie Mamane
* how do I get an EFI shell without having to use the install USB
stick
I see that Debian experimental has has en EFI shell in package
efi-shell-aa64, so I have my solution :)

Plus I filed https://bugs.debian.org/1036948 to have it automatically
installed in the EFI partition and show up automatically in grub
Lionel Élie Mamane
2023-05-30 18:20:01 UTC
Permalink
After the upgrade to bookworm/sid, the battery level is not anymore
shown. Trying to read most files in
/sys/class/power_supply/qcom-battmgr-bat/
returns error "No such device"

Downgrading to the previous kernel (the one in the install image) with
its own dtb file does not solve this issue, so it must be "something
else", but I'm not sure what. The "specific" packages that were
removed are:

qrtr, replaced by qrtr-tools from Debian
pd-mapper, replaced by protection-domain-mapper from Debian
firmware-lenovo, replaced by firmware-qcom-soc from Debian

The latter package ships a
/lib/firmware/qcom/sc8280xp/LENOVO21BX/battmgr.jsn
which looks like it would be the necessary firmware for the battery
management to work, but I don't know how to check if it is actually
loaded successfully. A "modinfo qcom_battmgr" doesn't show that it has
declared that it would use that firmware file...

I see on
https://lore.kernel.org/linux-firmware/378be5b0-59e2-cfcf-84b5-***@lenovo.com/T/
that there is supposed to be a symlink from
/usr/lib/firmware/qcom/LENOVO/21BX to ../sc8280cp/LENVO/21BX
but adding that symlink manually doesn't help.

I notice that the qcom-specific rmtfs service fails to start...
It looks for /sys/bus/platform/drivers/qcom-q6v6-mss
doesn't find it. "modprobe qcom_q6v5_mss" creates that directory, but
then rmtfs wants a "remoteproc" directory, doesn't find it.

Loading...