Dotaz: nebootuje po upgradu kubuntu 16.4 -> 18.4

[Martin]

Příloha:

• 20191201_164329_small.jpg (197057 bytů)

Zdravím,

upgradoval jsem kubuntu 16.4 na 18.4 a teď nenabootuje. PC začne rovnou bootovat, zmizela nabídka boot manageru (myslím, že to byl GRUB), po nějaké době se objeví logo KUBUNTU, pomalu u něj bliká podsvícení, to je vše.

Lze přepnout na jiné screeny, ale nelze se nalogovat, obrazovka je celá černá, jen v rohu bliká kurzor, na nic nereaguje, jen někdy na enter odřádkuje.

Na obrazovce s logem lze pomoci ALT-TAB přepnout na výpis bootu, opakují se tam hlášky:

Failed to start Light Display Manager.

a

Failed to start Detect the available GPUs and deal with any system changes.

Nepodařilo se mi na té obrazovace skrolovat, tak nevím, jestli vypsal i něco jiného.

Potřeboval bych poradit co s tím, připravím si bootovací flešku s 18.4, lze tam pustit nějaký repair? Kde po bootu s flešky najdu nějaké logy z bootu z disku?

Budu rád za jakékoliv nasměrování a rady.

Martin

Počítač:

ASUS P7P55D-E, P55

MSI VN210-MD512H, 512MB DDR2 (800MHz), NVIDIA GeForce 210

Procesor INTEL Core i7-870

Seagate Barracuda 3TB, 64MB, 7200

HD INTEL 330 Series 120GB SSD disk

systém je na SSD

---

---

Odpovědi

[k3dAR]

grub zobrazis tlacitkem ctrl nebo shift tesne v momente kdy z disku zacne startovat, v menu vyber advanced/cislojafra-recovery_mode, nastaruje nabidka kde vyberes root shell, tam odinstalujes nvidia ovladace:

sudo apt purge nvidia*

pokud bys nebyl jistej zda to nebude chtit odebrat vice baliku, udelej foto, o dej ho sem v priloze a odinstalaci odloz dokud to tu nekdo neoveri...

[David]

Asi by to chtelo odinstalovat i ten lightdm a zkusit pro KDE sddm. Jinak jake pouzivas spojeni na net pro pripad stahovani pres negrafickou konzoli?

[Martin]

diky, vyzkousim, k pocitaci se dostanu az vecer. Nechapu dotaz na spojeni na net, PC je pripojeno eternetem k ADSL routeru, sit snad fungovat bude. Na routeru je DHCP server, tomuto PC nastavuje porad stejnou IP adresu.

[Jendа]

Mohl by nějaký odborník na systemd vysvětlit, co se v této situaci má správně dělat? (opravdu mě to zajímá) Se sysv initem se mi tohle nikdy nestalo, samozřejmě jsem zažil spoustu různých havárií, ale úplně vždycky to skončilo spuštěním shellu (resp. požadavkem na root heslo a následně spuštěním shellu). Se systemd vidím situaci „systemd na něco čeká a nejde s tím vůbec nic dělat“ pravidelně - naštěstí většinou jde o 90s/5min (!!! - defaultní na síť - člověk blbě nastaví rozhraní a pak v serverovně pět minut stojí než dostane shell aby to mohl opravit !!!) timeout.

[Michal]

To se řešilo několikrát za poslední dny. Dalo by se to parafrázovat zhruba takto: máš věnovat veškerý svůj volný čas studiu systemd. Pak bys si to uměl správně nastavit a nestalo by se to. Uživatel, který by chtěl dělat s PC i něco jiného než objevovat taje systemd (divné, ale prý takoví jsou), nemá nárok.

[Peter Golis]

Keď sa systém stihol prepnúť do grafiky ktorá zhavarovala na (počas upgrade) poškodených ovládačoch, tak si to heslo na roota nemalo ako vypýtať. To je nezávislé od initu. A je jedno či by tým initom bol SysV init, openrc, upstart alebo systemd. Ak to raz zhavaruje a zasekne sa na binárnom ovládači, tak nemusia fungovať ani klávesy okolo SysRQ.

