Can't use L5 after update!

[irvinewade]

@ailonn

After an update few weeks ago, my L5 doesn’t detect the Hardware-Kill-Switches when I turn them on. I suppose the solution describe here could help me

I don’t think it is correct that this solution is applicable for you. The solution described here is for a Librem 5 that effectively can no longer boot i.e. you can’t even login to the phone.

So if you switch off all three Hardware Kill Switches and boot up, do you get the login screen (PIN pad for entering your PIN)? If you get the login screen and you can login then this topic is not for you.

If this topic is not for you then building uuu and building Jumpdrive would be a lengthy digression. Building uuu is not necessary in more recent versions of Ubuntu anyway i.e. not necessary for Ubuntu version at or after 21.04.

[Quarnero]

@ailonn, turn-off every HKS! Now please reread and proceed as described in above posts (here) #174, #175, #176 and:

@MV71

sudo dpkg -i uuu_1.4.77-1_amd64.deb

Step 2, take your Librem 5 battery out and connect Librem 5 per cable to your laptop by holding Volume-key up and inserting its battery back (actually connecting back needed power would mean that currently used battery is already charged to over 50%, at least not empty). New you need to execute: lsusb and ensure you are reading this line:

@MV71

Bus 001 Device 009: ID 1fc9:012b NXP Semiconductors i.MX 8M Dual/8M QuadLite/8M Quad Serial Downloader

Step 3, if you read text, actually output, as above and only then you should proceed and press Enter-key: sudo ./boot-purism-librem5.sh.

Explanation:

@ailonn

uuu (Universal Update Utility) for nxp imx chips – libpureos/1.2.91+0git6b465-0pureos+librem5.2-1-g5e5fee8

is some unknown version to me and it should read like something closer to this (when possible and as initially described in this post):
uuu (Universal Update Utility) for nxp imx chips -- lib1.4.77

Therefore (as not really sure which version you are actually using), and before you proceed with above steps please (re)follow this official guidance:

@mladen

2. Open terminal and run command: mkdir jumpdrive && cd jumpdrive (creates new folder and changes location to it)
3. Download: wget https://github.com/dreemurrs-embedded/Jumpdrive/releases/download/0.8/purism-librem5.tar.xz
4. Unpack: tar -xf purism-librem5.tar.xz

P.S. I’ll check your progress today (but it might happen to be very late).

[ailonn]

Thanks to the time to answer me.

After re-reading this post introduction, I come to the same conclusion so I sent an email to the support.

Building uuu is not necessary in more recent versions of Ubuntu anyway i.e. not necessary for Ubuntu version at or after 21.04.

Yes, on kubuntu I get uuu through apt and on Archlinux through snap.

[ailonn]

Hi ! Thank you very much for your detailed answer !

I already took the time to do the different steps with the correct uuu version through snap or apt and with the battery dance. But the script stays blocked.

My main problem is to have my phone detect the changes on the HKS when this problem is fixed then I will dig in the forum, or I will create a new topic, to fix my problem with uuu and jumpdrive .

I bookmark your answer with your tips on the battery level charge and wait the purism support answer.

Thanks you for your time and the precision of your answer.

[ailonn]

Hello,

I’m back !

The support team ask me to try this protocol to solve my issue.
I tried with your tips @Quarnero : the correct uuu package and the battery with 60% charge. I met the same issue as describe in my first post. L5 light yellow and boot-purism-librem5.sh script block in the state below:

[dos]

Have you tried using a different port? USB 2 one? A different cable? USB-A to C?

[Quarnero]

@irvinewade

If you have a uSD disk inserted then it will advertise two disks, otherwise just the one (the eMMC drive).

@ailonn, as first thought of mine or another conscious approach, as based on @irvinewade post, please remove your microSD (if inserted) temporarily away.

@dos

there’s enough power available for phone to actually run etc.

@dos

so if you don’t see it on your PC you’re pretty much in the dark and figuring out why it’s not working is mostly trail-and-error.

My second thought here is that using shorter/another USB Type C cable will provide more current/power if your PC/laptop USB port (as mentioned in above post) doesn’t provide (through particular USB-C cable) at least 0.5A (just my guess, perhaps ensuring 5.0V/0.6A from currently used USB port is even better) to your Librem 5, therefore please connect your laptop (if perhaps older type) to its original power supply (should help) during usage of here related procedure.

I’d agree with @dos expert advice as positive and encouraging that you’ll get there eventually, that we hope that you’ll get there, that Jumpdrive will mount your Librem 5 eMMC drive soon. Therefore, and in addition, ensure usage of correctly extracted archive and, please, download this one (again and although the very same 0.8 version one), unpack it to another folder, with another name, and try here related procedure again from that new folder.

@ailonn

L5 light yellow

Also, after executing: lsusb | grep 8M, by having constant red LED light on, please do not disconnect (if so) USB-C cable from your PC/laptop. Just press Enter-key after typing: sudo ./boot-purism-librem5.sh.

As well, did you try: ./boot-purism-librem5.sh without sudo? Thanks for your feedback!

[Quarnero]

