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.
3 Likes
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.
You can download the latest upstream commit as CI artifact from here, it should launch reliably: https://source.puri.sm/sebastiankrzyszkowiak/Jumpdrive
2 Likes
Tested once and it initialized the first time! Thanks for the link.
2 Likes
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.
Looks like just a permission issue. You can use https://source.puri.sm/Librem5/librem5-flash-image to configure it automatically: sudo ./librem5-flash-image --udev
1 Like
Perfect that worked thank you so much!
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
Then please be careful!!
What exactly are you trying to do?
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.
1 Like
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?
To copy the entire contents of the eMMC (partition table, partitions… everything user-facing), you would do something like:
sudo dd if=/path/to/backup-of-entire-eMMC.img of=/dev/mmcblk0 bs=4M oflag=sync status=progress
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.
1 Like
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.
Thank you very much for you aid.
1 Like