systemd auto umount???

Merevlemezek, vezérlők

Megfagyott a gép (sysrq-s reisub-ra sem történt semmi) reseteltem. (fsck-k rendre megvoltak) Azóta az a furcsa helyzet állt elő, hogy két partíciót nem tudok csatolni a megszokott helyére.

Más rendszer alatt, illetve másik helyre minden gond nélkül csatolhatóak/használhatóak.
Mount ránézésre rendben működik, mégsem csatolódik fel a fájlrendszer.

Találkozott már ilyennel valaki?

  • 2436 megtekintés

( juuzer | 2015. 01. 03., szo – 00:45 )

systemd tréfált meg, nem tett neki jót a reset. 


# systemctl status mnt-sam04.mount
● mnt-sam04.mount - /mnt/sam04
   Loaded: loaded (/etc/fstab)
   Active: inactive (dead)
    Where: /mnt/sam04
     What: /dev/disk/by-partuuid/dec517a0-06
     Docs: man:fstab(5)
           man:systemd-fstab-generator(8)

jan 02 23:54:38 fuser systemd[1]: Unit mnt-sam04.mount is bound to inactive service. Stopping, too.
jan 02 23:54:38 fuser systemd[1]: Unmounting /mnt/sam04...
jan 02 23:54:38 fuser systemd[1]: Unmounted /mnt/sam04.

El kellett indítani a hozzá tartozó szolgáltatást, utána már nem csatolgatja le a filerendszert. 


# systemctl start mnt-sam04.mount

Elméletben igazad van, újraindítás után a probléma ismét megjelenik. A gyakorlat picit érdekesebb, (fixme) az ide vonatkozó szabályokat systemd-fstab-generator hozza létre a boot folyamat során, ezért nem lehet őket engedélyezni.

Sajnos mégsem sikerült megoldani a problémát. Nem tudom hol a gond, ha fstab-ban a csatolási pontot átírom, akkor minden gond nélkül csatolva marad a partíció, egyéb esetben systemd magától leválasztja. Azt sem értem milyen egyéb inaktív szolgáltatásról van szó.
(Magam részéről mindegy lenne hová csatolom a partíciót, de az nem adna választ a probléma miértjére) 


# systemctl list-dependencies mnt-oldhome.mount
mnt-oldhome.mount
● ├─-.mount
● ├─system.slice
● └─systemd-fsck@dev-disk-by\x2duuid-8039ee91\x2d367e\x2d4bf7\x2db516\x2d20078e5bbe19.service
# systemctl list-dependencies mnt-sam03.mount
mnt-sam03.mount
● ├─-.mount
● ├─system.slice
● └─systemd-fsck@dev-disk-by\x2dpartuuid-dec517a0\x2d05.service

( juuzer | 2015. 01. 03., szo – 19:16 )

A következő report vezetett (egy részleges) megoldáshoz.

Eddig partuuid alapján csatoltam a partíciókat. Évek óta rendben is volt a tegnapi fagyásig. Eddig cimkézve sem voltak a partíciók, a fenti link alapján próbálkoztam meg ezzel a megoldással. Jelenleg label alapján minden gond nélkül csatolódnak a partíciók. 


#PARTUUID=dec517a0-05	/mnt/sam03	reiserfs	noauto,users,noatime,notail,exec	0 2
#PARTUUID=dec517a0-06	/mnt/sam04      reiserfs	noauto,users,noatime,notail,exec	0 2
LABEL=sam03		/mnt/sam03	reiserfs	noauto,users,noatime,notail,exec	0 2
LABEL=sam04		/mnt/sam04      reiserfs	noauto,users,noatime,notail,exec	0 2

Ha partuuid alapján szeretném használni, a következő hibával bukom a mutatványt:


jan 03 18:37:27 fuser systemd[1]: Unit mnt-sam03.mount is bound to inactive service. Stopping, too.
jan 03 18:37:27 fuser systemd[1]: Unmounting /mnt/sam03...
jan 03 18:37:27 fuser systemd[1]: Unmounted /mnt/sam03.


cat /var/run/systemd/generator/mnt-sam03.mount 
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
RequiresOverridable=systemd-fsck@dev-disk-by\x2dpartuuid-dec517a0\x2d05.service
After=systemd-fsck@dev-disk-by\x2dpartuuid-dec517a0\x2d05.service

[Mount]
What=/dev/disk/by-partuuid/dec517a0-05
Where=/mnt/sam03
Type=reiserfs
Options=noauto,users,noatime,notail,exec

címke használatával:


cat /var/run/systemd/generator/mnt-sam03.mount 
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
RequiresOverridable=systemd-fsck@dev-disk-by\x2dlabel-sam03.service
After=systemd-fsck@dev-disk-by\x2dlabel-sam03.service

