V jádře 6.10 bude počáteční podpora pro modrou obrazovku smrti (BSOD), nechvalně známou z Windows, kde se objevila v NT 3.1. Javier Martinez Canillas z Red Hatu v sobotu ukázal, jak bude modrá obrazovka smrti vypadat v Linuxu.
Jde zatím jen o počáteční podporu. Později se zde objeví QR kód, který bude označovat konkrétně chybu, ke které došlo. Pokud máte jádro 6.10, tak můžete vyvolat kernel panic pomocí echo c > /proc/sysrq-trigger.
(zdroj: phoronix)
Systém vypíše užitečnou informaci, ale aby byla jasně odlišená, vypíše ji na modrém pozadí. A přidá k tomu ještě QR kód, aby se ta informace snadno dala přenést jinam.
Jenomže... Ono tam really-human-readable vlastně už dlouho nic není. Nicneříkající trasovací informace, kde ta podstatná část odrolovala do ztracena... Nebo jen černá obrazovka a uživatel bušící do klávesnice.
Kolikrát jsem v diskuzi viděl fotky obrazovky, kde někdo fotil chybu jádra. Vše to bylo na několika fotkách, protože výpis byl dlouhý a stejně nic neříkající.
Když vás baví opisovat údaje z obrazovky na papír, tak si je klidně opisujte. Ale nebraňte lidem, kteří mají čtečku QR kódů, aby si ty údaje přenesli jinam efektivněji.
Když ten výpis nevidíte, nemusí vás trápit. Ale nebraňte v použití toho výpisu těm, kdo ho vidí.
To, že vy něco nevyužijete, fakt není důvod pro to, aby se to neimplementovalo.
QR kód je pro BFU, ti smartfouny mají.
Myšlenkový pochod: jádro může být kompilováno bez VT a FB, v tom případě se nyní nemá chyba jaksi kam zobrazit. S BSOD se zobrazí, BFU to vyfotí a vývojáři budou mít informaci o chybě, ne jen "se to zaseklo" a "nejede to".
Pokud v tom QR kódu bude rovnou celý stack trace, tak to všechna čest, to bude super novinka.
V 10-rocnom clanku na https://www.phoronix.com/news/MTY1NjI je o tom QR napisane viac. Je tam aj priklad s URL s GET parametrom obsahujucim gzipnuty stacktrace.
Proč ne? Aspoň pochopí, o co jde, i uživatel, který to zná z Windows. Patentovanou tu barvu snad Microsoft nemá.
Taky jedu nekolik stroju, vse si kompiluji sam, BSOD me nepotkava.
Posledni tvrdej kernel panic ani nepamatuji - ani behem vyvoje ovladacu pro vlastni PCIe/DMA hw na bazi FPGA. Obcas to v driveru padlo na nejakou dereferenci, ale nikdy ne tak aby to sejmulo system.
Oproti tomu stejny hw a cast sw spolecna - v prostedi Win jsem schopen dosahnout BSOD ciste jenom z toho co udela aplikace :D Ja vim.. jsem marnej koder.. ale ze win je tak labilni jsem neveril.
Já měl kernel-panic před týdnem. Ale šlo o moji chybičku v konfiguraci grubu. Vteřina údivu, trochu úlek co se stalo a za vteřinu vyřešeno i bez přemýšlení, stačilo přečíst co to píše. Kdyby mi napsal jen QR, asi by mě dost naštval.
Ta původní černá obrazovka mě štve tím, že se mi nedaří posunout zpátky k tomu co ujelo nahoru a že se nedá jednoduše restartovat nějakou klávesou. Aspoň na tom noťasu to nešlo.
Tak jde nastavit, aby po panic sám restartoval do třeba 30 sekund: kernel.panic=30 v sysctl.conf anebo panic=30 v příkazové řádce jádra.
Sysrq+B by to mělo přestartovat, jestli není zakázáno.
Konfiguraci pro případ kernel panic je potřeba mít nastavenou dopředu – protože až to nastane, je pozdě na nastavování. Většina lidí (včetně mne) na to přijde praktickým pokusem – třeba když sedíte u terminálu „na to přece byla nějaká zkratka s asi 5 klávesami zahrnující SysRq, <vygooglím na jiném zařízení>, proč to nefunguje?, <googlím>, aha, ono to musí být předem zapnuté“ :-) Podobné je to třeba s konfigurací pro případ, že si odříznete přístup na firewallu, nebo záložní kernel v Grubu.