Mohol by som sa na oplátku opýtať ako by dokázal akýkoľvek init zadať výzvu na heslo v tomto prípade?

[Jendа]

V příspěvku se píše, že klávesnice funguje, a podle přiložené fotografie vidíme, že obrazovka též funguje - tvůj první odstavec je tedy naprosto mimo (jako obvykle). Tyto dvě ingredience k provozování shellu stačí.

Navíc je vidět, že si systemd uvědomuje, že je něco špatně - už tři minuty čeká, a ví, že bude čekat potenciálně do nekonečna. Zobrazený kurzor dále ukazuje, že přímo do této konzole lze psát.

Jinými slovy: nic nebrání tomu, aby odchytával například Ctrl+C, a při takové události sestřelil to, na co čeká, a spustil shell.

[Peter Golis]

Nuž normálne. Človek počká pokiaľ nezafunguje watchdog a neprepne sa to do toho módu ktorý je ako druhá položka pri štarte a aktivuje sa aj sama v grube cez recordfail. A ak sa veľmi ponáhľa, tak stlačí tlačítko reset.

[Jendа]

To je problematické, protože v logách toho obecně nemusí zbýt dostatek na to, aby šlo problém efektivně ladit když se zrovna nevyskytuje. A v případě, kdy nemám zapisovací médium, v logu nebude dokonce vůbec nic. („Prováděj logování po síti“ říkají zastánci systemd. „Fuck you“ říkám já.)

[Peter Golis]

Pokiaľ potrebuješ logy a nemáš lokálne zapisovacie médium, tak kam by si logoval ak nie na vzdialený systém po sieti? To nesúvisí s systemd, to súvisí so zdravým rozumom.

A pokiaľ tie logy nepotrebuješ, tak máš všetko odladené a plne funkčné.

[Peter Golis]

Příloha:

• Ubuntu-failed-start-password.png (47747 bytů)

Čiže, ak som to dobre pochopil, tak by mal systemd čakať na odchytenie nejakej klávesy a opýtať sa na heslo? Nuž dnes mi urobil niečo podobné, po vypršaní času na pripojenie diskov sa opýtal na heslo pre jednoužívateľský režim.

Zachoval sa systemd správne, alebo nie?

PS: Spustil som si naraz farmu cca 8 desktopov na notebooku s jedným rotačným diskom. Mal som tak preťažené I/O, že si to nestihlo do 1.5 min ohmatať disky a považovalo to za zlyhanie HW.

[k3dAR]

pochopil jsi spatne, to ze naskoci emergency po vyprseni timeoutu je sice "hezke", ale slo o to ze nejde rucne vyvolat emergency(nebo skipnout) pred uplynutim tohoto timeoutu... coz obzvlast v pripade tazatele, kdyz se podivas do jeho screenshotu ma timeout ve stavu "( 3min 36s / no limit )"

[lertimir]

A nevíš jak to Lenart vysvětluje? Očekával bych tak, že všichni jsou úplně blbí.

[k3dAR]

to nevim ale logicky, vzdyt by preci bylo strasne jednoduche to zmenit (skoro) v dokonalost:

Sluzba X ceka na Y [ 0:05 z cokoliv ]...
(press: S-Skip, A-Add30sec, E-Emergency, R-Reboot, P-Poweroff)

+ by slo by se pripojit vzdalene pres ssh idealne/ne_nutne se napojit i na screen, nebo alespon tail logu z ktereho by bylo jasne co na obrazovce je...

[k3dAR]

+ to ssh klidne default off a povoloval by si to uzivatel na svoji zodpovednost treba pres "systemctl enable early-sshd"

[lertimir]

Napiš mu to.

[k3dAR]

odpoved nofix si muzu dat sam

[Peter Golis]

Pochopil som to správne. Zadávateľ pôvodnej témy mal problém s desktopom a stačilo mu použiť poskytnutý nástroj (štart OS bez potencionálne problematických ovládačov) a vykonať odstránenie starých/nekompatibilných ovládačov a nainštalovať nové ovládače.

Porovnanie s vytuneným serverom v serverovni ktorému niekto zabudol napojiť KVM over IP, iLO, DRAC alebo sa mu nechcelo k tomu stroju osobne prísť je rovnako mimo ako vyplakávanie z pred pár týždňov kde ľudia tvrdili že pri probléme s doplnkovým diskom systém donekonečna čaká a nepustí to ďalej. Nečaká, a pustí to ďalej.

