Recently I made a live USB stick with Xubuntu 20.04.02 LTS with Startup media creator (this might be usb-creator-gtk).
I tried to resize the partition after creating the stick in order to provide an additional data partition. But that was impossible: Although the capacity of the stick was 32 GB, gparted showed it as completely occupied and prevented me from reducing the size of the ISO9660-partition on it.
However, lsblk tells me about three partitions on it:
$ lsblk -o name,size,fstype,partflags,model,vendor /dev/sdc
NAME SIZE FSTYPE PARTFLAGS MODEL VENDOR
sdc 29,3G iso9660 Flash Disk Generic
├─sdc1 1,6G iso9660 0x80
├─sdc2 3,9M vfat
└─sdc3 27,7G ext4
$ lsblk -o Name,size,fstype,uuid,label,mountpoint | grep -E sdc
sdc 29,3G iso9660 2021-02-09-19-20-08-00 Xubuntu 20.04.2.0 LTS amd64
├─sdc1 1,6G iso9660 2021-02-09-19-20-08-00 Xubuntu 20.04.2.0 LTS amd64 /media/user/Xubuntu 20.04.2.0 LTS amd64
├─sdc2 3,9M vfat 54C5-9C6C Xubuntu 20.04.2.0 LTS amd64
└─sdc3 27,7G ext4 80b4c9bd-f04c-4bc2-8ae8-7551e6026d49 writable /media/user/writable
$
Surprisingly the same UUID appears twice: Once for the whole device and once more for the ISO9660-partition. The same label even appears three times: for all three partitions!
To my understanding that's not a very good idea. I would prefer more meaningful labels, e.g. Xubuntu20.04.2-amd64_purpose, where purpose indicates the purpose of that partition.
I wonder about the partition with label writable: It seems to keep track when the stick was used for installation. I could store data there, but I could not access them from the live system!
I have the impression that the partition with label writable is mounted in the live system as /var/crash. I stored a script there and I used it. But after shutting down the live system, my script on /var/crash was gone. Could someone please demystify the partition architecture of my Live USB-Stick for Xubuntu 20.04.02 LTS amd64?
The comments up to 2021-08-09 told me about the benefits of a full install (which is not my question) and how to make a persistent install (which also is not my question).
I had wasted some weeks with persistent installs using unetbootin: I had made them with a persistent partition labelled casper-rw. Unfortunately during shutdown, there is an awful lot of writing to the thumbdrive while the screen looks innocently black. If one disconnects the stick during that dangerous time, casper-rw is ruined (inode errors)!
Updating a system on a persistently installed USB-drive can take an awful amount of time. E.g. I exchanged firefox by chromium. I suppose that the time consumption is due to the huge number of turns of the transfer direction between reading and writing, which causes the electronics of USB3-devices to slow down by large factors. It got even worse, when I tried to compile a Jamulus system to be present on my live stick. I know that during make many files are read, other files are written and possibly intermediate files are created and deleted after use. This causes stress for which the electronics of USB3-sticks is not made.
To get out off the mud after wrecking my partition casper-rw, I had created a spare partition with a backup copy of a previous working casper-rw (of course with a different LABEL). But copying from one to the other one (both had exactly the same size) with cp -a (after deleting all previous files of the target partition) took much longer than adding an intermediate step of first copying to my fixed disk and then copying to the thumb drive: This observation led me to the conclusion that changing the data transfer direction is the root cause for time consumption when updating a persistent installation.
My questions above were after an explanation of why I could not resize the partition made with start media creation tool.
My questions above were after the purpose of the partition writable found on the stick.
My objective is to create partition on the live stick, which can be mounted as /home to be used for scripts, which apply some on-the-fly modifications like those, which I apply manually when trying the live system.
My second objective is to create partition on the live stick, which can be mounted as /home with scripts of on-the-fly installations of additional software (which happen in the ram-fs and which will be gone after shutdown).
Of course, the ultimate goal would be to have that partition mounted as /home automatically.
My objective would be in the middle between a DVD-like Read-Only installation medium and a persistent one. The difference is that such a stick can not be updated (persistently). The difference to a full install is, that it will run on any computer (capable of running the system, of course) rather than the particular one, to which a full install of a stick seems to be limited.
(N.B. I once made a full install stick for a Lenovo W530. It did not boot on a Lenovo T410. But it did on a T430 and on a T430s. The architecture of those two models seems to be close enough to let them boot, but many other computers which I tried did not boot from it. So in general, a full install seems to be limited to the target computer and very close relatives only).
Unfortunately persistent partitions seem to be infeasible because of the very time consuming shutdown process: I observed more than 5 minutes of disk activity! Otherwise inode-errors happen very often.
