I do not expect that here related issue exists with:
As already explained here:
Therefore I’m just trying to help to @LinuxNoob888 to come out as of his current situation, while working on how to avoid this to happen again isn’t of much help in this thread, not now (although this situation could have been avoided as @guru kindly warned earlier within this Forum).
I am suffering the same problem on my L5…after the PureOS store update, the phone boots to the encryption screen and then is unresponsive to any touchscreen input.
I’ve tried removing the battery, waiting five minutes and then re-inserting the battery, but the results are the same.
While I consider myself a well-above-average technical person with personal computers and have some experience with various Linux distributions, I now find myself with a device I cannot use until (I suppose) I re-flash the OS to the phone and wipe it. It goes without saying that a user should NOT have to perform such an operation on their device, and that the process of updating your device should NOT result in a device that is unusable.
What I and LinuxNoob888 now need is a step-by-step document that tells us what to do to re-flash the phone…a document that assume NOTHING and tells us everything we need to know.
Any takers?
I am experiencing exactly the same problem. I’m a beginner so besides knowing how I can start using the Librem5 again, I need to know how I can retrieve all the data I have saved on the memory card so I can find all my phone numbers and appointments in my calendar.
Hi Kyle, I have to say that is BS.
Support do NOT know what is going on, and after biting my tongue for a long time I have totally lost faith in Purism. I was not going to mention how long it actually took for us users to finally get our Librem 5’s and now to give an update through the PureOS store that has now bricked our phones.
No one is support is giving a definitive answer to solve this issue.
At this stage the advice I am getting is to re-flash the device! I mean WTF? seriously?
That is what I expect from the PinePhone, not Purism and the Librem 5.
Plus I’d like to know what kind of guarantee do we have that this won’t happen again, on the next update or one after that?
So thanks for the brick guys, I guess I have a new paper weight.
What is BS? Every Linux Kernel is new beginning, but the linux-image-5.16.0-1-librem5 is the LTS or simply the great one (currently as 5.16.3pureos1), IMHO.
Had the issue like 12h ago - librem5 is bricked after update, issue fits the description provided here.
The initial post is more than 48h ago.
Understanding of the problem seems to have existed before the initial post.
Why didn’t Purism stop (kernel-) updates until the issue is resolved to deliver the resolution as the first update to make sure that not more customers are affected?
If not already happened: Stop updates, please, until the next update ships the resolution of this fatal error first. @jeremiah, @joao.azevedo?
Instead of heaving everybody strucken by this error contact support it would be nice to have that information on the wiki.
Support didn’t have resolution steps to begin with when the problem first surfaced. They aren’t all-knowing and can’t know the resolution to every problem when it first surfaces. Instead they (like anyone doing troubleshooting) work the issue, and work with other folks at Purism to figure out the best way to resolve it. In doing that, they first advised reflashing as a simple (if destructive) way to definitely get the phone back to normal (it also has the side benefit of increasing the size of /boot to my understanding). We now have a universal set of steps we are advising people to perform who run into this issue. Early on, yes, reflashing probably seemed like the easiest way to get someone back to a functioning phone, but now we have a better process in place.
We have been working to halt the kernel update, however the problem to my understanding isn’t universal and isn’t within the kernel update itself (ie it’s not a kernel bug), it happens if you happen to have too many past kernels taking up space in /boot.
Sure, and if you want we can post in this topic too, although I’d still prefer people work with support to perform the steps in case they have questions or run into any issues along the way.
Insert the USB-c cable: (red light blinks, no green light)
Reinsert the battery: (red light is constantly on, the script will continue)
Release volume-up
To confirm that the device is in uuu mode, in the terminal run the command lsusb and search the following for an entry like: 001 Device 106: ID 1fc9:012b NXP Semiconductors i.MX 8M Dual/8M QuadLite/8M Quad Serial Downloader
Run the script: sudo ./boot-purism-librem5.sh
Once it is run the L5 will show up as an external drive
There will be a 465 MiB drive and a 28.7 GiB drive: open the 465 MiB one
Delete “initrd.img” and “vmlinuz”
Rename “initrd.img.bak” to “initrd.img”, rename “vmlinuz.bak” to “vmlinuz”
At that point you should be able to unmount the external drive and reboot normally
Once you get the device booted you should clean up the failed parts, so run these commands in terminal, one by one:
My Librem 5 no longer had the wifi and bluetooth icon active after the update. So I rebooted and I could no longer start the Librem 5. Then I followed the instructions above, but after step 5 "Run the script:“ ./boot-purism-librem5.sh “” on the Debian PC it did not appear the Librem 5, here is from the terminal:
$ ./boot-purism-librem5.sh
./boot-purism-librem5.sh: 3: ./boot-purism-librem5.sh: uuu: not found
I mean I DON’T see a hard drive. My Librem 5 no longer had the wifi and bluetooth icon active after the update. So I rebooted and I could no longer start the Librem 5. Then I followed the instructions above, but after step 5 "Run the script:“ ./boot-purism-librem5.sh “” on the Debian PC it did not appear the Librem 5, here is from the terminal:
$ ./boot-purism-librem5.sh
./boot-purism-librem5.sh: 3: ./boot-purism-librem5.sh: uuu: not found
I mean I DON’T see a hard drive. So I can’t complete the procedure. I plugged the USB-c cable into the Librem and the other end into the USB of the PC, is that correct?
After installing uuu, here’s what happened.
jumpdrive# ./boot-purism-librem5.sh
uuu (Universal Update Utility) for nxp imx chips – lib1.4.77
Success 1 Failure 0
2:1 3/ 3 [=================100%=================] SDPV: jump
3:1 10/10 [Done ] FB: Done
No device on the PC, but on the Librem 5 the image of the smartphone profile with the word error in red. And on the bottom: “/dev/mmcblk0 could not be opened, possible eMMc defect”.
So I unplugged the USB cable and magically the Librem 5 came back on and I was able to log in again. Now I will go to the boot directory and continue with the deletion and renaming. To turn the librem back on I have to use volume-up.
If you are thinking of “5.13.0-1-librem5” as in the command “sudo apt remove 5.13.0-1-librem5” suggested by @mladen above, then I think it is supposed to be a package name, but I suspect that @mladen means “linux-image-5.13.0-1-librem5”, so my guess is that the command should be as follows:
sudo apt remove linux-image-5.13.0-1-librem5
You can use the “apt list” command to list available packages, for example like this to see installed kernels:
apt list | grep linux-image | grep installed
which should give a list of installed linux-image-* packages with different version numbers, then you can compare that to the output from “uname -a” to figure out which one of them is currently used.
Removing kernels can be fun but don’t get too carried away, it’s probably wise to keep at least one.
I did try to follow the procedure on my desktop (PopOS) just for testing purposes but I couldn’t do: ./boot-purism-librem5.sh
I had an error: Failure open usb device,Try sudo uuu
To make it work without sudo I had to add some udev rules:
SUBSYSTEMS==“usb”, ATTRS{idVendor}==“1209”, ATTRS{idProduct}==“4291”, MODE=“0660”, GROUP=“plugdev”
SUBSYSTEMS==“usb”, ATTRS{idVendor}==“0525”, ATTRS{idProduct}==“a4a5”, MODE=“0660”, GROUP=“plugdev”
SUBSYSTEMS==“usb”, ATTRS{idVendor}==“0525”, ATTRS{idProduct}==“b4a4”, MODE=“0660”, GROUP=“plugdev”
SUBSYSTEMS==“usb”, ATTRS{idVendor}==“1fc9”, ATTRS{idProduct}==“012b”, MODE=“0660”, GROUP=“plugdev”
Add my user to the plugdev group and reload udev: sudo udevadm control --reload-rules && sudo udevadm trigger