Reinstalace Debianu, přechod ze stable na testing

2.3.2014 19:59 | Přečteno: 986× | poslední úprava: 3.3.2014 17:56

Debian po přechodu na novější kernel odmítal připojovat RAID (na kterém jsem měl i kořenový adresář) a nedávno začaly všechny GTK aplikace padat při otevření open/save dialogu. To druhé se stalo po dist-upgrade na Debian Jessie. Protože ve Virtualboxu fungovalo vše správně, rozhodl jsem se pro reinstalaci.

Problémy jsem zkoušel řešit, ale úspěchu jsem nedosáhl. Stručně řečeno, GTK2 aplikace (Firefox, GIMP) se stylem Atolm stále padají při otevření open/save dialogu. U GTK3 aplikací (Evince) se zdá, že se problém neprojevuje. Podle některých zdrojů je potřeba doinstalovat nějaké asijské fonty (v distribuci jsem zmíněný font nenašel), jiné doporučují změnu GTK stylu. Prozatím jsem přejmenoval adresář .themes v domovském adresáři a jedu bez stylu.

Ano, přizpůsobím se, co mi zbývá. Nelíbí se mi ale, že bez problémů fungující GTK2 styl (používám určitě něco přes rok) po aktualizaci GTK (z větve testing) začne shazovat všechny GTK2 aplikace. Opravdu se aktualizací nadobro odepíše nejeden GTK2 styl a uživatel musí hledat náhradu, která může za další měsíc také přestat fungovat?

 

Ohledně problémů s kernelem, z diskuze vyplynulo, že na vině bude zřejmě konfigurační soubor mdadm.conf, nebo generování initrd. Fakt je ten, že:

- Dříve se initrd vygeneroval správně pro kernel, který jsem zrovna používal - 3.2.0. U dalších kernelů ale docházelo k tomu, že RAID nenaběhl. Konfigurační soubor jsem mezitím nijak neupravoval.

- To samé se stalo i po čisté instalaci Debianu Jessie, vše proběhlo v pořádku, ale raid se nepřipojil

- Je zvláštní, že ve VirtualBoxu funguje vše hladce.

- Chybová hláška je konkrétně:

mdadm: No devices listed in conf file were found.

 

---

Zároveň bych se chtěl omluvit všem, kteří museli číst původní verzi zápisku. Poslední dobou jsem trochu podrážděný a musel jsem to ze sebe nějak dostat. Uznávám že vylívat si zlost v blogu není dobrý nápad a nehezky jsem se tím potrestal (pro někoho už jsem troll). Kdyby to mimochodem někoho zajímalo, tak mě dráždí hlavně dvě "drobnosti":

- práce - v prosinci jsem byl odvolán abych šel pomáhat na druhou dílnu, údajně do konce roku, potom jsem se měl vrátit na elektrodílnu. Místo toho vedení na začátku ledna rozhodlo, že budu na strojní dílně pracovat do konce března (později změněno na konec dubna) na dvě směny včetně sobot. Po dvou měsících toho máme všichni dost, termín se nestíhá, někteří pracovníci z kanceláří (i ti se museli zapojit do procesu) pochybují, že se na svá křesla ještě vrátí. A mechanik-elektronik místo jeho oblíbené práce brousí a leští nerez

- PC - protože přítelkyně nebydlí zrovna za rohem, tak je pro nás nejlepším komunikačním prostředkem internet, i když i tam se zřídkakdy sejdeme. A teď si představte, že po instalaci systém nebootuje. To bych se pak ani netěšil z práce domů.

       

Komentáře

[Josef Kufner]

Gtk témata jsou kusy dynamicky loadovaného (dlopen) kódu, takže pokud je v tématu chyba, veme s sebou celý program. Použij nějaké rozšířené, staré a ozkoušené téma. Bude to vypadat slušně namísto dokonale, ale nebude to padat. Třeba takový Clearlooks není špatný a je i pro Qt (Cleanlooks).

[._.]

Zápisek sám o sobě je zmatený, jedno naházeno přes druhé. Nevím o co bloggerovi vlastně jde, jedině snad o trollování.

