Can't use L5 after update!

[Quarnero]

@MV71

I have the Jumpdrive running

This was the very key step we’ve been looking for, very positive side. Great achievement (while using other Linux distro), the one that you are, from now on, familiar with (not hidden for you any more).

@MV71

Please, to avoid mistake, what do you mean ‘right directory’ at this point?

I’ll let myself talk less and attach two very same pictures (from inside of the phone and when mounted with: ./boot-purism-librem5.sh to my laptop, actually through Jumpdrive for the Librem 5 smartphone) showing initrd.img, etc. files you are about to work, through Terminal app, with (but do not use, please, Nautilus or other GUI programs for any purpose now and here other than showing ‘related directory‘, afterwards usable of course for …):

/dev/sdX1 is actually the first partition (on Librem 5 eMMC) with the only one/direct directory (not counting sub-directories that are present there) called /boot. You already found needed two files, therefore like to confirm here, that those are: /boot/initrd.img and /boot/vmlinuz, found them by using either ls -la or ls -lh command (through Terminal).

EDIT:

@Marts

cd /mnt

@MV71, actually those two files are, for our purpose here, by strictly following “my” previous advice(s): initrd.img and vmlinuz found directly under /mnt directory:
cd /mnt
ls -lh
sudo rm initrd.img
sudo rm vmlinuz
sudo mv initrd.img.bak initrd.img
sudo mv vmlinuz.bak vmlinuz
sudo apt remove linux-image-5.13.0-1-librem5
sudo flash-kernel
sudo umount /dev/sdX1

One by one, please, disconnect your Librem 5, remove its BPP-L503 battery and insert it back to power on Librem 5 without any further worries (relax for quite some time, as such bridging to the brand new Linux Kernel is very rare thing that never happened before, at least I never saw one with the long term support Linux distribution, and I do not expect any similar one in future either.) Purism Team mastered this one quite easily, in comparison to what all other tasks they already mastered and that they are actually still mastering … here was about our active involvement … our indeed small involvement (as I wrote here: in comparison). We learned few very useful things hard way confirming that we are in charge of our smartphone … open source software smartphone.

[guru]

Only due to technical interest, could some kind soul shed a bit light on how uuu and jumpdrive work exactly together. I imagine, that uuu copies over the USB from the PC some mini kernel to the L5, which is set by the procedure of the volume button and battery insert in some kind reader mode and then starts the mini kernel in memory, which then offers the partitions of the eMMC as USB devices and starts some TELNET daemon… Something like that must the procedure, or not?

[irvinewade]

@joao.azevedo

If there are no udev rules installed, then the script needs sudo

I don’t know how many more of these failed-update customers we are going to get but wouldn’t it make sense for the instructions in post #14 just to include the sudo ?

Where it is unnecessary, it should be harmless. Where it is necessary, it should avoid a lot of grief for already-flustered customers.

@guru

Only due to technical interest, could some kind soul shed a bit light

Big disclaimers apply as I haven’t looked at any code but:

@guru

which is set by the procedure of the volume button and battery insert in some kind reader mode

The procedure with the volume button puts the Librem 5 in “serial downloader” mode. (lsusb output on the host will be different, as compared with a normally booted Librem 5 that is plugged into a host via USB.)

The procedure with the battery is not usually relevant or necessary but is sometimes needed in obscure cases, according to @‍dos.

In serial downloader mode, commands and data can be sent by a USB-connected host to the Librem 5. That of course needs some client software on the host. That client software is uuu

uuu is capable of many things but one of those things is transferring a bootable image over USB and having the Librem 5 boot it. One such bootable image is “Jumpdrive”.

“Jumpdrive” configures the USB device at the Librem 5 end to advertise one (or two) USB mass storage class devices (disks) and some kind of network device (sorry, details not in front of me). If you have a uSD disk inserted then it will advertise two disks, otherwise just the one (the eMMC drive). Yes, it configures a network interface and starts a telnet daemon.

(Handling of partitions is just standard functionality on the host.)

From having watched the build, for 5 hours , the Jumpdrive kernel is fairly comprehensive. Once you telnet in, you would expect most things to work normally. So you should be able to mount the disk(s) locally - if you didn’t mount them on the host - and wander around the directory tree. However I can’t give an account of what things are missing and what things are included.

[joao.azevedo]

@irvinewade

@joao.azevedo

``

I don’t know how many more of these failed-update customers we are going to get but wouldn’t it make sense for the instructions in post #14 just to include the sudo ?

Where it is unnecessary, it should be harmless. Where it is necessary, it should avoid a lot of grief for already-flustered customers.

That is not something that we are thrilled about, but in the interest of reducing friction in the case of users that are not doing this from a PureOS install, ok, done

[dos]

Pretty much. Booting the phone up while Vol+ button is held puts it into USB download mode, at which point you can load the bootloader from a PC over the USB port. uuu is used to do that (boot u-boot), and also to communicate with that loaded u-boot instance so you can flash things or load them into memory and boot from there. That’s what Jumpdrive’s uuu script does - it loads u-boot, then uses it to load a kernel and initramfs into RAM and tells it to boot it from there.

Once Jumpdrive boots (which is pretty much just Linux with a small initramfs that contains Busybox and bunch of scripts), it displays the splash screen, exports eMMC and SD card over USB as mass storage devices, sets up serial console and Ethernet (also over USB) and runs a telnet daemon.

Technically, you don’t need to do the battery dance, but the instructions tell you to do so because it increases the chances of it working in some edge cases, like battery being flat, or SoC being stuck in some weird state. This helps because of the LED feedback you get when there’s no battery in - so you can match the LED output you see with the instructions and know that things are going well, there’s enough power available for phone to actually run etc. Without that, there’s no indication of progress, as the only feedback USB download mode gives that informs you it actually booted into USB download can only be seen over USB, 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. With these slightly more annoying instructions, we can at least weed some common failure cases out early (that said, I never take the battery out to put my phone into flashing mode - once you’re familiar with the device enough to recognize which state it’s in by yourself there’s not much reason to do so)

[ailonn]

Hi,
Excuse me about my English, it’s not my best skill.

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, so I try to access to my L5 through jumpdrive but I’m stuck.

I am on Kubuntu 20.04, I try the process on an Archlinux and a Kubuntu 21.10, every time I reach this state :

ailonn@ailonn-Oryx-Pro:~/librem5/jumpdrive » sudo ./boot-purism-librem5.sh
[sudo] Mot de passe de ailonn :
uuu (Universal Update Utility) for nxp imx chips – libpureos/1.2.91+0git6b465-0pureos+librem5.2-1-g5e5fee8

Success 0 Failure 0
3:1 3/ 3 [=================100%=================] SDPV: jump

The script never stop, the screen is black and the litght is kind of yellow. In this screenshot I build uuu with the instructions from the wiki.

Thanks you to have take the time to read this.

Someone has some tips to help me please ?
I’m available to any comments.

[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?