Trying to revisit the Librem 5. I have a friend who might be willing to lend me his sim card with another carrier; maybe the phone will actually make a call then.
Unfortunately I cannot unlock the phone; I must have set the PIN at some point to something other than the default (I can get past the decryption prompt with the default).
So I am trying to reflash the thing. There’s apparently no quick simple hardware reset on these phones.
First off the description here: Reflashing the Phone says the light should stay solid red, but the actual script indicates red+green (yellow). I’ve seen both, as well as green, when the phone “ought” to be flashing. (It’s red on this attempt.)
How long does this take, by the way? I’m getting the impression it should take just a few seconds, but is that true? Should I wait overnight? A week? Nothing says anything about it.
sudo uuu -lsusb only shows a device for split second, right after the phone mounts to the computer and you feel it vibrate. After that it’s blank. lsusb by itself shows a couple of USB hubs and nothing else.
It seems as if it’s finding the device and immediately kicking it out and refusing to flash it (without doing me the courtesy of saying so).
One other thing that might matter is I am doing this with a virtual machine on Qubes…so one additional step in the process for me is attaching the device to the VM. All things I have discussed so far have been in terminals on that VM.
Turns out the PureOS image worked…eventually. I couldn’t get it to boot properly at all on my desktop (a NUC 11 normally running qubes; the system I was trying to use last night). Today I was able to boot the Librem13 with it, and juggle thumdrives and usb mouse to get the files I downloaded at great pain earlier this week, onto the PureOS liveboot filesystem. After that, following the instructions I linked above worked (other than having to install git…no big deal!).
So I now have a lobotomized phone I can get into. I might try getting it to make a call even with my current sim card on the theory that a software bug might have been fixed. My keyboard yaml files (that at least some people here like), I will have to transfer from here onto the phone. I don’t think I lost anything else of value.
BTW the light behavior was totally different…at the point where I should get a flashing red, I was getting green alternating with yellow (i.e., green always on, red flashing) and the system vibrated every time it flashed. I proceeded anyway and it worked.
Thanks for the advice! (And yes maybe I’ll finally do the Librem 13…I hope that is non-destructive; reinstalling Qubes 4.2 again would be a pain.)
And typically that means … for an x86_64 computer.
Reportedly you can reflash one Librem 5 from another but I have certainly not tried that.
If you don’t use PureOS on your host computer then Ubuntu works fine too. I have done multiple exercises with the Librem 5 using uuu from Ubuntu without a problem. So you can live boot Ubuntu instead if that works better for you.
For what it’s worth (too late?), there are options in the flash script to download without flashing and to flash without downloading. That is, you can split the process in half - and hence if you tried once and it didn’t work, you don’t have to download the flash image again.
Again, this may be too late but … yes, that is the correct USB id for when you have successfully put the Librem 5 in “serial download mode”, ready to use uuu
I prefer just to use lsusb and then you should see something like:
... ID 1fc9:012b NXP Semiconductors i.MX 8M Dual/8M QuadLite/8M Quad Serial Downloader
if you did the Vulcan death grip correctly on the Librem 5.
Our replies must have crossed. I actually was successful after a bit of a donkey derby of switching machines and juggling thumbdrives (see above).
I had to try multiple times to download that image, and finally discovered the stupid thing was set to give up after ten interruptions. In discovering that (and how to tell it not to give up just because my connection is erratic) I noticed the other parameters. I actually manually saved the files before I finished the last run of the script that successfully downloaded…So even though they got wiped when I quit that attempt, I had copies.
The problem was, of course, the copies were on the system I was NOT going to boot because I was going to use the PureOS image. But I realized (after I posted) that of course I can copy them to another thumb drive before booting into PureOS! There are just enough thumbdrive (USB-A) ports on a Librem13 to let me boot off one thumbdrive and mount another so I can get to the files (though I did copy them so I could use my USB mouse). I had to use a USB-C to USB-C cable to connect to the phone, fortunately even though the instructions specify an A to C cable, that doesn’t seem to actually matter (they may have been assuming computers likley wouldn’t have USB-C on them).
Glad to hear that Ubuntu usually works. I can now attest that a Debian 12 virtual machine running in Qubes OS will not work! (And I also know that my desktop won’t boot in PureOS, fortunately my Librem13 saved the day.)
I think the problem is at the Purism end (although your end may be erratic too). It is suggested to use --stable on the download script.
If having problems, invoke the script with the argument --help to get help about the available arguments e.g. to control how many interruptions it will tolerate in the download and e.g. to separate the download from the flash.
That will reveal the argument --download-attempts and a value of 0 will ensure an infinite number of attempts or a value much higher than 10 will make it try longer.
You obviously have discovered all this but someone else having difficulty figuring out reflashing may read this topic in the future.
That’s where Ubuntu comes in handy, as it will boot on a wider variety of hardware.
As for enjoying the Librem5, I never got it to make a call and I received it well over a year ago. Support asked for log files which I sent them, they asked me to do something different and for the log files from that, which I sent them, and I never heard from them again. It was fun playing with the on screen keyboard and 2048, but cost way too much money for that. It’s basically a $2K paperweight.
This is simply my attempt to try something else…I thought of a way to test on a different carrier (in case it’s actually the carrier that has been the problem). But in order to do that I had to unlock the phone.
If having problems with carrier then best to mention what country you are in and what carrier you are using. That might save some messing around.
If you know the LUKS disk decryption passphrase but you don’t know the login PIN then there is no absolute need to reflash. I mean a reflash probably makes sense here anyway if the phone has been gathering dust for a while and has never been used but you can fix the login PIN just by booting Jumpdrive and then changing the password for the purism user (with care of course).
Fair enough. It’s T-mobil in the United States. The very first thing support did was mail me a different modem…that new modem being the one I was using when I went through the inconclusive exchange of logfiles.
(I wasn’t expecting to debug my phone on this thread, just to get it accessible as the first step to revisiting by experimenting with a different carrier.)
This is good to know for the future, thank you. (And hopefully others will see it too.)
However, it’s already done. I lost nothing of value, because the keyboard work I did was actually posted to a different thread here (I copied it to my desktop computer from my forum post so I can put it back on the phone). Only in the event that I made some modification I never posted, have I lost anything.