@sudodus, Thanks for your help. I'll let you know if there are any other problems.
@sudodus, Thanks for your help. I'll let you know if there are any other problems.
@sudodus, I still don't understand how this would enable the replacement of the foxclone executable which is located in the /usr/local/sbin folder. Would the end-user place the new executable in the casper-rw partition or the usbdata partition? Do I need to create a /usr/local/sbin folder in the casper-rw partition? I've done a lot of reading but none that I've found explains how it all works. Can you point me to a tutorial that explains how it works rather than how to make it?
The persistent live system uses an overlay method, so that you need not worry about where to put the updates. When you install or update something in the normal root partition (for example in /bin, /usr, /etc or in /home), it will actually be stored automatically in a corresponding location in the casper-rw partition. The important thing is that you shutdown or reboot the computer in a correct way and let the process finish before you unplug the USB pendrive.
Try it and let me know if it works for you. Good luck
So when the user wants to install a new update does it go into the casper-rw partition or the original location?
Only the casper-rw and/or home-rw partitions are writable.
(With latest 20.04 daily, the persistent partition can be labeled "writable" rather than "casper-rw").
Last edited by C.S.Cameron; February 25th, 2020 at 02:11 PM.
@sudodus - I'm having trouble running your scripts. I used mkusb to create the persistent on /dev/sdd. After I reboot and insert the USB I can see the partitions are mounted. Here's what I'm getting when I run "sudo bash mkpersimage /dev/sdd". Yes, I did make sure that the folder with the scripts is in the path.
EDIT: Had to manually create mount points and install espeak. Also had to set the executable bit on mkxzimage and ender. It's working now but creating a much larger .img.xz when run against the same foxclone.iso. When I ran it, the result ended in 16GB.img.xz instead of 8GB.img.xz. My .img.xz is 1.1GB, yours is 787.7MB. I compared both yours and mine in Gparted after burning each to a USB and they both have the same partition sizes and use the same amount in each partition. Can you explain what might of happened?
Last edited by lhh29936; February 27th, 2020 at 11:03 PM. Reason: Additional Info
0. Sorry for the extra trouble because I forgot to check and tell you about all the dependencies.
1. I would think that the result ended in 16GB.img.xz because you created the drive in a 16 GB pendrive and did not shrink and/or move the casper-rw partition and the usbdata partition to fit in an 8 GB pendrive (with some margin (say within 7.7 MB) because many pendrives are undersized (slightly below the nominal size)).
2. The difference in compressed size is because of the bigger size of the uncompressed image and maybe partly because of things you added to the casper-rw partition. I understand that you ran mkpersimage (and checked that the zeroising of free space worked as expected).
I used the same iso as I sent to you, nothing added. If the partition sizes between yours and mine are the same as well as the space used in each partition, I still don't understand the difference in size. Is the amount of compression based on the amount of free space? I'm going to try again tomorrow and will shrink both casper-rw and usbdata to 2GB before running mkpersimage. Will let you know how it turns out.
Yes, the amount of compression depends on the amount of free space. But I think the difference is rather small. So there is probably some other thing too. Maybe you did not write zeros to all the free space in all the partitions. Or maybe you did not move the partitions, so that there was some 'hole' between the partitions with unallocated drive space, and that space was not zeroised.
Here's what I did today. Took the same original iso that you used and burned it to a 16GB flash drive (the smallest I have). Ran mkusb then opened Gparted and shrank casper-rw and usbdata from 6+GB to 2GB then moved them so they contiguous .There was 9.63GB unallocated space at the end of the drive. I then ran your scripts and that resulted in dd_sda-5GB.img.xz that was 1.7GB in size. It seems like the zeroing isn't working. Any suggestions?
Bookmarks