So recently my Librem 5 screen came loose and was starting to fall out and stuff, so I booted into an SD card, used a single command line command to image main storage onto the card, popped the card out and put it in a new Librem 5, booted from SD card in the new device, then wrote over the device main storage with the image captured on the previous device.
Then I rebooted back to normalcy. My files, pictures, documents and everything are perfectly sync’ed. The screen is no longer cracked and falling out, everything feels buttery smooth. No loss, no feeling of moving to a new device. It’s just… the same. No payment to a repair man. No need to read an online guide how to sync and transfer since I used the same terminal commands we would use on a PC.
Android is a trash by comparison. They try to hurt us and say Librem 5’s don’t work, but today because of what I have given up and withstood I am the one who gets to not be hurt.
As an AI language model, Google and its corporate leaders are incapable of any emotion. Any simulation of emotion such as abhorrence would surely be a way of using language to accomplish the established goal, and not an expression of any real feelings in the sense that humans can have them - since machines cannot.
Can you please share in detail how the SD card was prepared and booted from. The copy of main storage to the SD card was perhaps just done with dd if=… of=… bs=8m Also, what you used exactly as if?
Copy SD to main storage: sudo dd bs=10M status=progress of=/dev/mmcblk0 if=./my-liberty-001.img
Regarding the process to flash PureOS to the SD card, it was the same. I used dd with if set to an img of PureOS for Librem 5, and of set to the SD card.
the first two shown commands would be executed on the phone (respectively the original and the replacement) while booted from SD card.
The SD card has to be big enough to hold the disk image of the phone’s main disk, which on the full spec Liberty model would be much more demanding that on the basic model (basic model: 32 GB eMMC drive - so SD card only needs enough space for a bootable install, about 5GB, plus running space, plus the disk image - so a 64 GB card would cover it).
What size SD card did you use?
(There may be merit in capturing the disk image piped through gzip so as to reduce the SD card size requirement, presuming that the source phone’s main disk is not close to full.)
For the process of making the bootable SD card in the first place, it may make more sense to do it on the host computer, presuming that when reflashing the phone originally, the disk image was kept. However, it should be possible to make the bootable SD card on a phone itself provided that the phone’s main disk has sufficient disk space for the downloaded disk image i.e. about 5GB.)
I am using a 1028GB SD card, so that I can dump multiple copies of the unzipped 128GB eMMC drive of the full Liberty model onto the card at a time (and to offer me pseudo-infinite space to store other things). I’m currently sitting at 82GB of eMMC usage after using the larger storage model for about two years.
Is the img you dd’ed to the SD, an image which was prepared as you described above, i.e. dd’ing such img just on to the SD , not as a file, but of=… set to the SD as device /dev/sda?
If you boot the L5 will it automatically boot the SD and not the device /dev/mmcblk0?
Generally speaking .. avoid references to partitions in this context. The images are of the whole disk. Hence if preparing the SD card on a host computer and sda is correct at all then you want /dev/sda rather than/dev/sda1 (or any other partition).
No, booting from SD card is not automatic. You hold “Volume Down” during boot in order to tell the Librem 5 that you want to boot from SD card rather than from the eMMC drive.
Yes. This is how it works for me. This is different from – for example – PinePhone that always boots SD card if available. As a result, whenever I boot the default is the eMMC but I can choose as a user to boot the SD card at any time without opening the device or the trays or anything.
the hw does that, but the bootloader can do anything, which can reside on both storages… see p-boot - PinePhone bootloader for example, it is awesome, but i still didn’t try it, cuz i want to compile it myself, just that shrunk on my todo list…
it could be great if librem 5 would receive support (from anywhere) as this isn’t even packaged or mentioned in wikis (i remember only tow-boot), while it has a bunch of killer features, and only precompiled binaries with some instructions for reproduction are available… i don’t want to rely on it before becoming able to compile it natively, if i remember correctly, then i will need it for updating boot entries, and there is a driver that needs to be compiled to a buggy or1k coprocessor that manages deep sleep, and that’s where i stopped, it is available as a precompiled binary, and maybe i succeded with the rest, or failed cuz this (and 1 more precompiled component) are missing… it wasn’t yesterday… if it would be packaged anywhere, then recompilation would be instantly available… maybe a letter to the right direction could help, but here it is until that day… spread the verb! (i mean not mine, but its author’s…)
so both these gems are fine when it comes to bricking basically any other phone as far as my limited knowledge… maybe there are more like these, but the general solution is to succeed on replacing the bootloader for the 1st try on blackbox hw’s (i dunnow how much variables are involved in that game, as i never even tried that…), and then try to never touch it again X’D now im wondering how they initially flash those phones, or why i never saw phones with known and accessible contact points on their motherboards, as i researched the topic of linux phones (not droid linux) very extensively and for so long time… (while i never even rooted a droid phone in the meantime, as i didn’t have a backup phone in case of bricking… + a bunch of i don’t want to learn the depths of droid garbage, i know linux better than what droid is…)