[Mount]
What=/dev/disk/by-label/sam03
Where=/mnt/sam03
Type=reiserfs
Options=noauto,users,noatime,notail,exec

Nem tudom mi lehet a gond a partuuid-s féle csatolással (eddig működött), valamint label alapján miért működik.

GPT-t használsz? Miért PARTUUID-re hivatkozol UUID helyett? Ha jól látom, az UUID azonosítja a filerendszert, a PARTUUID pedig GPT partíciót. Viszont szerintem ez logikailag nincs rendben, mert egy filerendszer lehet több partíción is akár LVM fölött. Filerendszert szerintem UUID azonosít.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

[FIXME]
Nem használok GPT-t, MBR van. UUID az elsődleges meghajtók sajátja, a logikai meghajtók csak PARTUUID-vel rendelkeznek. Valamint, bár ez csak tipp, a PARTUUID-k nem változnak formázás, átméretezés során.

Járattam az agyam elég sokat ezen a PARTUUID-s dolgon, hogy vajon ez GPT függő-e, de mivel csak MBR van nálam nem tartom valószínűnek. Ráadásul évek óta partuuidvel voltak hivatkozva a logikai partíciók fstab-ban.
[/FIXME] 


# lsblk -o NAME,FSTYPE,LABEL,UUID,PARTUUID,MOUNTPOINT /dev/sdb
NAME   FSTYPE   LABEL UUID                                 PARTUUID                             MOUNTPOINT
sdb                                                                                             
├─sdb1 ntfs-3g        1078B05D78B042F0                     dec517a0-01                          /mnt/sam01
├─sdb2 ntfs-3g        24D8A1BDD8A18E1C                     dec517a0-02                          /mnt/sam02
├─sdb3                                                     dec517a0-03                          
├─sdb5 reiserfs sam03                                      dec517a0-05                          /mnt/sam03
└─sdb6 reiserfs sam04                                      dec517a0-06                          /mnt/sam04

Értem, hogy még akár működhet is, csak logikailag fáj nekem kicsit, mert szerintem nem az a réteg. Például nekem az sda6-ban van egy LVM kötet, benne 3 filerendszer. Az sda6-nak van PARTUUID-je, de ezzel a filerendszerre nyilván nem hivatkozhatok. Egyrészt, gondolom, az LVM-hez tartozik némi header, másrészt ahhoz az egy PARTUUID-hez tartozó partícióban az LVM fölötti rétegben található három filerendszer. Ezen filerendszerek mindegyike saját UUID-del rendelkezik, amire korrekt a hivatkozás.

Továbbra is azt állítom, hogy az UUID a filerendszert azonosítja, a PARTUUID pedig a partíciót. Oké, szerencsés esetben a kettő kezdődhet ugyanott, de szerintem ez nem törvényszerű. Mi több, filerendszer nem feltétlen van partícióban.

Amúgy van egy nagyon kósza gondolatom. Nem lehet, hogy valamikor nem sikerült a mountpointhoz csatolni a filerendszert, s valaki írt a csatolási pontra, most nem üres a csatolási pont, s erre nyűgös a systemd? Mert ahogy írod, a mountpointtól függ a dolog. Hasonlóképpen megnézném a jogosultságokat, tulajdonost, csoportot, selinux környezetet, illetve azt, nincs-e véletlenül a mountpoint nevében szóköz - pl. a végén -, amit nem veszel észre, vagy effélék.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Amit a végén említesz, azokkal kezdtem ... jogosultság stb, nem ott van a gond. Másik mountpointtal is ugyanaz a helyzet, egy reboot után az is lecsatolódik állandóan (erre csak később jöttem rá). Arch fstab wikijében is említik ezt a PARTUUID-s csatolást, még ha logikátlan is (ha jól veszem ki, PARTUUID a GPT-s megfelelője az MBR-s UUID-nek).

LABEL alapján működik, PARTUUID-vel nem, a hivatkozást leszámítva ugyanaz mindkettőnél a csatolási pont is. 


# blkid /dev/sdb*
/dev/sdb: PTUUID="dec517a0" PTTYPE="dos" 
/dev/sdb1: UUID="1078B05D78B042F0" TYPE="ntfs" PARTUUID="dec517a0-01" 
/dev/sdb2: UUID="24D8A1BDD8A18E1C" TYPE="ntfs" PARTUUID="dec517a0-02" 
/dev/sdb3: PTTYPE="dos" PARTUUID="dec517a0-03" 
/dev/sdb5: LABEL="sam03" TYPE="reiserfs" PARTUUID="dec517a0-05" 
/dev/sdb6: LABEL="sam04" TYPE="reiserfs" PARTUUID="dec517a0-06" 

 # lsblk -o NAME,FSTYPE,LABEL,UUID,PARTUUID,MOUNTPOINT /dev/sdb