Debian stable funguje dobře. V případě potřeby se do něj dají nainstalovat jednotlivé aplikace z větve testing nebo unstable.

Kernel rozumný člověk povyšuje jen tak, aby systém fungoval. Osobně používám pouze jedno téma vzhledu, a to pochopitelně výše doporučený Clearlooks.

[Dreit]

Omlouvám se, nějak mi povolily nervy a musel jsem to ze sebe dostat. Šlo mi hlavně o to, že:

- dříve nebyl problém upgradovat kernel a vše bylo ok, od nějaké aktualizace mi ale fungoval jen jeden kernel a to 3.2.0 - protože používám OSS ovladače grafiky, tak jsem chtěl zkusit 3.12, kde údajně došlo k nárůstu grafického výkonu. Najednou jsem se ale dostal do situace, kdy nešel Debian nabootovat a fungoval jen s jedním kernelem

- GTK aplikace byly vždy bez problémů, ale po natažení části GTK z větve testing začaly padat jak ovoce. Styl používám pořád stejný, GTK2 i GTK3, mám pocit že se jmenuje Atolm3. Dřív se to nedělo a nelíbí se mi, že nějaká aktualizace GTK není ošetřená tak, aby aplikace nepadala se starým stylem.

 

Jsem si samozřejmě vědom, že chyba je někde mezi klávesnicí a židlí, ale proč to dříve fungovalo a teď ne?

[Max]

ale po natažení části GTK z větve testing začaly padat jak ovoce

A tomu se divíš? Míchat větve se nevyplácí (resp. je blbost to dělat), buď jedu čistě stable, nebo čistě testing.
Zdar Max

[pavlix]

Při míchání větví už se spálil nejeden člověk. Místo kupy hnoje by měl do blogu napsat stokrát po sobě: „Už nikdy nebudu míchat stable a testing.“

[Josef Kufner]

Já mám docela dobré zkušenosti s mícháním stable, unstable a experimental. Stable je stable a experimental se rychle opravuje, unstable se zas vcelku málo rozbíjí. Jen ten testing mi přijde jako nejhorší možná volba. Stable to není a opravám to trvá dlouho.

[pavlix]

Já mám docela dobré zkušenosti s mícháním stable, unstable a experimental.

Já osobně nevidím problém s tím, že to někdo používá a umí to používat. Jen bych to obecně uživatelům nedoporučoval, protože jediným výsledkem je velké množství frustrovaných jedinců, kteří navíc mají pocit, že za jejich neúspěchy může Debian.

[w4rr10r]

kteří navíc mají pocit, že za jejich neúspěchy může Debian

No a ne, když notoricky obsahuje i v unstable některé zastaralé balíčky?

[pavlix]

Jak souvisí zastaralost některých balíku v unstable s problémy s mixováním stable a testing (a popřípadě i unstable), to teda opravdu netuším.

[Dreit]

Chtěl jsem přejít na testing, upravil jsem sources.list, apt-get update, apt-get dist-upgrade....a je to tam

[Max]

Ohledně toho pole, dle popisu to nevypadá, že by jsi si to pole definoval v "/etc/mdadm/mdadm.conf". V takovém případě se pak není čemu divit .
Definuj si pole v konfiguráku mdadm a přegeneruj si intrd, aby měl v sobě ten config a mělo by to svištět.
Zdar Max

[Max]

Jinak mdadm jsem podrobně rozebíral zde : novinky v mdadm, cache, bariéry.
Zdar Max

[Dreit]

Já hlavně předpokládal, že když je / na RAID oblasti, tak se do /etc nic nedostane dřív, než se RAID připojí. Že se to nějak sype do initrd mě nenapadlo, GNU/Linux neznám až tak dobře

Jen mě zaráží, proč se to tak neudělalo už během instalace. Čekal bych, že čistá instalace připraví systém tak, aby první start proběhl hladce (jako tomu bylo předchozích 8 let, kdy jsem s tučňákem neměl po instalaci snad nikdy problémy).

[Max]

Já hlavně předpokládal, že když je / na RAID oblasti, tak se do /etc nic nedostane dřív, než se RAID připojí..

