Dotaz: Jak ukončit dropbear a pokračovat v zavádění?

[Aleš Kapica]

Mám dropbear v ramdisku. Když dojde k problému, nahodí se a já ho mohu pořešit vzdáleně. Má to ovšem háček. Nevím jak to udělat aby se ukončil a init pokračoval v zavádění systému.

Když dám exit, tak se ukončí pouze ssh sezení. Když ho killnu, tak ramdisk stejně čeká dál na to, než mu na lokální konzoli napíši a odklepnu exit.

---

---

Odpovědi

[k3dAR]

to mas pres balik dropbear-initramfs, nebo si pripravil vlastni skripty? pokud to prvni, tak mam zkusenost jen s tim ze se pripojim, odemknu luks a killnu skript co ceka na luks heslo na konzoli, pripadne tusim je tam skript co to dela vse sam, predpokladam ale ze ty pises o tom, kdyz systemd nahodi emergency konzoli, tak se ti pusti zaroven dropbear, nevim tedy zda to dela dropbear-initramfs nebo ty, ale obecne/surove, proste zabit neco vejs nad tim, podivej se na seznam bezicich procesu treba te neco trkne...

[k3dAR]

tedy pokud pises ciste o initramfs, tak systemd asi u slova neni, tzn. pri jakem problemu se ti dropbear nahazuje? kdyz nenajde root= ?

[k3dAR]

tak sem si overil, s dropbear-initramfs pousti initramfs v pripade (napr.?) nedostupnosti root= dropbear automaticky, proces kterej musis killnout, tedy ten pro co representuje busybox "emergency" shell na konzoli je "{exe} sh -i", je potreba "kill -9 pid" nemam to tedy kompletne overeno, protoze kdyz sem root= uvedl spatne a ted pres ssh chtel zmenit cmdline (na ktere bindnul rw file) tak i kdyz zmenim na spravne a killnu pid "{exe} sh -i" tak se na konzoli zobrazi erorr root= neni (s tim puvodne vadnym nazvem) a busybox se pusti znovu...

[k3dAR]

