Po aktualizaci na Debian Buster nefunguje síť

[onetimer]

Nevim jak najit reseni - poradite?
upgradoval jsem debian stretch -> buster (a prisel jsem o pripojeni k siti)
Na stroji bezi systemd

Kroky:
1.Pri priprave upgradu jsem se drzel tohohle:
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#migrate-interface-names
Radi najit mista, kde se sitovce rika (treba) "eth0"  a zmenit je na "novy" typ nazvu (treba "enp1s0"), ulozit, updatovat initramfs, vyhodit udevove pravidlo.
2. Reboot -> sit OK
3. edit sources.list, pustit logovani prubehu ("script ..."), apt update a apt upgrade bez problemu (tj. sit zije)
4. reboot -> sit v rejzi. dmesg nehlasi problem se sitovkou.  ip --address vraci loopback a eth0 (cili stare jmeno sitovky). V /etc/network/config menim jmena sitovky z noveho ("enp1s0") na eth0. ip up nahodi sit.
5. reboot -> sit v rejzi. Timeout hledani sitovky pri bootu (systemd?)

Mate napad? Co delam blbe a kde mam hledat? Omlouvam se za neuplny popis bez logu, ale prislusny stroj je bohuzel offline...
 

[Reklama]

[redustin]

Jo, upgrady posledních verzí debianu se systemd jsou veliká radost, obzvláště pokud jde o již upgradované instalace z ještě starších non-systemd verzí.

Určitě bych v prvním kole ponechal původní názvy rozhraní parametrem kernelu  net.ifnames=0, jak je popsané v https://wiki.debian.org/NetworkInterfaceNames#How_to_get_it_back . I tak je těch změn a rizik nenabootování nového debianu tolik, že o starost méně je jedině dobře. Defaulty v timeoutech a pravidlech systemd jsou nesmyslné, navíc se mezi verzemi debianu mění. Nabootovat upgradovaný debian napoprvé bez problému je takový malý zázrak.

[HanzHanz]

Ahoj, Debian sice moc nepoužívám, nejčastěji Manjaro, ale problémy jsou všude. Na jednom místě mám jenom přípojku 100Mbit a potom co jsem to PC přenesl z místa, kde je přípojka 1Gbit, tak mi to změnilo název rozhraní z původního enp8s0 na enp10s0 a KVM virtuálky už automaticky nenastartovaly (nechápu proč změna rychlosti změní název :-)). To jen tak pro pobavení...

Tak raději před každým upgradem používám Timeshift a pokud se to podělá, tak za pár minut můžeš být zpět. Na Debian to určitě taky půjde doinstalovat, jestli to tam není už po instalaci.

[František Ryšánek]

Zrovna nedávno jsem si cvičně poskládal maličký serveřík na Debianu 10 a síťoviny mě trochu vypekly (díky mé neznalosti).

Debian 10 má tři různé kanonické způsoby, jak konfigurovat IP adresy při startu:

• systemd-networkd , konfiguráky žijí v /etc/systemd/network/ - toto je aktuální doporučený způsob konfigurace
• /etc/network/interfaces - klasický způsob, dnes oficiálně zavržený, ale funguje dál
• NetworkManager a jeho řádkové nmcli .

Nelze mít v systému démony systemd-networkd a NetworkManager zároveň - vždy smí být živý jenom jeden.

Mohla by Vás částečně zajímat moje odpověď k tomuto tématu. Fintu se systemd-networkd-wait-online.service jste znal?

[redustin]

Finty jsou fajn, když má člověk funkční internet a spoustu času hledat chyby. Narazil jsem velice podobně - již roky neaktivní druhá linka do netu. Prostě tam jenom byla, logicky na druhé straně žádný DHCP server.. takže po upgradu se na ní geniální systemd zahryzl, s tím fantasticky defaultním nekonečným timeoutem kvůli blbé síti... Pořád jsem přesvědčený, že tenhle nesmysl vymysleli v RedHatu pro kontejnery a na normální stroje (natož vzdálené, jen se síťovým přístupem bez IP KVM) ani nevzdychli.

[Reklama]

[František Ryšánek]

Jako je sranda, jak systemd na jednu stranu hrotí rychlost startu, paralelizaci a kdesi cosi, a ve finále zůstane nesmyslně trčet na jednom z dvaceti roztomile svévolných timeoutů...

[redustin]

Přesně to si říkám pokaždé, když koukám na ten timer, jak v lepším případě hlásí, že si počkám ještě minutu a půl, v horším tam to druhé číslo vůbec není. Takže stačí, aby provider měl výpadek DHCP serveru a už se nenabootuje. Nechápu, kdo a jak u toho uvažoval. I když vlastně... do kontejneru lze vlézt zvenku, když nenaběhne, je potřeba rychlý start, centrálně všechno a všechny spravovat jedním nástrojem...

[to_je_jedno]

takhle se mi pojebal upgrade ubuntu 18.04 -> 20.04. nez neco googlit na kompu bez netu, takze i bez copy-paste tak jsme to preinstaloval.

[k3dAR]

Přesně to si říkám pokaždé, když koukám na ten timer, jak v lepším případě hlásí, že si počkám ještě minutu a půl, v horším tam to druhé číslo vůbec není. Takže stačí, aby provider měl výpadek DHCP serveru a už se nenabootuje. Nechápu, kdo a jak u toho uvažoval. I když vlastně... do kontejneru lze vlézt zvenku, když nenaběhne, je potřeba rychlý start, centrálně všechno a všechny spravovat jedním nástrojem...

ja obcas narazim pri poweroff nebo rebootu, nekdy "jen" cekam nez ubehne 90s, ale obcas po ubehnuti 90s se odpocet protahne sam na 180s, to uz vetsinou vypinam natvrdo

opravdu nechapu, proc pri timeoutu neni moznost hotkey "S - skip timeout na vlastni nebezpeci"

[_Jenda]

opravdu nechapu, proc pri timeoutu neni moznost hotkey "S - skip timeout na vlastni nebezpeci"

+1, mně většinou dojde trpělivost a v konfiguraci všechny timeouty snížím, ale pak jsem zase narazil na problém, že velký FS na rotačním disku, který nebyl korektně odpojen, trvalo dlouho připojit (přehrával se žurnál atd.), nestihlo se to do toho timeoutu a celé to vybuchlo.

[redustin]

Timeouty lze snížit až poté, co to nabootuje. Bohužel tahle podmínka nebývá splněna....

Když už je ten systém tak složitý, mohl by se ptát filesystému, jak je na tom, zda je tam chyba nebo jenom se čeká na přehrání žurnálu.

[František Ryšánek]

Timeouty lze snížit až poté, co to nabootuje. Bohužel tahle podmínka nebývá splněna....

...já bych navrhoval, zkusit bootnout do režimu single. Podle mého se ho mnohé z těch timeoutů netýkají. Přitom v singlu máte přístup na disk, teda pokud není rootfs zbořený. Jo a dobrá je taky finta, vnutit navrch k singlu ještě namísto initu /bin/bash :-)