Portál AbcLinuxu, 1. května 2025 14:02
Pro GRUB už asi není 80x25 dost cool a tak se rozhodli, že budou autodetekovat VESA rozlišení. Škoda, že to občas úplně selže a uživatel má prd. Nainstaluju systém, rebootnu, temno. Bug už dva roky existuje.
Brownout v napájení a zhebnul nám DNS a DHCP server a nebootuje to. Nakonec se ukázalo, že je to tento bug. No co, stane se. Stačí přecvaknout KVM a zmáčknout enter, to zvládne uklízečka navigovaná po telefonu. Ne však, pokud tam je GFX a nějaké LCD Samsung. To totiž po připojení ukazuje jenom Out of range. Připravené rescue ze sítě nabootovat nelze, protože PXE boot řeší právě ten DHCP server, který zhebnul. Super.
(Proč to nenareportuju? Protože po mně budou chtít dumpovat DDC komunikaci s monitorem a rejpat se ve VGA BIOSu a na to se můžu vybodnout. Řešení mít robustní bootloader využívající jen to nejnutnější minimum je politicky neprůchodné.)
(Btw. je tu workaround, vytrhněte VGA kabel a nabootujte bez toho. GRUB nezdetekuje monitor a nastaví nejnižší mód, nějakých 640x480, a to pak už projde)
Nabootujete debianí instalátor, odentrujete první položku a… nic. Zátuh. Pokud totiž kernel zhavaruje ještě než se mu podaří převzít od isolinuxu grafiku, vypíše chybu na konzoli, která je ale jaksi překrytá budoucím framebufferem. Tohle se stane typicky když procesor nepodporuje všechny instrukce, pro které je kernel zkompilovaný. Nicméně tato informace je určena pouze pro experty. Běžným uživatelům stačí vidět, že to zatuhlo.
Splash (nebo alespoň quiet
parametr kernelu) jsou strašně důležité, znemožňují totiž uživateli vidět, co se se systémem děje, případně na čem se čeká a co zfaililo. Případně si sežerou password prompt, aby nešlo systém odemknout vzdáleně. Nebo alespoň při odemykání vypisujou hvězdičky, aby to měli lidi, co se vám snaží okoukat heslo přes rameno, jednodušší.
Autodetekce a zmena rezimu je zalezitost KMS, ale da se vypnout nebo nastavit na neco rozumnejsiho jako parametr jadru. Installer ze slackware treba vzdycky nabehne v "sane" textovym modu 80x25 a nabidne rezim pro vychozi boot. Kdyz ctu o problemech s Anacondou, GNOME3, NM nebo padajicima aplikacema tak mi pripada ze existuje jeste jiny linux. U Debianu me to ale prekvapuje.
Console je prezitekProč?
logy bootu kernelu a initu muzou vystrasitPak ten člověk nemá používat počítač.
splash je cool muzes se s nim chlubit na TwitteruJá bych se na Twitteru (kdybych ho měl) chlubil tím, jak mi počítače dobře fungují. Takhle se tam „chlubí“ uživatelé „nefunguje DHCP a ten kokot resuscituje půl hodiny server, protože ne neumí dostat na konzoli“.
Autodetekce a zmena rezimu je zalezitost KMSMluvil jsem o GFX v GRUBu. KMS mi zas tak nevadí, protože se problém stane až po spuštění kernelu -- při dalším bootu není problém v GRUBu napsat „nomodeset“. Ale s GFX není vidět ani ten GRUB.
I ty, Brute?, se přidám i s dalším, s čím možná nebudeš souhlasit :)
S grubem, jsem včera na schodech s kolegou říkla, že pro servery, (a vlastní PC :)) to chce oživit LILO, bo to je jednoduché a a splní to přesně tu práci co má zavaděč dělat a vždy stejně.
Pak tu máme systemd
, nic už není jednoduché a all-in-one, je to správné řešení, bo pak už jsou všichni v pr..li, bo kdo ovládá systemd, ovládá vetšinu…, mimochodem taky to není dořešené viz screenshoty v příloze, startuje to paralelně a jednou je to ok podruhé ne…, matoucí je jen výpis, po zmáčknutí klávesy, se tam zopakuje ten řádek, jak je vidět na druhém snímku…
Pak tu máme NM, který u mě tedy zatím vždy na serveru jen něco rozbil nebo život zkomplikoval, buď jeho chybou nebo použitím v distribuci, kravina je, že se musí říkat NE, místo aby se říkalo ANO managuj toto přes NM. Instaluje se i v CentOS jako spuštěný, a navíc název servisu s velkými písmeny vypadá divně. A def-facto pro běžné připojování NTB k wifi, je lepší wicd, velmi jednoduchá konfigurace, lehce přihoditelné skripty k danému spojení - jednou se zprovozní a jede, narozdíl od NM, kde se sem tam vyskytne dost divné chování, nejlépe když je uživatel 2000km daleko a nutně se potřebuje připojit k síti. Asi to budu zas zavádět…
Proč bych s tím neměl souhlasit?Bývá to vnímáno jako „už moc velké brblání“.
wicd jsem opustil, protože mi dekonfigurovalo drátový interface při ztrátě linku.Jakože pokud se vytáhl drát, tak zmizela jeho konfigurace?
ignore-carrier
popsanou v NetworkManager.conf(5)
.
Nijak jsem moc neřešil u NTB síť po káblu, ta je v 95 % všem ukradená…, a na většině serverů zas, chce mít člověk stabilní konfiguraci, která vždy stejně nastartuje a je lehce čitelná, takže tam nemá ani jedno (aspoň tedy někdo :))…
OT: Já osobně NM už nevěřím ani „ahoj“, je to dané tím, že se vypustí nedodělek agresivním způsobem s agresivním chováním, člověku to několikrát rozhodí sándál a otráví ho to na hodiny a je putna, že už 0.9.10 má rozumné chování (prostě má na několik let razítko), takže při prvním zádrhelu už automaticky vždy letí (kolem sebe, ho už ho vidím jen na NTB a ne všech, bo z jednoho jsem ho musel taky vypakovat, nevím co dělal si Wifi spojením, ale a WiCd běželo hned a bez problémů)… Já to auž ani nijak nezkoumám i radím, zkus si ho vyhodit(deaktivovat) a uvidíš, když tak si to vrátíš zpět…, Na mém desktopu (Debian Squeeze) jsem ho kdysi dávno
A myslel jsem si donedávna, že na svém NTB je to s ním v pohodě, a není to úplně pravda, 99 % času ano, ale pokud se pár krát přehodím s wifi na drát a zpět, tak se dostanu na N-ku pod AP a gigabitu pod 10Mbit a a chvílemi to snad ani neběží (jako by se to furt vypínalo a zapínalo), zkusil jsem si ho vypnout a dělal jsem to ručně mnohem víckrát, než snese NM a hle žádná potíž, tedy zas je to v něm.… Jak říkám nevěřím mu ani „ahoj“.
A myslel jsem si donedávna, že na svém NTB je to s ním v pohodě, a není to úplně pravda, 99 % času ano, ale pokud se pár krát přehodím s wifi na drát a zpětTo asi úplně není věc, která by NetworkManager nějak ovlivňovala.
tak se dostanu na N-ku pod AP a gigabitu pod 10MbitPokud vím, tak o wifi rámce se stará kernel a o údržbu wifi spojení wpa_supplicant. Pokud vím, tak NetworkManager jen spustí wpa_supplicant, nakrmí ho informacemi a pouští background scany, které jdou vypnout svázáním s konkrétním BSSID.
a a chvílemi to snad ani neběží (jako by se to furt vypínalo a zapínalo)Vypínání/zapínání lze vcelku triviálně poznat z logů. Tak jako tak se tam dá s určitou pravděpodobností najít i příčina celého problému, zvláště pokud se najdou nějaké logy od kernelu či supplicantu.
To že NM spouští wpa_supplicant, je hezké nicméně to bylo i kdysi u WiCd, krmili to ve špatném pořadí, nebo bez nutných prodlev pro některé chipy.
Jak říkám - kašlu na to, zatím běží a normálně toto nedělám, jak budu, tak poletí a je problém vyřešený - sorry, není nic proti vložené práci, ale připojení je něco co „jen“ chci aby se navázalo a nemusel se o to starat, hraju si s jinými věcmi.
OT: musel bych zapnou logování
To že NM spouští wpa_supplicant, je hezké nicméně to bylo i kdysi u WiCd, krmili to ve špatném pořadí, nebo bez nutných prodlev pro některé chipy.Je to jen můj pocit, nebo je to co píšeš jen komplikovaný eufemismus pro kernelový bug specifický pro konkrétní hardware, který ani wpa_supplicant, specializovaný nástroj pro daný účel, nedokázal odstínit?
OT: musel bych zapnou logováníProč jsi ho vypínal?
Mně je to to jedno co to je, případ co jsem teď měl na NTB zpomalila se radikálně síť jak WiFi tak drát, pokud jsem odstavil NM a udělal to ručně a mnohem vícekrát, tak žádný problém. Co píšu o WiCd, tak to bylo při připojování na WEP a chtělo to otočit volání „nevím čeho“ (bylo to dokumentované a následně opravené) a pak tam bylo něco co na některých chipech při opakovaném připojení opět na WEP bylo třeba dělat s prodlevou, co byl sice asi modulový bug, který ovšem uživatele nezajímal, ani to že si to někdo přehazuje jako horký brambor, řešit to šlo hrubou silou vyhodit/nahodit modul (u WiCD se dodalo do pre-scriptu u daného spojení).
Ad. logování: na rozchozeném NTB mi na nic není (a něco loguju, možná by se i navazování spojení našlo), ale opravdu cokoliv u NM řeším velmi rychle, svůj čas si už vybral, pro mně je to „červený hadr“, stejně používám distribuční a to je pro všechny tak starý, že o něm už ani neslyšeli…
Mně je to to jedno co to jeToho jsem si zcela vědom, a proto obohacuju diskuzi o názor člověka, kterému to jedno není a který může k tématu dodat i nějaká fakta.
Co píšu o WiCd, tak to bylo při připojování na WEPKonkrétně k WEP po pravdě nemám co říct, odstranil jsem ho, kde jsem mohl a v posledních letech už ho ani nepotkávám. Snad jen to, že je to tak debilní mechanismus, že to svět ještě neviděl.
ani to že si to někdo přehazuje jako horký bramborPodle mě se zde dopouštíš pomluvy. Co vím, tak Dan Williams na hlášené bugy ohledně wifi reaguje, dotazuje se na detaily ohledně hardware, popisuje o co jde a angažuje se ve vývoji driverů. Tím pomáhá i lidem, kteří NetworkManager nepoužívají, chodí po diskuzích a mluví o přehazování horkých bramborů.
řešit to šlo hrubou silou vyhodit/nahodit modulTo je důkaz, že se jedná o problém driveru, který by se měl taky v driveru řešit, v krajním případě obcházet v nástroji, který s driverem komunikuje (wpa_supplicant), ale určitě ne v nástrojích o úroveň výš. Přecijen alespoň někteří z nás vyvíjejí open source proto, aby se to dalo používat, nikoliv proto, abychom si hráli na vlastním písečku. Že si nějaký projekt udělá rychlý workaround namísto smysluplné opravy, s tím bych se moc nechlubil.
Ad. logování: na rozchozeném NTB mi na nic neníNa druhou stranu logování do RAM by ti stroj nijak nezatížilo a měl bys k dispozici alespoň aktuální logy a nemusel bys chodit do diskuzí s tím, že stejně víš hovno.
Bohužel stále WEP je ještě k vidění, u nás snad ani ne, ale v GB, FR i já jsem byl naposledy v hotelu přes WEP v DE.
O házení bramboru není pomluva, ale fakt (asi i dohledatelný) a byla to situace pře hodně lety kolem WiCdm kdy NM neexistoval (aspoň já jsem o něm nevěděl).
O některý věcech nic vědět nechci (NM) a stačí mi brblat, a o některých jo (dostal jsem hlášku, že CentOS nenastartuje ze šifrováním, tak jsem to „zkusil/řešil“).
O házení bramboru není pomluva, ale fakt (asi i dohledatelný) a byla to situace pře hodně lety kolem WiCdm kdy NM neexistoval (aspoň já jsem o něm nevěděl).Tak si rozmysli, co vlastně tvrdíš, o jaké době, o jakém projektu a o jakých lidech.
Nevím na co narážíš?, bo i po opětovném přečtení:
To že NM spouští wpa_supplicant, je hezké nicméně to bylo i kdysi u WiCd, krmili to ve špatném pořadí, nebo bez nutných prodlev pro některé chipy.
Z toho necítím žádné míchaní ani lidí a ni projektů, jen srovnání, že když něco NM volá, ještě neznamená, že to volá správně, protože to tu už bylo u jiného projektu.
To první netvrdím ani já, ale říkám, že je to možné, to druhé si mysli co chceš, já vím jaký patch jsem používal, nechce se mi to hledat ale na první dotaz vyjelo to-to a možná je to ono (nebo nějaká následná obměna téhož).
A protože to nikam nevede, pokračuj si případně sám…A protože to nikam nevede, pokračuj si případně sám…Tak já asi nejsem ten, kdo má potřebu tu vést prázdné řeči ;).
Já tam LILO používám běžně, jeho jediná nevýhoda je, že se při jakékoli změně souborů jádra (a initramdisku) se musí spustit (potřebuje znát čísla bloků souborů jádra) a u některého (dnes už velmi historického) hardwaru může mít problémy, pokud se ony soubory na disku nachází za určitou hranicí. Ale od doby, kdy jsem se začal vrtat v rozličných ARM deskách, používám i na desktopu podobně jednoduchý bootloader EXTLINUX, což je verze SYSLINUXu, podprující načtení jádra a spol. z Ext2/3/4/BtrFS/XFS/FAT/NTFS a na konfiguraci je zhruba stejně jednoduchý jako LILO, ale bez nutnosti cokoliv spouštět.S grubem, jsem včera na schodech s kolegou říkla, že pro servery, (a vlastní PC :)) to chce oživit LILO, bo to je jednoduché a a splní to přesně tu práci co má zavaděč dělat a vždy stejně.
rhgb
, takže šup tam obrázek…rhgb
a druhá s oběma volbami rhgb quiet
.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.