So I had this wonderful bad idea. With Librem 5’s we get to have freedom, and freedom probably also means being free to make the wrong choice.
I took a backup Librem 5 that I was not using a whole lot, and I tried using uuu with an Android for iMX 8M Quad image from the NXP website, and tried to see if I could burn this image onto the Librem 5 using uuu. It was similar to the PureOS flashing tutorials and it gave the Success 1 Failures 0 message at the end of uuu.
But then when I unplugged the Librem 5 from the host computer, now it doesn’t do the thing where holding the power button makes it buzz and show the green light. Instead, it’s just dead. [Laughing at myself when I typed that, to be honest. I kind of deserve this.]
I was curious… I have to go for now… But do we think that imaging it back to PureOS with uuu would work, or is it more likely to be super dead at this point? Curious on opinion in the meantime until I get more free time to try re-imaging back, maybe after work.
Edit:
Sometimes, when the battery was in, the blue light would turn on. And then it would flicker on and off and on off. Is that it burning out its processor? What is that?
Well, I can’t help you to recover from this. But having an Android like Lineage on Librem phones with a dual boot with PureOS would be a very nice thing.
now it doesn’t do the thing where holding the power button makes it buzz and show the green light.
As expected.
You should be able to get into flashing mode and reflash it back to a good image if you didn’t break the hardware, but this isn’t guaranteed. Good luck.
There’s plenty of configurable voltages that can be set to values that other components won’t be happy with, for starters. If you boot with a bootloader and device tree meant for a completely different device, all sorts of bad things could happen.
…and dozens of different ICs connected with each other in a unique configuration, very much unlike the set of ICs used by the board the image you flashed was meant for.
Okay, so, the saga continues. I tried using the Librem 5 flashing script to flash PureOS, but after going through the loading process where the light turns yellow and the laptop lists it as copying over, and then says “Successes 1 Failures 0”, after I removed the cable from the Librem 5 and tried booting it, it didn’t boot or do anything.
I noticed that unlike last night when trying to flash the goober ROM and unlike the PureOS tutorial, when I attach the Librem 5 to the computer while holding Volume Up, now it is flashing green as if trying to boot something and failing, instead of not doing that, prior to uuu stuff beginning. Is that a sign of something we can fix? It’s interesting that that’s the only time I’ve seen it flash green since mucking about with this.
I searched the same official docs you linked for “jumpdrive” and nothing came up. Do you have a link to jumpdrive and what it is and where to get it? My Librem 14 running byzantium says:
$ sudo apt install jumpdrive
[sudo] password for <me>:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package jumpdrive
$ sudo apt search jumpdrive
Sorting... Done
Full Text Search... Done
I really appreciate your help. I was partially skeptical of running something from a github instead of PureOS repo on my Librem 14, but the contents of their shell script was 1 line, to run uuu thing for their bootable thing.
Then, this thing put words and graphics on the Librem 5 screen, even though previously indications were that I had possibly destroyed the Librem 5. So, now it seems that I did not destroy it, at least not totally.
Jumpdrive seems to have mounted and is showing two partitions. One is big with 4 GB and has a /home/purism folder, and the other is 488 MB and has some files in it with librem5 in their name. So, it seems that at least partially, the eMMC was indeed overwritten with PureOS.
But where do I go from there? So, the device itself won’t boot anything but jumpdrive, but we know that uuu did actually overwrite what is on the eMMC at least in some form and to some extent?
(NOTE: The wacky image I tried to flash yesterday had 13+ partitions and is nothing like any of this, so it definitely seems gone.)
When you put your phone in Serial Download mode, your host computer effectively controls what happens on the phone, using uuu.
When you reflash, that is fairly straightforward, the host computer sends the disk image over to the phone and the phone writes the disk image to the eMMC drive.
When you use Jumpdrive, the host computer sends a whole (maybe slightly abridged) kernel over to the phone, for storage in memory, not on the disk, and the phone boots that kernel, and the phone then exposes its eMMC drive (and µSD drive if there’s a card inserted) to the host computer via USB, and you can telnet into the phone, again via USB.
Okay but if the eMMC drive already has PureOS Byzantium for Librem 5, where should I look to understand why the Jumpdrive “maybe slightly abridged” kernel can boot on the Librem 5 but the PureOS Byzantium for all that I can tell does not?
Ah yeah sorry I didn’t say. Along with jumpdrive the telnet was already working, and can ls inside of the telnet console and see files in the jumpdrive mount. I didn’t mount anything there via any manual jumpdive mount command (inside of the L5 itself?) so I was only looking at the eMMC contents from the Librem 14 USB mount, wherein I entered the 123456 luks password based on the assumption that the reason it asked for a password would have been successful eMMC overwrite with PureOS Byzantium for Librem 5 image tonight.
But when I look in the mounted stuff, for example /var/log (inside the mounted LUKS encrypted part) at where I loosely recall system logs might be, everything is last modified in 2023. Definitely seems like it never booted the main eMMC partition.
Unlike the example that you have linked, the boot partition on the eMMC appears to have kernel version 6.2.0-1-librem5 because I got the “stable” image when I ran the flash script.
Aside from that, the example that you linked has a grub folder, but I do not find that same folder on my current boot partition. Would it be worth me imagining this phone with the 6.5 or 6.6 or whatever kernel is current, by way of trying to image onto it the exact contents of what was on it before I messed around with it last night?
Yesterday before mucking about with it, I booted into an SD card and then used dd to try to image the entire eMMC onto an external drive. However, if it cannot boot stable Byzantium default image, I do not know why it would successfully be able to boot something I created with dd last night. Plus I would imagine I probably couldn’t boot that SD card anymore.