overeno, ten kill funguje jak sem psal...
(pretim mi to neslo overit, protoze pri nedostupnosti root= se nenahodilo lvm, nedoslo mi ze lvm nastroj neni v ceste ale v /sbin a to ze initramfs si cmdline uz pak nereloadne z /proc/cmdline, takze sem dal "/sbin/lvm vgchange -ay", cp -a /dev/mapper/spravnej-nazev /dev/mapper/blbej-nazev" a po killnuti system nastartoval, tenhle hacek by samozrejme odpadl kdyz by nebyl rootfs na lvm)

[Aleš Kapica]

No. To je přesně to nač narážím. Místo aby pokračoval, nahodí ho znovu. Problém je v tom, že jinak vidí zařízení ramdisk a jinak systém. Nevím, jestli to je dáno tím, že systemd nějak reinicializuje sběrnici či co.

…
   8      144 1953514584 sdj
   8      145 1953513560 sdj1
   8      128  312571224 sdi
   8      129  312570200 sdi1
   8      176 1953514584 sdl
   8      177 1953513543 sdl1
   8      160 1953514584 sdk
   8      161 1953513543 sdk1
   8       96  488386584 sdg
   8       97  488385560 sdg1
~ # mount LABEL=system /root -o subvol=root
mount: mounting /dev/sdg1 on /root failed: Invalid argument
~ # mount /dev/sdi1 /root -o subvol=root
~ # btrfs fi show /root
Label: 'system'  uuid: 95ab0eec-4930-4400-8d89-4c24d6aa8f28
        Total devices 2 FS bytes used 43.21GiB
        devid    1 size 298.09GiB used 45.03GiB path /dev/sdi1
        devid    2 size 465.76GiB used 45.03GiB path /dev/sdg1
~ # ps -ef | grep sh
    1 root     {init} /bin/sh /init
  281 root     sh -i
  284 root     -sh
  315 root     [btrfs-flush_del]
  336 root     grep sh
~ # kill -9 281
~ # Connection to 192.168.33.101 closed by remote host.

Problém je v tom, že když mountuju v ramdisku přes LABEL, nebo uuid, tak se primárně pokouší mountovat /dev/sdg1, což selže. Nicméně dík za nasměrování. Tvrdé odstřelení spuštěného shellu vede ke kýženému výsledku

[k3dAR]

aj btrfs, nemam zkusenosti ani ve virt na simulaci, kazdopadne nemuze to souviset s timto?

[Aleš Kapica]

Ani ne. Jen tak pro zajímavost. Tak vypadá výpis zařízení v ramdisku kupř. nyní:

~ # cat /proc/partitions 
major minor  #blocks  name

   8        0 1953514584 sda
   8        1 1953513560 sda1
   8      112 1953514584 sdh
   8      113 1953513543 sdh1
   8       96 1953514584 sdg
   8       97 1953513543 sdg1
   8       80 1953514584 sdf
   8       81 1953513560 sdf1
   8       64  312571224 sde
   8       65  312570200 sde1
   8       32  488386584 sdc
   8       33  488385560 sdc1
   8       48 1953514584 sdd
   8       49 1953513560 sdd1
   8       16 1953514584 sdb
   8       17 1953513560 sdb1
   8      128 1953514584 sdi
   8      129 1953513560 sdi1
   8      144 1953514584 sdj
   8      145 1953513560 sdj1
   8      160 1953514584 sdk
   8      161 1953513560 sdk1
   8      176 1953514584 sdl
   8      177 1953513560 sdl1

Takže nikoliv sdg1 a sdi1, jako předtím, ale sde1 a sdc1. Fakt to nechápu. Pokaždé se ty disky najdou nějak jinak. Aniž bych do toho stroje nějak vrtal.

[PetebLazar]

Na kolika řadičích jsou ty disky přípojeny? Nemuže docházet k paralelní iniciaci jednotlivých řadičů (jimi obsluhovaných disků) s pokaždé jiným výsledek (dle závislosti na době trvání iniciace)?

[k3dAR]

jak pise PetebLazar... dle mnozstvi cekam vice radicu i kdyby meli byt vsechny onboard a prave proto se to poradi bude menit, podle toho jak se ktere driv chytej, pripadne mozna i inicializace jednotlivejch zarizeni, kazdopadne to ze se muzou(a deje se) menit poradi sdX byl duvod proc se pred XY lety preslo na pristup pres UUID (ci LABEL)...

takze spis bych se zameril na to proc se pres LABEL snazi pripojit jinej disk, chapu ze jde o btrfs raid? nebo nejakej seskupeni, proc je problem s tim co se snazi pripojit? jde o fyzicky vadnej disk? neni mozno u btrfs vynutit z ktereho disku (dle UUID disku) se z daneho "seskupeni" pripojuje?

[PetebLazar]

Pokud by to tím bylo, nešlo by zakázat paralelismus asi systemd (aspoň v iniciaci), detekce by pak možná končila se stejným výsledkem (pořadím). V minulosti (init era) jsem měl přes osm HDD na více než čtyřech řadičích a změna pořadí mne nikdy netrápila.

[k3dAR]

pri teprve initramfs je to myslim vec jadra, v initramfs systemd neni, resp. je tam udevd ktere systemd sezral:

$ sudo lsinitramfs /boot/initrd.img-5.3.0-42-generic | grep systemd
lib/systemd
lib/systemd/systemd-udevd
lib/systemd/network
lib/systemd/network/99-default.link
lib/x86_64-linux-gnu/libsystemd.so.0.21.0
lib/x86_64-linux-gnu/libsystemd.so.0
lib/modprobe.d/systemd.conf

takze vlastne otazka zda to neni i vec udevd kazdopadne jak sem psal pod tim, neresil bych zmeny nazvu, ale zameril se na Non-sdXY pojmenovani zarizeni pro root...

[k3dAR]

mysleno v tom prvnim vystupu kde si uspesne rucne pripojil pres:

mount /dev/sdi1 /root -o subvol=root

zda by neslo:

mount /dev/disk/by-partuuid/[UUID-TOHO-SPRAVNEHO-ODDILU] /root -o subvol=root

(nebo pred */by-uuid, */by-id, atd) a to funkcnii by-X poresit v cfg zavadece...

[Aleš Kapica]

No to je právě to. Dřív problém nebyl, pak se objevil. A neřeším ho zase tak často abych tomu věnoval víc času. Stačí mi, kdyžt to mohu vzdáleně připojit a nazdar pipi. Jinak ano. Je tam řadič na desce (8 portů) + 2 x 4portový adaptec. Všchny sata pozice osazeny nejsou, mám rezervu.

Jinak v grubu se používá uuid FS, jenže ten idiot vždy leze ne na první z disků, ale na ten druhý. Pokud jde o ty ostatní disky - ty s tím nesouvisí. Je to jiný FS s jiným uuuid.

[k3dAR]

[...] Jinak v grubu se používá uuid FS, jenže ten idiot vždy leze ne na první z disků, ale na ten druhý. [...]

to sem psal, ze (mozna tim ze neznam btrfs) nevim co znamena ze mas v "seskupeni" ty 2 disky, je to raid a prvni je vadnej? proto sem myslel nemit v grub.cfg UUID filesystemu (kterej je asi na tech 2 diskach), ale primo oddilu na tom druhem disku kterej ti rucne pripojit sel

[Aleš Kapica]

To je těžké. V podstatě tam jsou dva FS. Původně jsem to měl jen na jednom. A fungovalo to dlouhé roky bez problémů. Pak soudruzi chytráci co vyvíjejí grub udělali někde nějakou změnu a po update to začalo zlobit. Tak jsem oddělil systém od dat. V naději, že se dvěma menšíma diskama problém nebude. Omyl. Tak jsem to vyřešil tím dropbearem. Štvalo mě akorát to, že jsem nevěděl jak ho po nahození zastřelit, abych nemusel instrouovat někoho doma že má jít napsat a odklepnout exit.

[Aleš Kapica]

Aby to nevypadalo že vývojáři grubu jsou blbci - jejich chyba to není. Ten problém je ve skriptu pro mount Btrfs, který nejspíš počítá jen s jedním fyzickým diskem.

[k3dAR]

i kdyz stale nevim proc jsou ty 2 disky a proc 1 z nich je problem, nicmene, zkusil si ten mount zarizeni /dev/disk/by-partuuid/ ? tam logicky presne urcis jednoznacne konkretni disk-oddil narozdil od LABEL ktere je stejne pro oba ty disky...

[Aleš Kapica]

LABEL se používá proto, abys mohl FS migrovat mezi disky. Ale to předpokládám víš. Vázat to na konkrétní partuuid znamená, že ti to zavádění přestane fungovat, pokud chcípne.

Nechce se mi zatím mi do toho hlouběji zabáhat i když mi asi nic jiného nezbyde. Klíčový je moment, kdy dojde k selhání initu a je zavolán dropbear.

[k3dAR]

u EXT4 beru LABEL jako to co mi zajisti, ze i kdyz vymenim disk ci preformatuju oddil, tak nemusim (pri formatovani, nebo az pak) resit UUID nastavenim na puvodni, nebo menit miste kde UUID je uvedeno... nicmene nevim jak je to u BTRFS kdyz mas LABEL system na dvou diskach(btrfs raid? seskupeni? neco?) ale 1 z nich nelze z nejakeho duvodu pripojit, a rucne ti pomuze kdyz misto mount pres LABEL pouzijes primo jmeno zarizeni z tech dvou disku toho co pripojit lze, proto myslim ze resenim(kdyz nepocitam vyresit proc ten 1 pripojit nelze) by bylo misto LABEL urcit prave to UUID oddilu ktere jasne rekne ze ma jit o ten disk co pripojit rucne sel

[Aleš Kapica]

U Btrfs v multi device módu to funguje tak, že LABEL zastupuje celý FS. Mountuje se vždy ten disk, který má nejnižší index. Po pravdě nechápu proč si s tím ten init neporadí, protože příkaz btrfs normálně ten souborový systém vidí a vidí i které zařízení má nejnižší devid. Že se to mění, můžeš vidět z následujícího výpisu:

stroj :~# btrfs fi show
Label: 'system'  uuid: 95ab0eec-4930-4400-8d89-4c24d6aa8f28
        Total devices 2 FS bytes used 43.23GiB
        devid    1 size 298.09GiB used 45.03GiB path /dev/sdi1
        devid    2 size 465.76GiB used 45.03GiB path /dev/sdg1

Label: 'main'  uuid: 10000000-0000-0000-0000-000000000000
        Total devices 10 FS bytes used 6.18TiB
        devid    1 size 1.82TiB used 1.32TiB path /dev/sda1
        devid    2 size 1.82TiB used 1.29TiB path /dev/sdb1
        devid    8 size 1.82TiB used 1.19TiB path /dev/sdk1
        devid    9 size 1.82TiB used 1.19TiB path /dev/sdl1
        devid   10 size 1.82TiB used 1.20TiB path /dev/sdc1
        devid   11 size 1.82TiB used 1.31TiB path /dev/sdd1
        devid   12 size 1.82TiB used 1.25TiB path /dev/sde1
        devid   13 size 1.82TiB used 1.23TiB path /dev/sdf1
        devid   14 size 1.82TiB used 1.19TiB path /dev/sdh1
        devid   15 size 1.82TiB used 1.19TiB path /dev/sdj1

Jak vidíš, původní FS je 'main'. Důvod proč se to nepřipojí v ramdisku je jednoduchý. Ten pitomý skript sáhne na první disk, u kterého najde LABEL a dál už nejde. Přitom by stačilo, aby v případě neúspěšného mountu přešel na další, dokud mount nedopadne, nebo dokud mu nedojdou disky co mají stejný LABEL.

[j]

"přes LABEL, nebo uuid, tak se primárně pokouší mountovat /dev/sdg1"

Mozna mas nasledujici proble s grubem ...

Najdes tam totiz neco takovyho(v grub-configem vygenerovanym cfg):

if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  ebd6...

A potiz je, ze to proste da prednost tem nazvum v hintech ktery ale v okamziku bootu nemusej vubec platit, a navic pokud samozrejme pridas trebas dalsi disk, tak to cely prestane fungovat uplne. A nenasel sem zadnej zpusob jako ty vopicarne rict, at to negeneruje, takze sem si proste pridal vlastni post-script, kterej to smaze. Kupodivu, se ty vopicarne naopak da rict, at tam nedava uuid.

BTW: Trebas HP microserver gen8 ti nazvy devices taky behem inicializace/bootu zmeni, presne proto sem to resil = chtel sem aby to pouzivalo label/uuid. Defakto se mi tam pokud si pamatuju delo to, ze boot sice probeh z hd0, ale kernel to pak uz videl jako hd4 (=pred to zarizeni, se naladovaly ty 4 disky, ktery sou jen datovy a nestartuje to z nich). Tudiz kokotskej grubconfig vzdycky nasral do konfigurace hd4, ze kteryho ale nastartovat pochopitelne neslo a uuid + label to vesele zcela ignorovalo. Kdyz tech disku byl jinej pocet, tak se samo prislusne menilo device (hd3/2/1 ...)

[Aleš Kapica]

Je to přesně tak jak píšeš.

Jo, a taky mě napadlo to ošetřit init skriptem. V podstatě stačí hodit do smyčky ať zkusí mountnout všechny disky co najde, dokud se nechytne a pak pokračuje dál.

[Aleš Kapica]

A ještě jedna věc. Ten grub to udělá dobře, jinak by nenašel jádro. Blbý je init skript pro mount Btrfs.