Také, že ne. konfigurák se při generování initrd vkládá do něj. Načte se tedy kernel s initrd a jsou tak v ramce všechny potřebné údaje k nahození pole. V initrd většinou bývají kromě konfiguračních souborů také moduly (drivery k řadiči filesystému apod.).
Zdar Max

[Dreit]

Ha, jasně! To už dává smysl

Jen netuším proč to s jedním kernelem šlo a s dalším ne. Jakoby v době generování initrd pro starší kernel bylo všechno v pořádku a potom se to nějak rozhodilo. Nebo se při generování novějšáho initrd na RAID vůbec nebral ohled.

[Dreit]

Teď mě ale napadá, že to vlastně fungovalo i ve VirtualBoxu, jen na fyzickém stroji byly problémy. Otázka tedy spíše zní jak zjistit, co má být v souboru mdadm.conf a proč to ve virtuálu funguje a v reálu ne.

Hádám že bude potřeba chrootovat z LiveCD, zjistit UUID disků a nějak donutit initrd aby si všimnul RAIDu. Nezapomněl jsem na něco?

 

[O existenci initrd vím, jednou dobou jsem zkoušel i kompilovat kernel abych si rozšířil obzory, už to ale nějaký rok bude. Teď když se rozpomínám jak to fungovalo, tak to všechno dává smysl. Akorát moje paměť je mrška a na nějaký initrd jsem úplně zapomněl.]

[Max]

V mdadm.conf má být to, co jsem linkoval výše, tzn. názvy polí, verze metadat, počty disků apod., viz příklad :

mdadm --detail --scan
ARRAY /dev/md2 metadata=1.2 UUID=14640e9e:d1c30960:5b020607:1eecbc2b
ARRAY /dev/md3 metadata=0.90 UUID=1d4bfb10:2b00fef9:5b020607:1eecbc2b
ARRAY /dev/md5 metadata=0.90 UUID=1011cbb3:b48abbe7:5b020607:1eecbc2b
ARRAY /dev/md6 metadata=0.90 UUID=88018aa2:0d416a22:5b020607:1eecbc2b

Dále, proč ti to jde / nejde. Debian myslím standardně ještě mdadm.conf nepoužívá (teď bych kecal, nevím to jistě). Každopádně vždy to bylo tak, že se mdadm.conf nepoužíval a distribuce spoléhaly na autodetekci pole v kernelu. Jenomže, tato autodetekce má své mouchy a v posledních verzích už je ignorována čím dál víc a doporučuje s používat mdadm.conf nehledě na to, že ani nové verze kernelů nepodporují při autodetekci novější metadata, takže u nových verzí metadat ti ani nic jiného nezbývá.
Zdar Max

[Dreit]

Poprvé jsem si všiml, že mají dva oddíly spojené do jednoho RAID pole stejné UUID. Jdu si vytisknout tvůj článek a v práci ho zkusím během dne přechroupat, moc díky a počítej s tím, že se ještě budu ptát...pokud tě to teda nějak neobtěžuje.

[Honza Jaroš]

Mohlo by se hodit...

[Dreit]

Díky, bookmarknuto a vytisknuto

Akorát jsem si všimnul, že při dnešním ranním bootu opět vyskočila hláška, že v poli nejsou disky, přitom včera bylo vše OK a nijak jsem s tím nemanipuloval. Začínám mít podezření, jestli na to nemá vliv i nastavení BIOSu a podobných blbin

[kolcon]

jojo, bylo nedavno jedno kratke obdobi, kdy bylo generovani initrd rozbite (nepoznalo to raidy). Taky jsem na to narazil, cca po tydnu bylo opraveno...

[Dreit]

Díky za informaci. Já se teď snažím odhalit proč jednou initrd disky najde a jindy ne, je to opravdu zvláštní

[Dreit]

Ha, po odkomentávání řádku

DEVICE partitions containers

v

/etc/mdadm/mdadm.conf

a spuštění

update-initramfs -u

to vypadá nadějně. Při bootu už to všechny oddíly našlo. Uvidíme po pár rebootech, jestli to nebyla jen náhoda.