After applying the latest updates to my Librem 5 back in July, I can no longer boot my phone. I asked support for help, but haven’t heard back yet, so now I’m asking here to see if anyone has any ideas.
When the phone boots, I’m greeted with the disk decryption screen, as it’s always done. The UI doesn’t respond when I try to type in my password though. I don’t know if it’s the touchscreen itself, or one of the layers of software in between. I’ve also tried using a physical keyboard connected to the USB port, but that doesn’t work either.
Looks like a know old bug software on that date. There is an exercise to resolve it. Lets wait distinguised @FranklyFlawless for instructions for… as FranklyFlawless it more speedy-gonzalez than me to locate files.
I don’t quite follow. Option 1 seems to suggest that the problem can be fixed by reflashing the firmware. Option 2 makes it sound like a hardware issue. @carlosgonz suggested that this was a known software issue, which makes me think that reflashing the device is the route forward. Am I misunderstanding Option 2? Why do you expect that to help? I’m trying to understand the root of the issue.
@FranklyFlawless i talk about the bug that caused not booting after update via apt, so dosowisko shared a hack to troubleshooting that bug. I thing that Jumpdrive was used to chroot to fix the issue via core. So reburn was not needed.
You asked for ideas, so I provided a few off the top of my head. I do not have expectations of whether they will actually help or solve any of your issues.
Using Jumpdrive does not reflash the firmware. (If you did choose to reflash then it makes sense to use Jumpdrive to rescue your personal files before reflashing.)
Still, Jumpdrive is not a bad idea. Using Jumpdrive will establish that your phone is basically functional. So it’s basic troubleshooting.
But also, using Jumpdrive would potentially allow you to revert an update if you are lucky and if you know what you are doing (would probably require that you do get a response from Purism Support).
My actual answer for recommended course of action would be
Restore from backup made before the update.
But that assumes that you do regular backups (which you would use Jumpdrive for i.e. for the backup and for the restore).
Quite a few people seem to have this same mystery problem where it no longer becomes possible to enter the decryption password (hence phone is effectively bricked) and reflashing does resolve the problem. That’s strange to me because I have applied every update as it is released for several years and have never had this problem. In any case, you might want to review existing topics.
If you are super adventurous, a fourth option could be:
Boot Jumpdrive and then actually remove the disk decryption. Then see whether the phone now boots and operates normally. (But of course you then don’t have disk decryption any more and it may be troublesome to put it back. I mean it should be possible but I think the only forum user who tried it had problems doing so. And in any case, without understanding what is actually going on, putting encryption back may just get you back to where you started.)
Thanks for the suggestion. Fortunately, I have backups enabled and they were running regularly, so I’m not particularly worried about re-flashing if it comes to that.
How do I go about restoring from backup though? Or do you mean re-flash and then restore from backup?
I like option 4… I might give that a shot when I have the time. I have plenty of experience maintaining systems with LUKS, so unless there’s anything crazy going on, it should be pretty straightforward to run that test.
Here’s how I do backup: Boot Jumpdrive on phone. Use dd command on host computer to image entire eMMC drive of phone to a disk image file on the host computer (actually then piping through gzip to shrink it down).
In that scenario, restoring is simple: Boot Jumpdrive on phone. Use dd command on host computer to copy disk image file on the host computer back to eMMC drive of phone (actually piping from gunzip to expand it first).
This has happened to me a couple of times. The first time was due to one of my partitions running out of room on an update, even though the main issue causing that problem had been fixed. I just had a different enough odd circumstance. Not worth explaining here.
The next time was more recent. I’m pretty sure a file just got somehow corrupted in the update process. I used the jumpdrive process to replace the newest boot files with the previous version. I tried a couple at a time and eventually I replaced the right one to make it boot.
Although a new fresh flash sometimes feels nice and clean, for some reason I am happier when I can boot up my old dirty partition. Oh, the stories it could tell…
Let me find the old thread and see if there are any good old notes in there that would he helpful.
My L5 has been dead because what happened to the OP happened to me, and I was just pissed that I once again needed to flash the thing. I just don’t have time to constantly wipe the thing just to get it to turn on. After cooling down, and being once again excited about the prospect of a mainline Linux “phone” I’m curious if someone could tell me what the actual jumpdrive version numbers in this command should be:
But to reiterate how this kind of thing is not acceptable in what is supposed to be a consumer grade product I will just say that my only not wanting to waste the phone is why I am here again.