Puncte:0

Ignorați eticheta când montați partiția de pornire a imaginii sistemului de operare ca dispozitiv de loopback

drapel ua

As dori sa montez partiția de pornire al ubuntu-21.10-preinstalled-server-arm64+raspi.img.xz descărcat de pe site-ul web Raspberry PI.

Despachetarea fișierului imagine și montarea partiției de boot cu o comandă ca

mount -o loop,offset=1048576,sizelimit=268435456 ubuntu-21.10-preinstalled-server-arm64+raspi.img /var/nfs/ubuntu-21.10-boot

... funcționează bine. Puteți vedea imaginea montată împreună cu /dev/mmcblk0p1 dispozitiv:

montură | cizme grep
/dev/mmcblk0p1 pe /boot/firmware tip vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
/var/nfs/ubuntu-21.10-preinstalled-server-arm64+raspi.img pe /var/nfs/ubuntu-21.10-tip de pornire vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset= ascii,shortname=mixed,errors=remount-ro)

Totuși, când adaug aceeași montură la /etc/fstab la montura deja existenta pt /boot/firmware:

LABEL=system-boot /boot/firmware vfat defaults 0 1
/var/nfs/ubuntu-21.10-preinstalled-server-arm64+raspi.img /var/nfs/ubuntu-21.10-boot ext4 loop,offset=1048576,sizelimit=268435456 0 0

... și reporniți sistemul (sau rulați monte -a) partiția de boot a imaginii este montată atât la /var/nfs/ubuntu-21.10-boot așa cum era de așteptat dar și la /boot/firmware și astfel înlocuind firmware-ul real la /dev/mmcblk0p1:

montură | cizme grep
/var/nfs/ubuntu-21.10-preinstalled-server-arm64+raspi.img pe /var/nfs/ubuntu-21.10-tip de pornire vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset= ascii,shortname=mixed,errors=remount-ro)
/var/nfs/ubuntu-21.10-preinstalled-server-arm64+raspi.img pe /boot/firmware tip vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed, errors=remount-ro)

Acest lucru se datorează evident că partiția de pornire a imaginii este etichetată sistem-boot care se ciocnește cu /dev/mmcblk0p1 etichetat la fel.

(Pagina manualului de montare specifică asta fstab este ignorată atunci când sunt specificate atât dispozitivul, cât și punctele de montare, ceea ce explică de ce montarea manuală funcționează conform așteptărilor.)

Mă gândesc la următoarele soluții pentru a evita suprascrierea suportului de firmware:

  • Evitați utilizarea fstab și montați manual într-un script rc
  • Reetichetați partiția de pornire a fișierului imagine
  • A inlocui LABEL=sistem-boot cu dispozitivul real care deține firmware-ul (după cum este sugerat în răspunsul lui @Tilman de mai jos)

... dar

Există vreo modalitate de a preveni montarea automată a unei intrări fstab după etichetă?

Christoffer Soop avatar
drapel ua
A adăugat soluția de soluție din răspunsul de mai jos, dar nu a acceptat-o ​​ca răspuns, deoarece nu răspunde cu adevărat la întrebarea dacă puteți împiedica declanșarea mecanismului de eveniment system.d atunci când un dispozitiv de loopback este adăugat la fstab.
Puncte:0
drapel cn

Clauza LABEL=sistem-boot spune montură a monta orice sistem de fișiere cu etichetă de volum sistem-boot pe acel punct de montare. Dacă nu doriți asta, atunci nu folosiți acea clauză. Înlocuiește-l cu /dev/mmcblk0p1 care spune montură sa montezi exact acel dispozitiv, fara a tine seama de eticheta.

Christoffer Soop avatar
drapel ua
Mulțumesc - dar acest lucru presupune că eu scriptul meu știe că dispozitivul `system-boot` este `/dev/mmcblk0p1` ceva ce sper să nu consider de la sine înțeles sau să nu analizez din rezultatul mount sau al unei alte comenzi...
Tilman avatar
drapel cn
Atunci trebuie să faci un pas înapoi.Ce definește dispozitivul pe care doriți să îl montați pe `/boot/firmware`? Nu puteți folosi eticheta, deoarece ați făcut-o ca non-unica. Nu doriți să utilizați numele dispozitivului, deoarece nu doriți să transmiteți aceste cunoștințe scriptului dvs. Ce atunci?
Christoffer Soop avatar
drapel ua
În acest caz, folosesc o imagine pre-ambalată a sistemului de operare pe care o folosesc atât pentru montarea pe o mașină „gazdă” care servește un sistem de fișiere NFS clienților fără disc. În prezent, folosesc /boot/firmware pentru clienții fără disc, dar ar fi mai bine să folosesc partiția de pornire a imaginii, deoarece apoi ar putea disocia versiunea sistemului de operare gazdă de cea a clienților. Cred că cea mai bună opțiune este să schimb eticheta fișierului imagine. De asemenea, ar putea dori să preprovizionați software-ul, astfel încât realizarea de imagini personalizate nu pare o problemă.
Christoffer Soop avatar
drapel ua
... și apoi cel mai ușor lucru de făcut este doar să montați partiția de pornire, să o copiați în fs și să omiteți întreaga problemă a etichetei, fără a adăuga partiția de pornire la fstab. Doar m-am gândit că ar exista o modalitate de a inhiba caracteristica implicită de montare automată pe etichetă a fstab pentru linii individuale, dar bănuiesc că ceea ce văd este un comportament neintenționat, deoarece dispozitivul de loopback este deja montat atunci când începe automatizarea.
sudodus avatar
drapel jp
În general, este mai sigur să folosiți UUID-ul decât o etichetă pentru a defini ce să montați, deoarece este mai probabil să fie unic. Ar fi posibil asa ceva in cazul tau?
Christoffer Soop avatar
drapel ua
@sudodus - vrei să spui prin schimbarea liniei implicite `LABEL=system-boot` în `/etc/fstab`, spre deosebire de schimbarea etichetei partiției definite în imagine? Presupunând că funcționează (nu văd de ce nu) mai trebuie să aflu cum să-l scriu folosind `cloud-init` sau Ansible și nu răspunde cu adevărat la întrebarea inițială... dar sigur, aceasta este o posibilitate ca rezolvă cel puțin problema de bază - mulțumesc!
Christoffer Soop avatar
drapel ua
... și asta era ceea ce spunea răspunsul în primul rând.
sudodus avatar
drapel jp
@ChristofferSoop, Da, vreau să spun că schimbarea la `UUID=...` îl face mai fiabil. (Puteți găsi UUID-ul corect cu comanda `lsblk -f`), Vă rugăm să rețineți că ID-ul dispozitivului `/dev/...` este *nu* la fel de fiabil ca utilizarea uuid-ului.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.