Recent, am făcut un stick USB live cu Xubuntu 20.04.02 LTS cu Startup media creator (acest lucru ar putea fi usb-creator-gtk).
Am încercat să redimensionez partiția după ce am creat stick-ul pentru a oferi o partiție de date suplimentară. Dar asta a fost imposibil: deși capacitatea stick-ului era de 32 GB, gparted l-a arătat ca fiind complet ocupat și m-a împiedicat să reduc dimensiunea partiției ISO9660 de pe el.
In orice caz, lsblk îmi spune despre trei partiții pe el:
$ lsblk -o nume, dimensiune, fstype, partflags, model, furnizor /dev/sdc
NUME DIMENSIUNE FSTYPE PARTFLAGS MODEL VANDATOR
sdc 29,3G iso9660 Flash Disk generic
ââsdc1 1,6G iso9660 0x80
ââsdc2 3,9M vfat
ââsdc3 27,7G ext4
$ lsblk -o Nume, dimensiune, tip fs, uuid, etichetă, punct de montare | 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 inscriptibil /media/user/writable
$
În mod surprinzător, același UUID apare de două ori: O dată pentru întregul dispozitiv și încă o dată pentru partiția ISO9660. Aceeași etichetă apare chiar de trei ori: pentru toate cele trei partiții!
După înțelegerea mea, nu este o idee foarte bună. Aș prefera etichete mai semnificative, de ex. Xubuntu20.04.2-amd64_purpose, Unde scop indică scopul acelei partiții.
Mă întreb despre partiția cu etichetă inscriptibil: Se pare că ține evidența când stick-ul a fost folosit pentru instalare. Acolo puteam stoca date, dar nu le puteam accesa din sistemul live!
Am impresia că partiția cu etichetă inscriptibil este montat în sistemul live ca /var/crash. Am stocat un script acolo și l-am folosit. Dar după ce am oprit sistemul live, scriptul meu este pornit /var/crash a fost plecat. Ar putea cineva să demistifice arhitectura de partiție a stick-ului meu USB Live pentru Xubuntu 20.04.02 LTS amd64?
Comentariile până în 2021-08-09 mi-au spus despre beneficiile unui instalare completă (care nu este întrebarea mea) și cum să fac a instalare persistentă (care nu este întrebarea mea).
Am pierdut câteva săptămâni cu instalări persistente folosind unetbootin: le-am făcut cu un persistent compartimentare etichetat casper-rw. Din păcate, în timpul opririi, există o mulțime de scrisori pe unitatea de memorie, în timp ce ecranul arată nevinovat de negru. Dacă cineva deconectează stick-ul în timpul acela periculos, casper-rw este distrus (erori inode)!
Actualizarea unui sistem pe o unitate USB instalată în mod persistent poate dura o perioadă îngrozitor de timp. De exemplu. Am schimbat firefox cu crom. Presupun că consumul de timp se datorează numărului mare de rotații ale direcției de transfer între citire și scriere, ceea ce face ca electronica dispozitivelor USB3 să încetinească de factori mari. A devenit și mai rău, când am încercat să compilez un sistem Jamulus pentru a fi prezent pe stick-ul meu live. Știu că în timpul realizării sunt citite multe fișiere, alte fișiere sunt scrise și, eventual, fișiere intermediare sunt create și șterse după utilizare. Acest lucru provoacă stres pentru care electronica stick-urilor USB3 nu este făcută.
Să ies din noroi după ce mi-am dărâmat peretele despărțitor casper-rw, am creat o partiție de rezervă cu o copie de rezervă a unei lucrări anterioare casper-rw (bineînțeles cu o etichetă diferită). Dar copierea de la unul la altul (ambele aveau exact aceeași dimensiune) cu cp -a (după ștergerea tuturor fișierelor anterioare ale partiției țintă) a durat mult mai mult decât adăugarea unui pas intermediar de prima copiere pe discul meu fix și apoi copiere pe unitatea de memorie: Această observație m-a condus la concluzia că schimbarea direcției de transfer de date este cauza principală a consumului de timp la actualizarea unei instalări persistente.
Întrebările mele de mai sus au fost după o explicație a motivului pentru care nu am putut redimensiona partiția realizat cu instrumentul de creare media start.
Întrebările mele de mai sus au fost după scopul partiției care poate fi scrisă găsit pe băţ.
Obiectivul meu este să creați o partiție pe stick-ul live, care poate fi montat ca /Acasă pentru a fi folosit pentru scripturi, care aplică unele modificări din mers precum acelea, pe care le aplic manual când încerc sistemul live.
Al doilea obiectiv al meu este să creați o partiție pe stick-ul live, care poate fi montat ca /Acasă cu scripturi de instalări on-the-fly de software suplimentar (care se întâmplă în ram-fs și care vor dispărea după oprire).
Desigur, scopul final ar fi acela de a avea acea partiție montată ca /Acasă automat.
Obiectivul meu ar fi la mijloc între un mediu de instalare Read-Only asemănător DVD-ului și unul persistent. Diferența este că un astfel de stick nu poate fi actualizat (persistent). Diferența față de o instalare completă este că va rula pe orice computer (capabil să ruleze sistemul, desigur) și nu pe cel particular, la care o instalare completă a unui stick pare să fie limitată.
(N.B. Am făcut odată un stick de instalare complet pentru un Lenovo W530. Nu a pornit pe un Lenovo T410. Dar a făcut-o pe un T430 și pe un T430s. Arhitectura acelor două modele pare să fie suficient de apropiată pentru a le lăsa să pornească, dar multe alte computere pe care le-am încercat nu s-au pornit de pe acesta.Deci, în general, o instalare completă pare să fie limitată doar la computerul țintă și la rudele foarte apropiate).
Din păcate, partițiile persistente par a fi imposibil de realizat din cauza procesului de închidere foarte consumator de timp: am observat mai mult de 5 minute de activitate pe disc! În caz contrar, erorile inode apar foarte des.
