Názory k článku
Linuxový BSoD s QR kódy v ukázkách

Pri takove velikosti QR kodu to uz fakt mohlo byt napsany textem a mobil umet OCR. Alternativne at se to posila na nejaky online koncentrator, kde to bude pod zkracenou url / hashem - a alespon nekdo bude moci sledovat pady vs verze jadra / hw.

Tohle mi prijde totalne k nicemu.

A ty servery pojedou na dobry slovo?

A co když jádro zpanikaří kvůli problémům se sítí?

Textové dumpy tu již byly. A protože byly k ničemu, máme tu toto. Pamatuji si mnoho diskuzí, kde byla fotka obrazovky a luštilo se z ní co se vlastně stalo... A bylo toho na několik obrazovek, přičemž často nebyla možnost skrolovat nahoru, takže se neluštilo, ale věštilo. A textová konzole již několik let nepodporuje skrolování, takže to ani není možné.

QR je dobrý standart, jak přenášet rozumně digitální data pomocí jednoduše přenositelné obrazové informace. Osobně toto vítám. Sice jsem kernel panic neviděl už dlouhá léta, ale jsem pro.

myslíš, že se toho sem vejde víc? Ten V40 QR kód na full hd rozlišení pojme tak 3000 bajtů (s kompresí to může být asi dvojnásobek), což tak nějak odpovídá tomu, co teď dumpuje kmsg na obrazovku.

Každopádně to je rozhodně lepší než to luštit z obrazovky a přepisovat.

Trošku tricky může být ta url pro zobrazení, nějaká být musí a na ní se mohou objevit různorodá data a jak znám potřeby některých sbírat cokoliv, tohle může být třeba pro Redhat nebo Canonical super zdroj nových metrik.

Také mi to přijde rozumné řešení, URL obsahuje celý dump a webová služba to jenom převede do textu.

Kdo ladi jadro ma vetsinou tyhle veci na seriaku.

V produkci musi byt veci, ktere kernel panic neprodukuji. Nestalo se mi, ze by experimental vetev gentofo vyhodila nejaky panic z distribuce - max jsem si ho zpusobil sam pri psani driveru.

Neprijde mi to o nic lepsi, nez vymyslet novej hashtag #qsod a sledovat kolikrat se objevi. Prakticky to totiz nic neresi, kdyz nejaky random koncak reportuje nejakou random chybu.

A vidite ze autor/ka neresila konkretni pozadavek, jen si chtela osahat rust v jadre. Nuz.. doufam ze nekoho napadne udelat clean&shiny de-rusted jadro.. protoze tyhle veci tam nemaj co plevelit.

Máš pravdu v tom, že cílovka tohoto je celkem malá. BFU nějaký kernel panic nebude řešit, vývojář to má pořešené jinak a sysadmin si to v případě potřeby taky nějak zařídí (pokud padne jednou, viz BFU a pokud bude padat soustavně, viz vývojář).

Navíc... jádro je mnohem stabilnější než dříve a kernel panic na desktopu jsem neviděl už... no hodně dlouho.

Panic na produkci samozrejme prijit muze - a muze jit treba o dusledek chyby HW. Je to nemile, ale stava se to. Samozrejme jsou i jine zpusoby, jak to i tam ulozit - treba pstore. Rozhodne se v takovych situacich hodi i z produkce posbirat co mozna nejvic info - a ten QR kod tomu muze dost pomoct - narozdil od vypisu na obrazovku, co casto rad odscrolluje, takze clovek zachyti jen cast.

Je moc hezké znovuvynalézat kolo.
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/kernel_administration_guide/kernel_crash_dump_guide

tak v produkty nám vyhazuje kernel panic např. chybný či poškozený HW, při tisícich serverch se vždy něco někdy najde.

Tohle ale asi je spíše pro malé uživatele, kteří si k tomu nemohou vybudovat vzdálenou správu a dozor.

Tohle je IMHO uloha to UEFI.

Kdysi hodne davno na RS/6000 to fungovalo tak, ze kdyz mel AIX kernel panic, tak to po rebootu "BIOS" poznal a na pasku zapsal cely core dump jadra a tepre pak az nabootoval system.

Proc neco takoveho PC architektura neumi? Navic ted kdyz je skoro kazdy server virtualni? Paska by se dala nahradit nejakym virtualnim diskem a UEFI by jednoduje zapsalo stack trace jadra na ten disk az behem bootovani.

Však umí a pěkně dlouho, viz ten link výše. Prostě když kernel crashne, swap je větší než raměť a zrovna to nepodělalo driver disku, tak se před rebootem nacpe RAMka do swapu, a při následném bootu appliance to z něj něco překopíruje do filesystému.

Trochu nemilé je pak ten dump (pokud v něm není něco, co nesmí z firmy) přenést k vendorovi, když je to trochu větší appliance no ;-) A taky ten reboot po crashi trvá poněkud déle.

4. 7. 2024, 21:12 editováno autorem komentáře

No a pritom nekdy staci ta hlaska, co se objevi v kernelovem logu. A to elegantne resi prave ten pstore. A nemusim slozite dumat nad tim, jestli mi s celym dumpem neutece nejaka citliva informace.... a krom jineho, take je to rychlejsi... toliko k tomu "znovuvynalezani" kola viz vyse :-)

Nemohu se vyjadřovat v jiných případech, ale zatím mám na tikety score 5:0 kernel dump vs krátký backtrace.
(nepočítám do toho ofc triviality na první pohled vedoucí k RMA disku)

Mimochodem, tušíte o tom, že z onoho kernel core se dá triviálně vytáhnout i ta samotná hláška, že ano? Takže se nemusí posílání konat.

To samozrejme vim. Preskocil jste ale tu jednu malickost... a sic, ze log se do pstore zapise rychlejc nez dump na disk :-) A pak je tu jeste jedna vec - LUKS a moderni KDF... co vyzaduji v zavislosti na parametrech vice RAM... no a tu musite na plnohodnotny dump mit v rezerve, tzn. ji jinak nepouzijete. Chapu vase nadseni pro dumpy, ale nekdy proste i jina cesta smysl dava... ;-)

První co by mě jako zloděje dat na ukradeném PC zajímalo by byl tento dump jadra, kdy tam vypíše syrová data.
Todle asi dlouho nebude, pokud se nevyřeší otázka bezpečnosti. Ono by bylo blbé sundat server a zjistit vlastně s čim máš dočinění a pak to jede rychleji než teď.
Ale ano bylo by to super... tam je ovšem to "ale"

Ten vektor útoku si představuješ jak?

Jakože před krádeží způsobíš kernel panic, počkáš na dump jádra, pak server odneseš a budeš zkoumat? To mi přijde zbytečně složité, vždyť už máš ten server.

Z dumpu by se dalo dostat třeba k šifrovacím klíčům pro disk nebo k privátním klíčům k certifikátům, co pak používají nějaké služby. Což bez znalosti prvního je mi celý server k ničemu a to druhé může být jen v paměti, protože je to distribuované nějakým nástrojem jen při spuštění těch služeb.