NAME   FSTYPE   LABEL UUID                                 PARTUUID                             MOUNTPOINT
sdb                                                                                             
├─sdb1 ntfs-3g        1078B05D78B042F0                     dec517a0-01                          
├─sdb2 ntfs-3g        24D8A1BDD8A18E1C                     dec517a0-02                          
├─sdb3                                                     dec517a0-03                          
├─sdb5 reiserfs sam03                                      dec517a0-05                          
└─sdb6 reiserfs sam04                                      dec517a0-06                          
fuser juuzer #

Amint lesz UUID-m sdb5/sdb6 -hoz, máris kipróbálom.

Partíció vs filerendszer ... igen, én elég szabadon használom ezt a két szót. Tudom, hogy teljesen mást jelent, de mikor azt mondom partíció, akkor a hozzá tartozó filerendszerre is gondolok. Abból adódóan, hogy egy partícióhoz egy filrendszer tartozik (nálam).

Az hogy a rétegek fölött mennyire nyúltam át, vagy sem ... Arch fstab wiki-jében is van PARTUUID-s példa.

Az az igazság, ebben most magam is bizonytalan vagyok. Egyrészt, ha a PARTUUID-del történő hivatkozás nem jó, akkor hasonlóképpen például a /dev/sda3 hivatkozásnak szintén rossznak kell lennie. Nem tudom, hogyan működik a kernel. Van a block device, azon vagy vannak, vagy nincsenek partíciók. Ha nincs, lehet benne egyből filerendszer a 0-s LBA címtől. Tehát mondjuk van egy ext4 az sdb-n. De lehet akár LVM kötet, benne filerendszerekkel, vagy akár több disken át.

Aztán, ha van partíció, akkor lehet benne filerendszer, hiszen a partíciós tábla feladata éppen az, hogy elmondja, milyen offsettel kezdődik a filerendszer a block device-on. Erre létrejön egy újabb eszköz, a példában sda3. De ebben sem feltétlen filerendszer van, itt is lehet LVM. Másfelől lehet filerendszer offsettel. Például tehetem azt, hogy az sda3 első 1 MB-ját üresen hagyom, s csak utána kezdődik a filerendszer. Vajon a kernel UUID hivatkozással így megtalálja? Erősen kétlem, mert nem hiszem, hogy keresni kezdi az egész HDD-n, illetve a partíción belül az fs elejét.

A fentiek miatt viszont igaznak kellene lennie, hogy amennyiben a partíció közvetlenül filerendszert tartalmaz, nyilván a partíció elejéhez képest nulla offsettel, úgy PARTUUID-del hivatkozva is meg kellene ennek lennie.

Tehát ez vagy bug, vagy nem implementálták a systemd-ben, mondván, filerendszerre tessék hivatkozni, ne partícióra, amelyben az fs van.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez már szerintem történelem amiről beszélünk :). Ha az MBR-ből indulok ki, hogy 4 elsődleges partíció lehet (2 bittel leírva), majd ez kevés lett, így jöttek a kiterjesztett/logikai partíciók. Később GPT és/vagy LVM megoldások.

Szerintem csak annyi történt, hogy a visszafelé való kompatibilitásból maradt meg a többféle (néha ellentmondásos/értelmetlen) hivatkozási lehetőség.

Ebből a szempontból szerintem nem túl érdekes a logikai drive, hiszen az EBR hasonló az MBR-hez. Egy láncolt lista, amelyik leírja az aktuális partíciót, meg a következő EBR helyét. Nekem inkább az a fura, hogy ha a partíció dolga megmondani, itt kezdődik az FS, s erre hivatkozol, akkor miért nem találja. Na most, ha az a gondja, hogy a PARTUUID hivatkozásban maga az aktuális EBR is beleértendő, akkor világos, hogy miért nem működik, de az disznóság. Ez még lehet egy ok. Lényegéban ez azt jelenti, hogy a PARTUUID-os hivatkozás primary partíciók esetén működne, logikai drive-on nem, mert ott az EBR kezdetét jelentheti, s az fs csak az EBR-ben jegyzetten, azt követően, némi offsettel kezdődik.

Apropó, lehet, hogy ez a baj? Az ntfs-edre PARTUUID-dal hivatkozol primary partícióra és működik?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Minden partícióra UUID-vel hivatkoztam, kivéve ezt a kettőt (amivel a probléma adódott). Most már ezekre is UUID-vel hivatkozom.

Eddig tökéletesen (éveken át) működött PARTUUID alaján. Sőt ha manuálisan elindítom a systemd-fstab-generator által létrehozott *.mount filokat, akkor is megy PARTUUID alapján. Ezen kívül a már említett hibába szaladok.

A lényeg UUID-vel már működik, részemről megoldva :)