Zjavne zafungovalo staré pravidlo: Keď je dostatočný počet hlasov za opravu alebo implementáciu novej vlastnosti, tak sa to vyrieši. Bez ohľadu na to či je to systemd alebo hocičo iné. A ak nieje ten počet dostatočný, tak sa bude autor/správca/komunita zaoberať inými vecami ktoré majú dostatok hlasov za opravu. Alebo dostatok odborníkov ktorí to opravia a poskytnú prehľadné patche na schválenie.

S tým nofix (won't fix) som videl veľa ľudí plakať. Najmä ľudí čo len čakali že to niekto za nich nahlási do upstreamu a potom to zas niekto iný pretlačí do distribúcie ktorá nie je rolling/continous delivery.

Takže šup, skontrolovať, zahlasovať alebo inak priložiť ruku k dielu. A nečakať so založenými rukami. Alebo prestať plakať.

[k3dAR]

goto #15 + nekolik hintu k pochopeni: - "no limit" znamena ze timeout neni omezen, tedy ceka donekonecna
- tazatel na svem screensotu ma "no limit"
- probihajici odpocet timeoutu nelze prerusit

[Peter Golis]

A kde je problém, že za to ľudia nezahlasovali a radšej plakali mimo záberu správcu daného programového balíka?

V prípade pripájania diskov za to zahlasovali, a pohlo sa to. A napriek tomu si to tu niektorí jedinci ešte pred pár týždňami nevšimli, a plakali nad neschopnosťou.

Ak je to pre teba esenciálna záležitosť, tak za ňu hlasuj na správnom mieste. A spropaguj to, aby za to zahlasovali aj iní. Potom sa to pohne rovnako, ako sa to pohlo pri tých diskoch.

[qwe]

jo systemd je sr@čk@, stává se mi to pravidelně (a u různých věcí)

[Martin]

Díky, pomocí vašich rad se mi podařilo systém znovu rozjet. Odinstaloval jsem nvidia, to nestačilo, pak jsem přepnul na sddm a už to šlo. Potom jsem ovladače opět přepnul na proprietární NVIDIA a funguje to.

Vypadá to, že vše funguje, dokonce i scanner epson 1650 koupený roku 2002, já snad upgrajduju na 20.4 až vyjde

Martin

[lertimir]

Super. S těmi upgrady může být různě potíž, protože vždy je za tím potřeba vidět lidi, kteří upgrade připravují. A možná nikdo neuvažoval v detailu situaci, kdy v KDE pojede jako DM Light DM a někde něco zapoměli zmigrovat. Navíc zvláště když pracují na dvou migracích současně. Jedné z 17.10 na 18.4 a jedné z 16.4 na 18.4.

[Peter Golis]

Holt, komunita tvorcov Kubuntu sa spoľahla na testovanie kompatibility ovládačov firmou Canonical (binárne ovládače nvidia sú medzi podporovanými balíčkami a nie v universe/multiverse), a neotestovala prepnutie na nimi odporúčaný sddm.

Technicky vzaté, zaujímalo by ma prečo upgrade metabalíka kubuntu-desktop nevymenil display manager za sddm keď priamo vyžaduje balík sddm-theme-breeze ktorý len odporúča balík sddm. Ak menili Display Manager, tak to nemuseli dať ako voliteľné.

Ale suma sumárum. Jedna komunita pozabudla, a druhá pomohla s riešením.

[❗Červivý Hřib krade❗]

jsem někde slyšela že je jako rozumný se kubuntu zdálky vyhnout a když někdo chce KDE tak je jako lepší si to nainstalovat do jinýho distra a nejlíp do obyč ubunta. nevim.

[k3dAR]

KDE Neon, Ubuntu LTS pripravovane od KDE tvurcu v stable/devel/nightly verzich, predinstalovavane na KDE Notebooky...

[❗Červivý Hřib krade❗]

hej to by mohlo bejt dobrý jako!! kdybych už chtěla ubuntu s kde tak šáhnu po tomhle. díkec!!