I flashed a bad image on my Librem 5 and now it doesn’t work. Totally my own fault, described in another thread.
But someone reached out to me in a private message and suggested that I try to write over the boot partition with an updated one, in case this might help. To be clear, this is an L5 which will not boot, and I wrote over the entire eMMC with the flash script that flashes back to PureOS Byzantium at least 3 times.
Is there a way that all of those attempts at flashing – which I can verify with Jumpdrive did change the eMMC contents – would have not re-imaged the boot partition? Or is there another boot / bootloader storage outside of the eMMC that the person messaging me might be thinking of, and that I could somehow independently access?
I’m curious because it sure seems like flashing “the wrong image” on my Librem 5, as software, has destroyed it. And I guess that makes sense that that was always a possibility but I’m mostly a software guy and it’s usually fun to think that we can try a different software on our devices and that if that doesn’t work, we could revert back - like what you would get on an x86 PC with some enthusiast Linux variant.
So I’m hopeful that what the person in the private message sent me is correct that there is some boot sector I need to image that I don’t know about, or maybe a second eMMC or second part of eMMC that I need to access independently.
I am probably totally useless (and possibly worse) but can you somehow connect it to another computer, open a terminal, and somehow use software like Gparted to access the Librem 5 boot partition?
I am writing you this message of thanks from the Librem 5 that is now magically allowed to boot again by doing what you said!
However, I was only able to boot from my non LUKS SD card. The LUKS eMMC recently flashed instance was spinning waiting for cryptsetup password, but not creating the onscreen keyboard during boot to enter that password. Is there another different uboot incantation that enables the onscreen keyboard?
What documentation should I read to learn these things so that I do not burn up your time, good sir? I would not have guessed ucmd mmc 0 0 7 0 on my own, and yet this made a nonbooting device become a booting device - where I can use it to write you this message.
Thanks again and even if you just read this message and laugh, and don’t have time to reply, I hope you have a wonderful day. (I know it often is the way of the world that when people know things, like how you knew the 0 0 7 0, they end up under appreciated and eventually replaced by the less experienced people who don’t know things. So, I really appreciate your time.)
After applying the fix from dos above, I would be inclined to reflash from scratch, given that your phone has spent a lot of time in some really weird states.
I flashed the eMMC with a non-default image. That is to say, before the “saga” I booted to an SD card and used dd to copy the mmcblk off to a big external hard drive.
After it was in the state described above where it could only boot from SD card, I used dd to put back the image from on that external backup drive.
After that, it appeared to boot very normally and let me enter LUKS password and everything. But I wondered if maybe it was running hotter than it used to, or possibly a little slower. Maybe I’m just growing accustomed to the additional Liberty Phone performance; I’m not sure.
Yeah. To be clear, basically I ordered a Librem 5, liked it, ordered a Liberty Phone, and since then only occasionally used the Librem 5. More often frequently I use it as a form of expensive spare battery charger.
So, on “my phone” I have intentionally never even installed Waydroid. Been somewhat lean, although I suppose as time goes on the idea that it would be some untouched secure place of beauty is still questionable. I’ve connected to insecure public WiFi a few times, etc., and recently even added the ppa for Brave Browser without doing a lot of research on the security implications of that, because I was interested whether it would outperform Epiphany and Firefox ESR at 1080p video on Byzantium.
But even when the backup became a backup, and I did all the crazy things with it like installing Waydroid (+Google Play Services and Google Play Store) and disassembling the device and breaking off bits inside (and ordering replacements) and now attempting to run Android… Admittedly when faced with the “it’s probably super dead” reality, I was a bit let down. It was sure a relief to see it run again.
Just to be clear and so people don’t get ideas: booting a GNU/Linux image meant for another i.MX8MQ board would also be a very bad idea:)
Build some AOSP-based distro with Mesa and Purism’s kernel tree, potentially adjusting the kernel config a bit for what Android recommends. Integrating everything to work well is another matter, but if you just want it to boot to GUI it really shouldn’t be hard.
Just created an account for this very problem. My L5 is not booting just after a day I used after receiving it on a long wait and installing updates via official store. It boots via jumpdrive, I can mount eMMC volumes as USB storage - and including SD card. Have tried to get into u-boot command prompt by pressing L5 buttons/laptop keys while it boots via running jumpdrive script; but it never went to u-boot command prompt on L5 screen. I have uuc installed for official reflashing methods and it reflashes L5 fine everytime - I reflashed LUKS and PLAIN distributions - original to latest 5r4 images and done some 20 or so times, reflashing is sucessful everytime but than it just won’t boot!.
(1) How to enter uboot while L5 is not booting normally, only jumpdrive booting works. L5 screen shows some script running and than jumpdrive connection logo appears and volumes are mounted as USB storage in file manager on linux/debian machine. I can unlock encrypted LUKS partion and volumes auto-mount (files can be read/write) in the linux file manager. Can mount boot partition as described on forums and open vim /fstab file to edit. /fstab file matches the volume UUID which I get in linux disk manager. It has /dev/sdb1, /dev/sdb2, boot, rootfs, SWAP and tmpfs - MBR is the boot scheme and vfat is boot partition file system shown.
(2) uuu ums commands, how to issue them to L5 which is unbooted or is booted into/via jumpdrive only? All I have is uuu installed on my debian machine when I treid to reflash once it stopped booting. There is no information available how uuu ums commands can be issued to a device from linux terminal. uuu --help does not list ums.
(3) If I manage to be able to go to uboot console on L5 itself somehow, even than, how can I enter commands on L5 screen without any keyboard working in that mode? Only availabe USB-C port of L5 is already conencted to linux computer so there is no question of using any hub or dock and hubs/docks won’t work in this mode.
(4) I am very much ready to fully wipe and erase eMMC completely and via DD in jumpdrive mode or via linux disk manager, have found extensive guides on another Libre board community forums, very much detailed than what Purism should have in the first place. Can I just DD flash xyz.img to eMMC? Will it work without boot.img? Which is a full disk-level factory restore image in the first place and where is it linked? Guys please provide correct information and guides. Purism Store upddates have bricked my one day old L5 and I am almost spedning my last two days and nights to figure out a proper solution.
I hated Windows style OS and so much fed up with daily drama of delibarate problematic updates etc. and now facing the similar situation of official updates screwing up or destroying a hardware! Scared of updates now.
(5) When you refer serial console, does that mean soldering wires and get an UART cable just to use Picocom? That is too much to ask from average user, even though possible, soldering on to a board is not a very exciting idea for majority users, may be good for factory testers who can have more than one L5 to tinker with.
Just some more ideas I have while during this situation
(1) Can the jumpdrive script itself be used to issue the required MMC PARTCONF 0 0 7 0 command to the non-booting L5? I assume it already issues UMS 0 MMC 0 command to L5 in SDL or FLASH mode to mount all partitions/drives as USB storage. Something like UMS 0 MMC PARTCONF 0 0 7 0 be issued via modified jumdrive script? And if is possible, how to modify/edit the jumpdrive script to issue required u-boot commands including above required to fix the booting problem
(2) Whre is/which is a bit-by-by accurate factory image file for eMMC which can be flashed to a completely erased/zeroed out eMMC of a non-booting phone mounted via jumpdrive, just in case, which can restore it to a factory default out-of-box status as Purism had intended it to be with all the required partitions restored as-is? Current flashing requires at least two images to be flashed to eMMC, one is boot and one is main OS image.
This is not in general necessary. This was necessary for the OP because he adventurously decided to install Android on his phone and Android bricked the phone. Hint: don’t do that.
It might be as well to confirm the version of uuu that you have e.g. with the bogus command uuu --invalid
above was from my fedora machine, but uuu I have used to work with non-booting L5 is from my another debian machine which has uuu as snipped below, looks it is version 4.193
I am ready to plunge to totally reformat and erase the whole eMMC after mounting via jumdrive; if reflashing procedure is able to/will be able to reformat and get it ready to be re-used, something like eMMC has failed and a brand new unformatted eMMC has been just installed into L5.
I will do whatever Purism would do in that same case, i.e. after installing a blank-brand new eMMC into L5 and then making it ready for use.
Or, I assume that each partition on the eMMC can be erased and reformatted via debian disk utility. Can anyone please confirm and advise if this will make L5 reboot again. I will do that for required partition via debian disk utility once mounting via jumdrive.
Can I do that please! My one day used L5 is just mocking at me
How long are you waiting after following the reflashing procedure and rebooting? It is normal to wait a while on the initial boot to encrypt the storage device.
If all you were doing was using the official reflashing scripts and methods, it doesn’t seem likely your eMMC is in a bad state like what the OP was in.
Flashing the Librem 5 with the uuu scripts and Librem 5 images (part of the recommended reflashing script in the official instructions) should handle all of the partitioning on top of installing the OS.