As still not too late, your System76 laptop description link says: 1 x Thunderbolt™ 4 (please do not use that one at all). Yet, please try here related procedure with this laptop left USB-A (as it provides more power) port (and adequate cable):

As well, here is another post on why not to use Intel® JHL6540 Thunderbolt™3 Controller (as this port provides 15W to bus-powered devices):

@irvinewade

Librem 5 goes into charging mode (LED is red) but does not seem to draw anywhere near the right amount of current - current as reported is all over the place - and appears to tell the host that the Librem 5 is self-powered (rather than bus-powered). I would tentatively blame the Librem 5 for this behaviour i.e. if it wanted to charge from a USB-A 3.0 port then it isn’t saying the right things.

Edit: Confirmation command would be something like: $ lspci | grep -i Thunderbolt.

[N8W]

I appear to have had this same issue, so I am here with a question on my twist. My daily driver is Open Suse, so it was bit of a pain getting uuu working, but I got through all that using snap and actually moving the binary file manually. So I connected fine via jumpdrive by downloading and running the script recommended by mladen et. al. All good - I have the three added drives (phone two and my SD card). However, that’s where we hit my odd twist. In the directory, neither “initrd.img” and “vmlinuz” nor their .bak’s are present:

So… I am guessing my course of action is to copy the two serialized versions to their non-serialized versions and see what happens?

i.e. cp initrd.img-5.16.0-1-librem5 initrd.img AND cp vmlinuz-5.16.0-1-librem5 vmlinuz ?

Then keep going?

[dos]

How does your problem manifest itself exactly? You shouldn’t be able to get hit by the issue described in this topic anymore.

[N8W]

Oh, it’s the same as others had. When the phone tried to boot after an update, it stopped at the encryption login, with no ability to type in the code. That’s why I was trying this fix.

I thought it was curious that it would have been a space issue, since I tried to be diligent about removing old versions when the phone gave me a warning that the space was low. But I thought that maybe one of the same files got corrupted, just by different means? But I wouldn’t know how else to check that.

[guru]

@N8W

So… I am guessing my course of action is to copy the two serialized versions to their non-serialized versions and see what happens?

i.e. cp initrd.img-5.16.0-1-librem5 initrd.img AND cp vmlinuz-5.16.0-1-librem5 vmlinuz ?

The content of my /boot partition looks like this:

purism@pureos:~$ ls -l /boot
total 93624
-rw-r--r-- 1 root root     2328 Apr 23 01:35 boot.scr
-rw-r--r-- 1 root root     2328 Apr 18 11:30 boot.scr.bak
-rw-r--r-- 1 root root   189373 Apr 13 12:53 config-5.16.0-1-librem5
lrwxrwxrwx 1 root root       53 Apr 23 01:35 dtb -> dtbs/5.16.0-1-librem5/freescale/imx8mq-librem5-r4.dtb
lrwxrwxrwx 1 root root       53 Apr 23 01:35 dtb-5.16.0-1-librem5 -> dtbs/5.16.0-1-librem5/freescale/imx8mq-librem5-r4.dtb
drwxr-xr-x 5 root root     1024 Jan 23 02:17 dtbs
drwxr-xr-x 2 root root     1024 Jul 13  2021 grub
-rw-r--r-- 1 root root 65444751 Apr 23 01:35 initrd.img-5.16.0-1-librem5
drwx------ 2 root root    12288 Sep 11  2021 lost+found
-rw-r--r-- 1 root root  4962659 Apr 13 12:53 System.map-5.16.0-1-librem5
-rw-r--r-- 1 root root 24875016 Apr 13 12:53 vmlinuz-5.16.0-1-librem5

i.e. there are no non-serialized versions.

[N8W]

Ok, our boots look exactly the same on that level. I guess they must have changed the need for those files or something?

In the directories:
grub: there is one 1-kb file, “grubenv” that thinks it’s a text file.
dtbs: there are two sub directories of the 5.13.0 and 5.16.0 versions that contain the .dtb files in the freescale sub.

5.16 version directory contains the .dtb and its .bak version, whereas the 5.13 version directory contains only the .bak version.

5.16 version directory files were updated Wed, apparently when i tried to update, with a sad result.

[N8W]

Ok, well, if no one has any better ideas, I guess maybe I’ll just try and revert the couple of files that changed on Wednesday? One is “boot.scr” and the backup looks older. So maybe there’s a chance. The only other ones that look like they updated were the imx8mq-librem5-r4.dtb and the links to it. The problem there is that the backup has the same date and time, so I would suppose if the regular one were updated with a corrupt file, the backup probably was too. It doesn’t make sense to me that the backup would have updated at the same time - doesn’t that take half the point away from having it? So, I guess maybe just the boot one then?

Any other insight before I just start trying things?

Update - changing out boot.scr to the backup did not help. Neither did changing out imx8mq-librem5-r4.dtb. No surprise with the second one, since the files had the same time stamp. Now what? There is a backup 5.13.0 version of the .dtb file, but then that wouldn’t match the versions of initrd.img and the other files, which I suspect would be an issue; and I don’t see where backups would have been created of the other files - initrd.img, etc.

Now what?