Fórum Root.cz
Hlavní témata => Server => Téma založeno: MiroslavPragl 13. 02. 2025, 21:29:35
-
Dobry vecer,
dnes jsem na jednom domacim zalohovacim serveru (Ubuntu 24.04.2 LTS) aktualizoval mj. kernel na 6.11.0-17-generic a "diky" nekonecne dlouho trvajicimu restartu a chvilkovemu zobrazeni "enter root password for maintenance" kvuli neplatnemu fstab zaznamu zjistil, ze je zjevne opravena letita chyba cislovani RAID - misto md127 je pole opet autodetekovano jako md0
Nicmene nikde jsem nenasel, ze to tak ma byt. Muzete pls potvrdit?
Dik
MP
-
BTW: md127 nebude uplne genericky misto md0 s <6.11 ;-)
Xubuntu 24.04 s 6.8.0-52-generic:
grep ^md /proc/mdstat
md0 : active raid1 sdb2[1] sda2[0]
-
Je to 10 let stary problem.
Samozrejme netvrdim, ze kdyz jsem na nej narazil ja, ze na nej narazili vsichni. Jen mnozi :)
MP
-
Je to víceméně jedno, můžete použít jakékoliv číslo (0-127) zařízení md, které se vám bude líbit.
Akorát samozřejmě pokud se k tomu konkrétnímu zařízení někde dál přímo odkazujete např. ve fstabu, nemělo by se dál měnit.
Ve fstabu můžete místo devnodu konkrétního zařízení s oddílem použít jeho UUID, který zajistí že se oddíl připojí i když by se někdy změnilo zařízení.
Tzn. pokud máte teď ve fstabu např. podobný řádek jako
/dev/md0 /data xfs default 0 0
tak si zjistíte UUID, třeba přes "sudo blkid /dev/md0"
A následně změníte řádek, např.
UUID=8cd373b3-f161-41aa-b3b4-5726523b6a6f /data xfs default 0 0
Jinak ještě k tomu md, ta čísla zařízení by se rozhodně neměla jen tak sama od sebe měnit.
Jsou v podstatě dvě místa, kde to může být zapsané.
Buď v souboru /etc/mdadm.conf, kde bývá řádek s popisem každého konkrétního RAIDu (pozor jeho interní UUID je jiné, než toho oddílu s filesystémem, co se uvádí ve fstabu).
Takže např. tohle by mělo zajistit, že se konkrétní RAID složí jako /dev/md0 (resp. /dev/md/0, což je jen alias)
ARRAY /dev/md/0 metadata=1.2 UUID=7f444db2:4dcba828:5dbd2f88:d466a6a7
Tenhle soubor nemusíte nutně v systému mít. Pokud tam není, používá se autodetekce RAIDu a případně se číslo zařízení vezme z metadat v superbloku.
Ta se vypíšou příkazem:
sudo mdadm --detail /dev/md0
Výstup pak může obsahovat např. řádek:
Preferred Minor: 0
Což pak udělá víceméně totéž a zařízení bude opět /dev/md0
V případě potřeby se dá změnit jak superblok (raid se musí stopnout přes mdadm a ručně složit s updatem superbloku), tak vygenerovat /etc/mdadm.conf (v podstatě jen výstup z: sudo mdadm --detail --scan), nebo obojí.
-
Jinak ještě jestli je na tom RAIDu root oddíl (já uváděl příklady s nějaký dalším datovým oddílem), tak po případné změně, nebo vytvoření /etc/mdadm.conf je typicky ještě nutné vygenerovat nový initird.
Tzn. na Ubuntu/Debianu by to bylo přes update-initramfs.
-
To samozrejme vim.
Popisuju letity stav ponekud obskurniho cislovani md zarizeni pri AUTOMATICKE detekci a zajimam se o to, zda zmenu nekdo potvrdi.
MP
-
O.K. nepochopil jsem původní otázku a nevěděl, že víte :).
Já na serverech, kde mám md RAIDy, většinou nepoužívám Ubuntu, abych vám to potvrdil nebo vyvrátil. Na ostatních distribucích (RHEL, CentOS, Oracle, SUSE) v různých verzích se mi nic podobného nedělo, zařízení z vytvořených RAIDů se číslovaly rovnou od nuly a většinou jsem tam následně ukládal i mdadm.conf.
U vás tedy není ani config a ani ta zmíněná metadata v 0.9 superbloku?
-
https://www.pslib.cz/milan.kerslager/RAID_v_Linuxu#Zm.C4.9Bna_preferovan.C3.A9ho_minor_number
Jestli to dobre chapu, tak --update=super-minor bude fungovat jen pri rucnim sestaveni pole, takze musite udelat --stop, a pak --assemble a pokud nemate mdadm.conf, tak vylistovat komponenty pole (uvidite v cat /proc/mdstat pred stopem), a pak uz hura do nastaveni.
Pote bych to rebootnul a cekal zazrak, dejte vedet zda to zafungovalo.
-
Co si matně pamatuji, tak tenhle problém mi vždycky vyřešilo pole umístit do /etc/mdadm/mdadm.conf + nezapomenout přebuildovat initramfs, aby se ten zaktualizovaný konfigurák dostal i do startovacího systému.
-
Tak jsem si to otestoval sám, měl jsem shodou okolností jeden zkušební virtuál s Ubuntu 24.04.
Výchozí stav je s jádrem 6.8.0-51-generic, co tam bylo nainstalované se systémem 24.04.1
Pokus 1
- vytvořil jsem klasicky raid-1 a počkal, až se syncuje
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/vdb /dev/vdc
- zkontroloval jsem /etc/mdadm/mdadm.conf, nejsou v něm žádné direktivy, jen komentovaný po instalaci z balíčku
- po rebootu se zařízení skutečně složilo jako /dev/md127
- přidal jsem řádek array do mdadm.conf
mdadm --detail --scan >> /etc/mdadm/mdadm.conf a ruční úprava řádku se zařízením na /dev/md0
- po rebootu se zařízení složilo správně jako /dev/md0
Pokus 2
- zruším předchozí RAID
- vytvořím znovu totéž, ale se superblokem v 0.9, abych mohl naspecifikovat preferred minor (funguje jen se starým superblokem, přidávám parametr --auto)
sudo mdadm --create /dev/md0 --level=1 --auto=md0 --metadata=0.90 --raid-devices=2 /dev/vdb /dev/vdc
- kontrola madam --detail /dev/md0 ukazuje opravdu preferred minor 0
- po rebootu je to zas na /dev/md127 :)
- kontrola madam --detail /dev/md127 teď ukazuje preferred minor 127 (WTF!!!, jak je tohle možné)
Pokus 3
- po zrušení RAIDu, vytvořím nanovo, zpátky s výchozím superblokem v 1.2 jako u prvního pokusu.
- po rebootu se opět chytí jako /dev/md127
- apt update, apt install linux-generic-hwe-24.04 (poslední HW jádro 6.11.x)
- nainstaluje se 6.11.0-17-generic a přímé závislosti (headery, moduly, image), žádné jiné balíčky neaktualizuji
- po rebootu se RAID chytí jako /dev/md0 :)
Závěr.
Potvrzuji zmíněné chování, resp. změnu s 6.11.x.
Jediné, co vypadá, že to spolehlivě řeší i pro předchozí jádra na Ubuntu, je vytvoření řádku s odpovídající direktivou v /etc/mdadm/mdadm.conf (a případný, zmíněný update initrd, jestliže jde o RAID s root oddílem)
Jinak jsem si totéž ještě zběžně otestoval na virtuálu s Oracle Linuxem 9 (jádro 5.15). Tam se nic takového neděje, když se RAID vytvoří jako /dev/md0, tak to drží i bez explicitního záznamu v mdadm.conf.
-
Ještě v
https://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_6.11.0-17.17/changelog
Tam byly nějaké patche ohledně md v 6.8.2 a 6.8.3, podle rychlého prolítnutí jejich popisu mi nepřijde, že by to mělo přímo řešit zmíněné chování, ale nevylučuji že z toho něco mohlo mít i pozitivní vedlejší efekt.
Ubuntu - Linux pro lidi, ale bisectovat už se mi to nechce :)
-
Hele ale to podle toho tvyho popisu rozhodne nevypada jako oprava ... za tohle dodavatelum normalne vyhrozuju vypovedma smluv. Myslim tim prave to, ze nejaky chovani ktery ta vec ma roky znicehoz nic zmenej.
Minimalne po nich vzdycky chci aby zaplaili vsechny upravy ktery kvuli tomu budou treba ... a ono je to prejde.
Protoze mi je jedno jestli je politicky spravne chovani A nebo B, me predevsim zajima, ze mi v tomhle pripade ten stroj jeste priste ... nenastartuje.
-
Njn. chápu přístup a taky by se mi to nelíbilo, kdyby mi po rebootu zůstal viset třeba nějaký server, co nemá out-of-band přístup a musel se k němu fyzicky dostavit.
Canonical má samozřejmě i podporu, myslím, že v té variantě za $1800/rok/server se jim dá zavolat nebo vytvořit "výhružný" ticket ( Mažu Tě, vole! :)) )
Ale samozřejmě nevylučuju, že jsem si něčeho dalšího nevšiml, tohle byl takový rychlý půlhodinový test, protože jsem byl zvědavý a předtím se mi nic podobného nedělo. Určitě by se dalo dohledat víc, ale chtělo by to mnohem víc času - procházení změn od Canonicalu, upstream Debianu, upstream jádra, kontrola těch superbloků hexdumpem, pak třeba i potvrzení s maintainerem. Navíc tam může být i interakce s dalšími věcmi okolo (udev, systemd, inicializační skripty v initrd).
Jak jsem zmiňoval, používám primárně jiné distribuce, co tím úplně netrpěly, a i tam mám většinou RAIDy uvedené v mdadm.conf, který nastavuji i kvůli monitoringu, mailu s notifikacemi atp. Stejně tak se ve fstabu odkazuju spíš na UUID nebo label oddílu, přesně kvůli tomu, kdyby se změnil devnode. Pokud by to bylo takhle nastavené od začátku, tak se nejspíš ani na Ubuntu nic nehne, resp. nezastaví start systému.
-
[...] většinou RAIDy uvedené v mdadm.conf [...] ve fstabu odkazuju spíš na UUID nebo label oddílu [...] Pokud by to bylo takhle nastavené od začátku, tak se nejspíš ani na Ubuntu nic nehne, resp. nezastaví start systému.
jeste sem se koukal a /etc/mdadm/mdadm.conf mam a v nem definovane md0 a nevzpominam si ze bych ho pripravil,
tak sem to chtel otestovat bez, smazal, pregeneroval initramfs, rebootnul a koukam /etc/mdadm/mdadm.conf mam opet a znovu s definovanym md0 a na konci si vsiml: "This configuration was auto-generated [...] by mkconf"
[...] za tohle dodavatelum normalne vyhrozuju vypovedma smluv. Myslim tim prave to, ze nejaky chovani ktery ta vec ma roky znicehoz nic zmenej.
[...] me predevsim zajima, ze mi v tomhle pripade ten stroj jeste priste ... nenastartuje.
Trochu se hod do klidu ;-) uvedom si ze reagujes na Ubuntu kde ocividne tazatel podporu neplati, nema s zadnym dodavatelem zadnou smlouvu, nikomu ani za ten "SW" nic neplati, atd...
Druha vec je ze zmena mdX = nenabootuje je velmi omezena moznost a to velmi omezeneho admina:
predpokladam ze kdyz nad tim bude LUKS a/nebo LVM, tak jim zmena vadit nebude,
takze jedina situace kdy by mohl nastart nefunkci reboot, je kdyz by v fstab bylo uvedeno /dev/md127, ale proc by to kdokoliv pricetnej delal, kdyz uz snad od minuleho tisicileti je pravidlo blokova zarizeni do fstab (ci cmdline) uvadet pres UUID ktere se samozrejme pri zmene blokoveho nazvu nezmeni... (v pripade lvm pak klidne misto UUID /dev/mapper/vgname-lvname ci /dev/vgname/lvname)
-
jeste sem se koukal a /etc/mdadm/mdadm.conf mam a v nem definovane md0 a nevzpominam si ze bych ho pripravil,
Tak ja na tohle kdysi narazil u vanilla kernelu s autodetekovanym mdraidem (cti: bez initrd == ciste problem mezi diskem (superblokem) a kernelem) taky - tehdy ten problem, jestli si vzpominam, byl ten, ze se nejak divne rozpadl mirror pri HW padu, a superblok na jednom disku obsahoval neco, co nemel. Nakonec tehdy fungujicim resenim bylo (uz si nepamatuju presnej postup bez ztraty dat, prosim nezkousejte to bez zalohy...) trochu drsne --zero-superblock a znovu ten mirror znovu vyrobit.
-
Potvrzuji zmíněné chování, resp. změnu s 6.11.x.
Kolega Zdenek M. by rekl: klasicke pachani dobra :/
DIK ZA POTVRZENI!
Nastesti mam raid0 jako ryche velke odkladiste docasneho bordelu, takze i kdyz si ubuntu rekne o root password for maintenance, po chvili pozadavek zmizi (!) a objevi se logon.
MP
-
Trochu se hod do klidu....
Ja sem v naprostym klidu, jen dalsi dukaz toho, ze tux je presne stejna sragora jako widle. Support zadnej v obou pripadech, jakejkoli svepravnej pristup taky neexistuje ...
Mimochodem, uz par let vpodstate presne stejne nefunguje grub(2). Generuje (grub-mkconfig) do konfiguraku neco takovyho ...
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 --hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2 22cf335...
A ma to jeden drobnej problem ... misto toho aby se pouzilo primarne to idcko partysny, tak se primarne pouzijou ty hinty. Ty nejde (hledal sem) nijak vypnout (naopak generovani toho idcka je treba zapnout).
Kdyz to pak zkombinujes se spravnou HW konfiguraci = vic disku, kde se ti ruzne meni poradi disku ... tak to pravidelne nenabootuje. Je treba ty hinty z toho vdycky odmazat aby nemel na vyber ... lol.
To samy jsou pak ty naprostonepredikovatelny nazvy sitovek ... ktery se ti taky zmenej kdykoli s cikoli na tom HW byt jen pohnes.
-
Nazvy typu /dev/md0 ci /dev/md127 podobne jako /dev/sda atd. nechcete pouzivat k identifikaci. Staci vytvaret pole nejak takto:
mdadm --create /dev/md/_name_ -l 1 -n 2 /dev/sdc1 /dev/sdd1
a presne cislo vaseho pole vas nemusi zajimat:
$ ls -al /dev/md/
total 0
drwxr-xr-x. 2 root root 120 Jul 18 2024 .
drwxr-xr-x. 23 root root 3740 Jul 18 2024 ..
lrwxrwxrwx. 1 root root 8 Jul 18 2024 boot -> ../md127
lrwxrwxrwx. 1 root root 8 Jul 18 2024 pool -> ../md125
lrwxrwxrwx. 1 root root 8 Jul 18 2024 pv00 -> ../md126
lrwxrwxrwx. 1 root root 8 Jul 18 2024 rest -> ../md124
Povsimnete si, ze /dev/md/boot a /dev/md/pv00 byly vytvoreny instalatorem.