Call me old-fashioned but I always just use dd (or dd piped through gzip when that is appropriate).
I would always just dd the whole drive (input is /dev/sdx) rather than a specific partition (input is /dev/sdxn) where ‘x’ and ‘n’ are replaced appropriately.
Obviously whenever using dd, make 100% definitely absolutely sure that you are using the correct input and the correct output. This is not as important when the output is to a file rather than to a device.
Also, before starting to make the image, make sure that file systems on the input device are not mounted. (Since they might automount, this is something to check.)
Off the top of my head… The disc and partition images made via Disks start by first allocating the needed file, which is about 31Gigs (it’s not just the space that the system files take on L5, it’s the whole empty space too), so you need at least 32Gigs of empty. And if your SD card is formatted to old FAT, it can not handle file size more than 4Gigs, if my memory serves.
Good point. On FAT32 the size of any one file is limited to 232 − 1 bytes i.e. 4 GiB (so imaging the eMMC drive directly with dd is never going to work but dd piped through gzipmight work or might fail after an annoyingly long time).
Unless disk space is tight, I would just image to a file on the main drive, rather than imaging to a file on an SD card.
The SD card could be reformatted, if currently empty, to ext4 or if interoperability is important, to exfat.
OF COURSE!!! I completely forgotten about that. I’ve just changed the partition of my SD card from Fat32 to Ext4 and now it’s copying an .img of my eMMC drive right into my SD card.
Thank you all so much for your kind help. I only wish that I could give you more than my gratitude. If I ever get my Librem5 printed cases of the ground I’ll definitely send you guys a copy @irvinewade@JR-Fi (although, the 3D printed files will be available for free for everyone)
Also: writing this into a how-to to the community wiki, as an option for backing up, would be nice. Just so that the info doesn’t disappear into the forum.
jumpdrive i noticed is a little finicky and often fails to put the phone in the right jumpdrive mode, i typically have to try 2-3 times before it gets it right into proper flash mode (on the screen it will say failed in those instances), thats probably because it is still unstable.
I was looking at lock screen settings, and there is a switch for preventing USB drives to be used. I couldn’t test what effect that would have to Jumpdrive (if any), because it keep throwing authorisation popups - too annoying to use. Glitch or unfinished feature? Could it / should it prevent use of Jumpdrive?
The last stable Jumpdrive release still has a very old kernel that occasionally failed to initialize the eMMC. It has been updated upstream to use a newer kernel long time ago, but there was no release made since.
Today March 9th 2023 i was trying out jumpdrive again with my Librem 5 and i am getting an error:
`$ bash boot-purism-librem5.sh
uuu (Universal Update Utility) for nxp imx chips – lib1.4.193
Success 0 Failure 1
9:2 1/ 0 [Failure open usb device,Try sudo uuu ] `
As soon as i plug the phone into the USB port, using the volume up button, with phone off and battery removed. uuu is installed on my desktop. uuu v1.4.193 installed, and using the CI artifact referenced in this blog. The failure states it cannot open usb device… hmmm.
The L5 is running fine i just wanted to create a backup .img.
Okay, I finally gotten everything set for flashing in the backup on the device.
I’m sorry to have to ask of this, but is anyone good with using dd?
Would it be something like this: my_image.img | dd of=/dev/Device_eMMC
It’s just that using the disk utility before, I somehow can’t flash the whole eMMC partition of my Librem 5, only one at a time. Unless, I only did copy that one partition only and not the whole?
Sorry, I’m pretty weak with DD and I know I need to start getting better at some point
Make a backup of the eMMC drive of your phone to an image file on a desktop/laptop computer. dd would be appropriate for that.
Flash the eMMC with a new version of software, thereby completely wiping out the existing contents of the eMMC. You would use the provided script for that.
Restore a backup of the eMMC drive of your phone, thereby completely wiping out the existing contents of the eMMC. dd would be appropriate for that - but only if the original backup was good.
The basic syntax of dd is
dd if=something of=someotherthing
You just have to be sure that you are using the correct source (input) with if= and the correct destination (output) with of=.
I usually add status=progress (as it is fairly slow), and also add bs=somevalue e.g. bs=1M
As noted above, backup/restore the whole disk, not just one or more partitions - and make sure that no partition on that disk is mounted before starting.
I was able to leverage Jumpdrive to expose the internal storage on a host computer with the goal of creating/restoring a backup, so I created a script to hopefully be a good reference for anyone wanting to do the same. Please feel free to comment on the snippet directly if you discover faults or recommend improvements. I ran into a minor pathing gotcha in the upstream Jumpdrive repo where your pwd must be in the top-level directory of the repository in order for uuu to access the .lst, so I created a pull request to mitigate this.
Hi,
I have already made a back up ages ago so that the Librem 5 could be sent in for repairs before the eMMC gets wiped out for security reasons. Now that it has returned, I’d like to use the back up to restore what had been previously wiped. Basically, the device I have now it just a factory reset version.
I have checked the image I backed up and it has indeed copied the whole eMMC drive with all of it partitions. I had tried to restore the whole drive using the image back up via Gnome Disk Utilities but for some reason I can only find options to restore a single partition as opposed to the whole disk. That’s why I switching to dd: but maybe I overlooked some things in GDU.
So if I were to restore and overwrite my eMMC drive with a backed up image, would it appear something like this?:
dd if=/media/HOME/FOLDER/ImageBackUp.img of=media/HOME/(Librem device eMMC (however it appears in ls)) status=progress bs=1M
What does the bs=somevalue do anyway? is that how I get to see the progress in some form of measurement?
Notice that the block device is /dev/mmcblk0 and not a partition e.g. /dev/mmcblk0p1, etc.
From my understanding, the bs arument for dd essentially provides tuning for the block device IO. It’s not a critical component for most operations. If omitted, it defaults to a 512-byte block size. I personally prefer doing a sync on each block e.g. the oflag=sync option, but I don’t want to waste time doing a sync operation every 512 bytes, hence the 4M value. There is a question on ServerFault that provides a few examples of performance tuning.
Alright, well I finally found what I was looking for in the Gnome Disk Utility. I overlooked where it might have been and just now was able to restore everything back to the way it was.
So in the meantime, I try the dd command to install an image onto one of my usb drives.
but I always just use