Ztracené PATA disky na řadiči JMicron a kernelu 3.2.12 a novějším

Mým hlavním systémem je stále Ubuntu 10.10 Maverick a abych si užil trochu legrace, nacpal jsem do něj kernel 3.2.12 z Ubuntu 12.04 Pinďolín. Popravdě, hlavně jsem chtěl vylepšit odezvu systému při zatížení, kterou má obstarávat věhlasný zázračný patch scheduleru a který má Ubuntu v kernelech už od verze 11.04. Nicméně se nejprve dostavila ta legrace - přestal se ozývat můj starý paralelní disk Hitachi. Kernel ho vůbec nepřipojoval. Zkusil jsem nainstalovat ještě další kernely, včetně nejnovějšího 3.3.0 a zjistil, že problém se vyskytuje od kernelu verze 3.2.12 výš.
Problém souvisí s ASPM (pozor neplést s Amatérským Sdružením Profesionálních Muzikantů :). Špatná detekce této technologie způsobovala nadměrnou spotřebu energie a protože to souviselo s nestandardním chováním postižených komponent, tak se nějakou dobu vymýšlel snesitelný patch. A ten se dostavil, což dokumentuje zpráva na rootu.
Jenže v souvislosti s tímto patchem se dostavila i špatná komunikace se staršími PCI-E řadiči JMicron při vypnutém ASPM, která způsobuje odstřihnutí PATA disků. Mám základní desku Gigabyte EP45-UD3P. Pokud 'ručně' ASPM na PCI-E zapnu, disky začnou být pro kernel opět viditelné.

sudo nano /etc/default/grub

přidat pcie_aspm=force na správné místo:

GRUB_CMDLINE_LINUX_DEFAULT="pcie_aspm=force"

a samozřejmě grub aktualizovat

sudo update-grub

