Hey guys,
Just letting you all know that I’ve now tried out this same method from the Ubuntu Live Distro via USB and I am still getting the exact same results, which is: ./boot-purism-librem5.sh: 3: uuu: not found from using both ./boot-purism-librem5.sh and ./boot-purism-librem5.sh --variant luks
I know that the C-USB cable works fine and that the device is in Flash mode, I just don’t understand why nothing it working for me
I think I should give up at this point, considering that I tried using many methods through different computers and even different distro’s too. I just don’t know what’s going on considering that I’ve followed everything through and through.
I’ll just consider myself very unlucky and just stick with backups for now.
Sorry for wasting everyone’s time.
One more thing to check: what does is say (if anything) from which uuu ? I’m wondering that (especially since you’ve used different instructions) that at some point the uuu has not installed properly because it’s not finding it.
I have used the which uuu command on the Ubuntu live USB but nothing comes up.
That’s the problem, I can’t install anything UUU related and no one is telling whether or not the I have to install uuu or if it somehow comes with the Librem5 jumpdrive.
As long as i can’t install anything uuu related or get it running on any distro or computer, I’m never going to be able to do this.
I’ve also followed the instructions on the link you’ve provided me buidling uuu, but without success
@Gavaudan Thanks, but it already seems to be installed
sudo apt install zlib1g
[sudo] password for USER:
Reading package lists... Done
Building dependency tree
Reading state information... Done
zlib1g is already the newest version (1:1.2.11.dfsg-2ubuntu1.5).
No. In fact that release is now too old to complete this task.
So you definitely want 22.04
Ah, OK. My bad. I failed to point out …
the package uuu is in “universe” but in the Live Boot environment only “main” and “restricted” are configured by default.
So you need to do sudo vi /etc/apt/sources.list
(add the following line) deb http://archive.ubuntu.com/ubuntu/ jammy universe
sudo apt update sudo apt install uuu which uuu
and you finally get /usr/bin/uuu
Yay!
NB: I have just done this myself (and am posting this from the Live Boot). So it definitely works.
I would imagine that any of these changes to the Live Boot environment will be lost on reboot. So best to see whether you can actually get Jumpdrive booted on the Librem 5 without further rebooting of the host computer.
Edit: Update …
The above issue applies only to certain versions of Ubuntu. The above definitely applies to Ubuntu 22.04 (jammy).
The above doesn’t apply to Ubuntu 23.10 (mantic).
I don’t know which version of Ubuntu made the change.
Yes, only disabling deb http://archive.ubuntu.com/ubuntu/ jammy universe entry before next sudo apt upgrade would be recommended (when no other change needed).
That would apply if this were not a Live Boot. For a Live Boot, you probably aren’t ever going to do an apt upgrade and I expect that the change to sources.list is going to be lost on reboot anyway. (So to clarify that … the way I handle upgrade of a Live Boot is just to download the new .iso on most of the 6-monthly releases and ‘burn’ a new flash drive.)
You need sudo in front of that command.
Also, I don’t think --variant luks applies here at all. (That applies when flashing your phone but here you are just booting Jumpdrive - and to image the eMMC drive you don’t even have to care about LUKS. You just want an exact copy as seen from the outside, encryption and all.)
Okay, it worked this time and jumpdrive is running.
I am currently trying to make an image copied from the eMMC drive, but for some reason it’s telling me that the file size is too large, even though I got more than enough space on my SD card that is connected to my computer.
Something tells me that it’s not going to work through the disk utility, personally I’m not a fan of. I might just try to use Gparted to copy the whole eMMC drive partitions into the SD card instead. What ever it takes.
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)
but I always just use