Vypnuté ASPM není tou pravou příčinou, to bylo v mém případě vypnuté vždy -> `disabling ASPM on pre-1.1 PCIe device'. V tomto ohledu se tedy nic nezměnilo, a zkusím ještě popátrat, nicméně uvedené řešení funguje, žádné negativní důsledky nevidím a tak jsem spokojen. Relevantní je třeba tento odkaz:
https://lkml.org/lkml/2012/3/23/27

Update: Nakonec po zapnutí ACPI režimu v BIOSu se začal disk připojovat normálně, předtím jsem fungoval v režimu IDE emulace.

Jinak musím říct, že nový kernel běhá pěkně a vypadá to, že zázračný patch je nejspíš opravdu užitečný. No však to povídal i sám velký Linus.

OpenOffice - dokument byl zamknut bůh ví kým

Stává se mi to poslední dobou docela často nejen v OpenOffice, ale i v LibreOffice (což jistě nepřekvapí). Najednou mi to začne při otevření dokumentu hlásit, že ho nějaký neznámý hovád zamknul a nemůžu s ním vůbec nic, jen ho otevřít, případně vyrobit kopii. Stalo se i to, že se OO tvářil jako by nic, i progress bary kreslil při ukládání a pak to příště otevřu a v dokumentu poslední změny chybí! A dál se s ním nic dělat nedá. Ať už je příčina jakákoliv, tyto situace ve mě vyvolávají touhu někoho uškrtit. Ne, umlátit gumovou hadicí. Každopádně je to velmi nepřátelské gesto a uživateli se nedostane žádného vysvětlení ani řešení - soubor je zamknutý neznámým individuem a tak to zůstane na věky. Ámen. To, že soubor smažete a vytvoříte nový vám nepomůže. A proč? Protože nějaký šašek vedle vyrobí soubor s názvem toho vašeho, na začátek přidá '.~lock.' a pak ho už nesmaže. Tečka na začátku značí skrytý soubor, takže si ho jen tak nevšimnete, nicméně v Nautilu stačí stisknout Ctrl+H a objeví se. A pak ho s chutí smažete a svět zas začne vypadat lépe. Možná. Při poslední takové události mi došlo místo na systémovém disku a LibreOffice blbnul i po smazání locku, vlastně vyráběl zámky stále nové. Když jsem místo uvolnil, začalo to fungovat. Takže je dost možné, že tento bug souvisí i s tímto problémem.

No a když už jsme u toho místa na disku, po pár updatech kernelu je největším žroutem adresář /usr/src. Jeho obsah je po dokončení updatu zbytečný, ale statečně žere stovky MB.

Další hrátky s okny

Již jsem tu párkrát zmínil a použil program wmctrl, který se dá do Ubuntu nainstalovat ze základních repozitářů. Součástí systémů založených na X serveru bývá již v základní instalaci pár dalších zajímavých nástrojů pro manipulaci s okny...

Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap"

V češtině: Gtk-WARNING **: Nelze nalézt systém motivů v module_path: "pixmap".
Tuhle chybu mi vypisovaly v Ubuntu 11.10 GTK 2 aplikace při startu. Je to jen varování a na funkci rostlináře nemají vliv, ovšem vypadá to blbě, zvlášť, když to vypisuje i má aplikace. Vyřeší to následující příkaz:

sudo apt-get install gtk2-engines-pixbuf

Sedy, lehy, regulární výrazy 1

sed, awk, grep a jiné pěkné cli nástroje pro zpracování textu umožňují použití regulárních výrazů, což jsou takové masky, kterými můžete definovat řetězec, který v textu hledáte. Základy znám, ale každou chvíli objevím něco nového, co mi uniklo, protože zas tak svědomitě jsem to nestudaval. A tak bych chtěl začít seriálek, ve kterém bych si tyto objevy zapisoval.

Tak například dneska jsem se opět připletl k něčemu, co mě donutilo trochu posunout znalosti. Šlo o parsování xml dokumentu pomocí sedu a tím zajímavým je vytípnutí výrazu mezi dvěmi uvozovkami. Vzhledem k tomu, že regulární výrazy jsou od přírody žravé a tak těžko vytípnete řetězec v uvozovkách něčím jako toto: var=".*" , když je na řádku těch uvozených výrazů více, potřebujete něco lepšího. Pomohou htanaté závorky, kterými je možné definovat povolené znaky, ale pomocí znaku ^ (stříška), je možné výběr invertovat a definovat tak zakázané znaky. Proto uspějete s následujícím výrazem:

echo '<location altitude="307" latitude="50.92139" longitude="15.07974" geobase="geonames" geobaseid="3076124" />' | \
sed -n 's/ *<location .*latitude="\([^"]*\)".*/\1/p'

50.92139

Pokud nevíte, kulaté, zpětným lomítkem escapované závorky definují subvýraz, na který můžete dále odkazovat pomocí výrazu \1, a pokud je takových subvýrazů více, jsou číslovány podle výskytu zleva do prava.

Spouštěcí skript a opět Launcher

Další poznámky z mého bastlení. Občas je před spuštěním aplikace potřeba z shellu nastavit nějaké ty proměnné prostředí. Pokud nemáte pevně dané umístění aplikace, ale znáte pouze její relativní umístění vzhledem ke spouštěcímu sktiptu, může si skript tuto cestu jednoduše odvodit. Je-li ve stejném adresáři, jako aplikace, kterou spouští, může spouštěč vypadat třeba takto:

#!/bin/sh
export UBUNTU_MENUPROXY=
cd "` dirname "$0"`"
./aplikace "$@" &

Proměnná $0, obsahuje řetězec, kterým byl skript volán, může to být například ./Desktop/adresář/aplikace. Příkaz dirname z cesty odstraní vlastní jméno skriptu, a ponechá cestu. Ať už je cesta relativní, vztahující se k aktuálnímu pracovnímu adresáři, nebo absolutní, příkazem cd "` dirname "$0"`", změníte pracovní adresář na ten, ve kterém se nachází skript, ze kterého příkaz voláte. Absolutní cestu pak můžete získat příkazem pwd.

Následující text doplňuje můj předchozí příspěvek Quicklisty - problém se zdvojováním ikon a souvisí právě s tématem spouštěcího skriptu.
Nazvu například pythonní skript aplikace a spouštěcí skript aplikace-spouštěč. Desktopový spouštěč, umístěný v Unity Launcheru, tedy odkazuje na spuštěcí skript, který dále spustí aplikaci a sám chcípne, protože jsem aplikaci nechal spustit na pozadí příkazem &. Stane se to, že si Launcher nedokáže spojit hlavní okno aplikace se skriptem, který spustil a vytvoří pro okno novou ikonu. Tak si říkám "třeba to jen nestihne.." a přidám na konec skriptu sleep 5. Hle, není úplně hloupý, zabralo to. No jo, ale jen pokud spustím aplikaci poklepáním přímo na ikonu. Při spuštění z menu quicklistu, se ikona opět vesele zdvojuje, stejně jako jsem popsal ve výše zmíněném příspěvku. Dále tedy zařazuji základní myšlénku, že když se budou spouštěč i aplikace jmenovat stejně, bude se i proces jmenovat stejně a to by mohlo něco řešit. Samozřejmě je nemůžu mít v jednom adresáři, tak vytvořím podadresář launcher, spouštěcí skript nacpu tam a doplním příkaz pro přesun do nadřazeného adresáře:

#!/bin/sh
export UBUNTU_MENUPROXY=
cd "` dirname "$0"`"
cd ..
./aplikace "$@" &

A sláva, funguje jak má, i bez sleepu. Cairo Dock ikony také nezdvojuje, ale zase registruje pouze první instanci a další vesele ignoruje. Je to zkrátka legrace :)

Zkoušel jsem předtím operovat i s parametrem StartupWMClass, kterým můžete v desktopovém spouštěči určit třídu okna, která k němu patří, ale to v mém případě řešení nepřineslo.

Jak se zbavit indikátoru pro přepínání uživatelů

Pokud v Ubuntu 11.10 s Unity nepoužíváte více uživatelských účtů a nezajímá vás ani účet pro hosta, není od věci uvolnit trochu místa v horním panelu a zakázat indikátor pro přepínání uživatelů. Zvláště na pidiobrazovce netbooku, kde se dá místo využít rozumněji. Stačí editovat jeden soubor:

sudo nano /etc/lightdm/lightdm.conf

přidat na konec řádek:

allow-guest=false

a restartovat LightDM (Ctrl+F1, přihlásit a spustit příkaz: sudo service lightdm restart), nebo rovnou celý systém.

Quicklisty - problém se zdvojováním ikon

Quicklisty v doku jsou fajn výmysl. Jak se dají tvořit popsal třeba Vojta Trefný v článku Deset tipů pro zlepšení Unity (a jeden můžete vidět i o pár řádků níž u mého předchozího článku), chybí tam však jedna podstatná věc. Alespoň v případě aktuálního Ubuntu 11.10. Nějaká moudrá hlava vymyslela, že spouštěče v home adresáři se budou chovat jinak, než ty v /usr/share/.. a tak můžete narazit na množení ikon v Unity Launcheru, pokud jen překopírujete spouštěč ze systému do home adresáře a doplníte quicklist. Spustíte aplikaci a místo aby se u ikony udělala šipečka, objeví se nová ikona kus vedle. I se šipečkou :) Ta už další okna sdružuje, ale zkrátka se distancuje od hlavního spouštěče. Pak je třeba naopak něco ubrat a oním problematickým řádkem je tento:

OnlyShowIn=GNOME;Unity;

Takže vůbec vlastně nejde o ty quicklisty :)

Další update uspávače pecí

Tak konečně, po skoro půlroce, dodávám další verzi nejskvělejšího linuxového časovače pro uspávání pecí a spouštění čehokoliv - Shutdown GTimer 0.3.6.

Novinek není moc, nejzásadnější je podpora quicklistů, která přenáší uložené předvolby do spouštěče v Launcheru Unity, ale podporuje je již celá řada dalších doků, včetně Cairo Docku. Ten je ale zatím nutno po přidání předvolby restartovat, aby se změna projevila, v Launcheru se aktualizuje ihned. Plánované cli rozhraní tedy zatím nabízí pouze jeden parametr v podobě jména předvolby, která se má po startu načíst. ...

Nautilus 3 je opravdu trochu jiný

Nedá se nic dělat, musím si zas postěžovat. Konstruktivně samozřejmě :) Nový Nautilus se chová v mnohém trochu jinak, než jeho předchůdce a rozhodně mi naboural navigaci. Pokud z nějakého důvodu použijete pro práci se soubory výchozího správce souborů GNOME, stále je efektivnější držet se klávesnice, než myši. V dvojkovém Nautilu otevřu adresář a dál se naviguji postupným psaním jména podadresáře (pokud ho znám), kam potřebuji. Nalezený adresář odentruji, tedy otevřu, a psaním pokračuji dále. Když se spletu Backspacem poslední písmeno smažu. A najednou je tu Nautilus 3 a všechno je jinak. Dobře, ne všechno, ale dost na to, aby mě to na..štvalo. Takže začnu psaním vyhledávat adresář, Enterem ho otevřu, píšu další adresář a... prdlačka. Co to kur..nik je? Vyhledávací políčko po otevření adresáře nezmizelo, jak jsem očekával, ale zůstalo i se svým obsahem a tak jsem zadáváním dalších znaků nemohl uspět. Kur..nik, říkám si, a začnu automaticky mačkat klávesu Backspace. Co to kur..nik zase je? Aha, vím, že Backspace v novém Nautilu supluje chybějící navigační ikonu "přejít k nadřazenému adresáři", ale i když jsem v textovém poli vyhledávání? Paráda, takže nemůžu mazat a když otevřu adresář, musím stisknout klávesu Escape (nebo jako retarda chvilku počkat, až to vyhledávací políčko samo zmizí), abych mohl pokračovat. Nezdá se mi to chytré. No co, vždy se dá ještě stisknout Ctrl+L a v adresním řádku nového Nautila je vše při starém. Když jsem (letmo) hledal bugy na toto téma, našel jsem pouze dřívější problémy s tím, že po otevření podadresáře nešlo už psaním vyhledávat vůbec. Nicméně i stávající chování považuji za bug, takže to případně zkusím ohlásit.

Těch drobných změn souvisejících s přechodem na GNOME 3 je víc, ventilovat bych chtěl příště přinejmenším vytváření rozšíření pro Nautilus 3 v Pythonu. Ale ještě tomu musím přijít pořádně na kloub, na stránkách gnome.org je dokumentace.. není :)

Jak zatočit s login znělkou v Ubuntu

Když restartuji Ubuntu (virtuální poměrně často) v noci, nejsem z ubuntí znělky zrovna nadšen. Tím méně mé okolí. V zásadě má hlasitější projev, než cokoliv jiného, co poslouchám a vůbec nejsem příznivcem nevyžádaných zvukových projevů počítače. Ubuntu používá přinejmenším od verze 10.10 skrytý spouštěč v podobě následujícího souboru:

Cairo Dock 2.4 místo Unity Launcheru?

Před pár dny jsem restartoval  mou domácí pec (samozřejmě nedobrovolně) a po spuštění systému nereagoval Cairo Dock na můj skript, kterým přes tlačítko myši ovládám jeho viditelnost. Zároveň se nad dokem objevila notifikace o změnách v nové verzi, mezi nimiž svítilo i DBus, což dávalo tušit, kde je problém. A změna metody ShowDock konečně přinesla to, co mi v Cairo Docku chybělo hodně dlouho - přepínat mezi stavy Show/Hide. Do verze 2.4 bylo možné dok schovat, nebo zobrazit, ale už né jednoduše stav prohodit, nebo alespoň zjistit, v jakém stavu se aktuálně nachází. Nově bere metoda místo boolean parametru integer a krom jasných 0 a 1 akceptuje i číslo 2, které změní sučasný stav na opačný. Volání metody z příkazového řádku vypadá takto:

Počítání sezení s ConsoleKit em

Řešil jsem problém, který spočívá v tom, že pokud je v systému přihlášeno více uživatelů než jeden, vyskočí při pokusu o vypnutí/restartování systému požadavkem na službu ConsoleKit (nevím na koho mocnějšího se obrátit :) okno, které chce akci autorizovat heslem superuživatele. Stačí se v některém terminálu přihlásit jako root pomocí příkazu sudo su (rozumnější sudo -i, sudo -s, nezakládají další session) a můj Shutdown GTimer nesplní svůj úkol. A vzhledem k tomu, že okno System policy po chvíli samo zmizí (alespoň v některých verzích Ubuntu), tak pokud není uživatel očima na monitoru, ani se nedozví proč. V nové verzi by měl být Shutdown GTimer schopen předem na tuto skutečnost upozornit. Tato systémová politika je funkční přinejmenším od Ubuntu 10.04 výš, verze 8.04, kde vypnutí systému ještě řeší HAL, toto omezení neplatí, alespoň pokud jste v rámci GNOME session přihlášeni v emulátoru terminálu jako root.

Služba ConsoleKit je správcem sezení (sessions) a tudíž je to zase ona která dodá informaci, kolik sezení je aktivních a tím zda se dá systém vypnout bez požehnání vyšší moci. Tedy služba dodá seznam, který je nutno spočítat. Šel jsem na to klasicky přes DBus, v příkazovém řádku je dotaz možno formulovat takto:

dbus-send --system --print-reply --dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.GetSessions | grep Session | wc -l

nebo takto (vzhledem k tomu, že pro každé sezení založí ConsoleKit uzel (node), který odkazuje na metody a signály určené pro jeho správu):

dbus-send --system --print-reply --dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit org.freedesktop.DBus.Introspectable.Introspect | grep Session | wc -l

Pro ConsoleKit jsou ovšem v systému pro příkazový řádek přímo příkazy, které se používají jednodušeji a výstup je již formátován, bez xml značek. Příkaz ck-list-sessions vypíše všechna sezení, včetně jejich atributů. Z výpisu lze vyfiltrovat počet sezení takto:

ck-list-sessions | grep ^Session | wc -l

ConsoleKit toho z příkazového řádku nabízí více, můžete si třeba zkontrolovat historii sezení a zjistit, že se vám díky nedostatečně zabezpečenému ssh serveru někdo několikrát naboural do systému :D Více třeba zde:

http://wiki.ubuntu.cz/ConsoleKit 

V Pythonu to samozřejmě řeším bez shellu, ale princip je stejný, navíc tam mám možnost se pověsit na signály, které jsou ConsoleKitem generovány při přidání, či odebrání sezení a na jejich základě aktualizovat stavovou informaci. Pro další verzi Shutdown GTimeru si ale vystačím s detekcí více sezení při aktivaci odpočtu v režimu Vypnutí a Restartu, málokdo asi při tomto použití ocení upozornění o změně situace v průběhu odpočtu. Ještě mě teď napadlo, že pokud spustíte Shutdown GTimer jako root, zmíněné omezení samozřejmě neplatí a tudíž musím v kódu podchytit i tuto situaci. Tak snad brzy, první nástřely jsou již v svn.

Identifikace USB disků podle typu připojení

Nedávno jsem narazil na problém jednoho uživatele, který chtěl svým dvěma nesystémovým pevným diskům změnit po startu systému přes hdparm chování, ale ty se mu pokaždé připojují jinam v /dev/sd*., a tak neví jak napsat skript, který by je přesně identifikoval. Chvíli jsem se na tím zamyslel, jak napsat nějaké univerzální řešení pro vypsání všech interních pevných disků, které zároveň nejsou systémové. Vzhledem k tomu, že na mých počítačích se nachází krom zmíněných pouze USB disky, napadlo mě tyto identifikovat podle způsobu připojení a z výpisu je vyřadit. Pak už zbývá jen identifikovat disk, na kterém běží systém. Dospěl jsem se svými znalostmi k následujícímu:

find /dev -regex /dev/sd. | while read dev; do if ! udevadm info -n $dev -q path | grep -q usb; then mount | grep -q "$dev. on / " || hdparm -S60 $dev ; fi; done

Tento příkaz nastaví diskům podle předchozí specifikace dobu pro uspání při nečinnosti na 5 minut (hdparm -S60 - 60x5 sekund=5minut). Kdyby to někdo z příkazu nepobral - find najde přípojné body všech disků, výstup se čte řádek po řádku a pro každý disk se nejprve zkontroluje ve výstupu udevadm -n zda je připojen na USB sběrnici a pokud není, další pomínka v podobě výstupu příkazu mount pošle příkaz hdparm -S60 pouze na disky, na kterých není kořenový adresář běžícího systému.

Seznam pouze USB disků pak můžete dostat takto:

find /dev -regex /dev/sd. | while read dev; do udevadm info -n $dev -q path | grep -q usb && echo $dev; done

Pokud chcete s disky cokoliv rovnou provést, nahradíte echo konkrétním příkazem, stejně jako v minulém příkladě.

Další možností by mohlo být vypsání všech připojených filesystémů USB disků i s přípojnými body, včetně parametrů:

find /dev -regex /dev/sd. | while read dev; do udevadm info -n $dev -q path | grep -q usb && mount | grep $dev; done

Sluchátka Creative EP-630 - ujdou

Špuntová sluchátka jsem dlouho odmítal kvůli jejich špuntovosti, nicméně nedávno jsem jim dal znovu šanci a nakonec i milost. Nesmíte s nimi běhat a jíst, ale jinak jsou snesitelná a ve veřejné dopravě jsou daleko účinnější, oproti klasickým peckovým sluchátkům. Zkusil jsem Creative EP-630, které jsem dostal za nějakých 150Kč, zatímco normálně se dají koupit kolem 400Kč, a nemohu říct, že by mě zklamala. Recenze se na ně dají sehnat veskrze pozitivní a musím i já přiznat, že za tu cenu (i tu běžnou) jsou velmi dobrá. Nízké kmitočty umí hrát údajně od 6Hz a faktem je, že basy trochu preferují, je jich hodně a jsou lehce rozplizlé, osobně bych uvítal méně dunivé a o něco pevnější basy, ale není to taková tragédie. Střední kmitočty a vokály podávají tyto Creativy příjemně a výšky jsou solidní, stejně jako prostor. Pokud jim předhodíte mainstreamové nahrávky, keré trpí nemocí z komprese, budete nejspíš spokojeni. V porovnání s mými domácími Senheiser HD 595, které stojí víc než desetkrát tolik, produkují EP-630 na těchto pomrvených nahrávkách opravdu příjemnější zvuk. Ty Senheisery si zkrátka moc nevymýšlí a tak se dozvíte i to, co nechcete. Dnešní nahrávky zní většinou lépe na sluchátkach, která kašlou na nějaký analytický přednes. Na kvalitních sluchátkách (reprobednách) budete z většiny nahrávek zklamáni, či spíše znechuceni (pokud nejste hluší), je to záležitost masteringu, který se soustřeďuje na hlasitost a při tom kurví dynamiku. Především u rocku, nedej bože metalu, je to peklo, všechno se to slije do nechutné agresivní sračky. Po pár minutách poslechu takových nahrávek mám pocit, že musím sluchátka servat z hlavy a hodit s nimi o zeď. Popravdě bych raději o zeď hodil těmi hovady, co takové nahrávky vyrábí. Sluchátka mohou utrpení trochu zmírnit a té agresivity ubrat a u EP-630 takový pocit mám, i ty nejhorší nahrávky podávají tak nějak snesitelněji a čitelnost jednotlivých nástrojů i vokálů je solidní. Ovšem ve chvíli, kdy jim předhodím opravdu kvalitní nahrávku, především akustické nástroje, je to slabší. Tedy v porovnání se zmiňovanými Senheisery HD 595, které hrají kvalitní nahrávku například Dire Straits (album Dire Straits), nebo Rebeccu Pidgeon (The Raven), naprosto lahodně, EP-630 dodají nepříjemnou bahenní příchuť. Zkrátka pro přenosná zařízení nevalných kvalit a nechutně komprimované nahrávky, jsou velmi dobrá a to bude jejich úkol.

P.S. Kompresí nemyslím ztrátové komprimační algoritmy MP3 a podobné, ale kompresi dynamiky, která vede k celkové vyšší hlasitosti nahrávky a je produktem nahrávacího studia, které ji vytvořilo. To že to stáhnete z CD do bezztrátového formátu FLAC, vám nepomůže, podělaný je už zdroj.