Dotaz: Nelze se přihlásit do systému v KDE

[Dalibor Smolík]

zdravím, mám Debian jessie, po čerstvé instalaci vše fungovalo 2 dny, pak po ručním spuštění kdm (automaticky KDE nenaskočilo) se objevilo hlášení "Systém is booting up. See pam_nologin(8)
Po odkliknutí se objevila hláška "přihlášení neúspěšné".
Mohl by někdo poradit, kde může být chyba? Jedná se o stabilní verzi ..

Odpovědi

[Pavel 'TIGER' Růžička]

A v logu též žádné chyby nejsou? /var/log

[Dalibor Smolík]

Měl jsem připojený externí disk, po jeho odpojení a restartu systém naběhl. Budu tedy chybu hledat zřejmě v /etc/fstab.

[Pavel 'TIGER' Růžička]

V fstab by neměl být externí disk vůbec zapsán.

[Dalibor Smolík]

Já mám připojené dokonce dva . Jeden už tam mám několik let, bez problémů, druhý připojit nelze (ale samostatně ano). Ale vůbec mi nevadí, když ho připojím ručně v rámci KDE (dostupná zařízení). Je to stejně jen pro zálohy.

[Pavel 'TIGER' Růžička]

Napsal jsem to špatně, pochopitelně v fstab zapsán být může, ale o připojování a odpojování extérných úložišť se primárně starají jiné nástroje. Zapsat je do fstab se vyplatí jen pokud se k němu spíše přistupuje jako k internímu disku.

[Max]

Jen bych upozornil, že v "/etc/fstab" by neměly být uvedeny disky ve formátu cesty k blokovým zařízením "/dev/sdx", ale měly by se mapovat v návaznosti na UUID, nebo LABEL (je to lepší, než názvy blokových zařízení).
Zdar Max

[lertimir]

Tohle je zásadní připomínka. V současném paralelním startu není zaručeno pořadí disků /dev/sdx tak, jak bylo dříve pořadí na hw sběrnici. /dev/sda může být i ten externí disk

[Dalibor Smolík]

To je pravda, toho jsem si taky všiml. Musí se to řešit jinak, pokud chci mít externí disk trvale připojený k počítači (což je můj případ)

[dutá palice]

Uvedený článek ale neříká proč se nesmí nebo proč je to lepší ani ty. Já taky vím, že se to dělá dynamickým identifikátorem ale vlastně jsem se ten správný důvod nedověděl.

[Josef Kufner]

Je to kvůli tomu, že /dev/sd* je přiřazováno nedeterministicky, neboť záleží na tom, jak který disk se zrovna chytne rychle a jestli náhodou není připojeno i nějaké další zařízení. V dobách dávno minulých bylo /dev/něco přiřazováno podle fyzické pozice na sběrnici, takže to deterministické bylo (víceméně).

Oproti tomu označení pomocí labelu nebo uuid je celkem bezproblémové. V případě labelu sice může relativně snadno dojít ke kolizi, ale u uuid je ta pravděpodobnost zanedbatelně malá.

[petr_p]

Než začne dělat zálohy blokových zařízení. Pak obě kopie budou mít stejný UUID, protože to je prostě řetězec uložený v souborovém systému. To už bych raději použil cesty z /dev/disk/by-id. Sice to je taky jen řetězec uložený ve firmwaru, ale aspoň nezávislý na datech, se kterými se pracuje.

[Max]

Když se nad tím zamyslíš, tak tvůj návrh je možná ještě horší. Uděláš si bitovou kopii a ta kopie ti nepůjde, protože jí obnovíš na nějaký hdd, ale ten hdd bude mít jiné ID.
Pokud děláš bitovou kopii s UUID, nebo LABEL, tak víš, že na to při obnově nemusíš sáhnout.
Pokud řešíš nějakou zálohu, tak většinou někam na síťový disk, nebo do souboru. Takže tě shodné UUID/LABEL netrápí.
Pokud děláš bitovou kopii na jiný hdd, tak jsi v klidu, dokud nedáš reboot a nenecháš zapojený disk, na který jsi klonoval.
Pokud potřebuješ měnit UUID/LABEL, tak není problém si na to napsat zálohovací script, který bude měnit i UUID/LABEL.
Vše ale tak nějak předpokládá nějakou menší znalost problematiky, takže kdo takové věci dělá, tak by o tom měl toto minimum vědět.
Závěr je tedy takový, že pokud tomu člověk aspoň trochu rozumí, tak je to jedno, ale samozřejmě platí, že používat přímou cestu na blokové zařízení není dobrý nápad.
Jinak osobně si myslím, že UUID/LABEL je variabilnější řešení, jak přímá cesta na ID apod. Člověk má prostě možnost bez starostí klonovat 1:1, nebo si to ve scriptu upravovat.
Zdar Max

[Josef Kufner]

Zálohy na úrovni blokových zařízení nejsou moc praktické tak jako tak.

[tom]

Mel jsem podobnej problem, po odinstalovani systemd a nainstalovani sysvinit to zmizelo.

[nobody]

mam pocit ze po letitem,
"a zkousel jsi to vypnout a znovu zapnout?"
nastala jiz pokrocilejsi era,
"a zkousel si odinstalovat systemd?"
;)

[tom]

Vymena implementace programu zodpovedneho za problemovou funkcionalitu mi prijde jako systematicke reseni problemu.

[nobody]

nepochopils ;) https://www.youtube.com/watch?v=iFd_qqfoEsQ

[tom]

nemam televizi

[dutá palice]

To je kvůli UDEVu ne kvůli systemd, nobody.

[nobody]

podivej se na cislo verze udev, neprijde ti totozne jako verze systemd? cim to asi bude, duta palice ;)

[marek_hb]

tohle se mi stalo po nechtěném zaplnění home - nemůže se ten exterák "nějak postart" o to, aby si kde myslelo, že nemá místo?

[Josef Kufner]

Pro přihlášení do X session je potřeba vytvořit maličký soubor ~/.Xauthority. Pokud to nejde, například kvůli nedostatku místa na disku, tak se nepřihlásíš.

Zkus se přihlásit do textové konzole. Pokud to projde, zkontroluj místo na disku a případně trochu uvolni.

Druhá možnost, které to "System is booting" nasvědčuje spíš, je, že ti v /etc zůstal viset soubor /etc/nologin, který zabraňuje přihlášení uživatelů během bootování. Jedna z posledních operací při bootu je jeho odstranění.

[lojza]

a nemas nahodou prepnutu nejaku inu klavesnicu napriklad EN/SK ... a zadavas zle heslo , nepomoze ani ked urobis update a upgrade v konzole .

[Dalibor Smolík]

Jo, takové věci se stávají, ale to si ohlídám. Nicméně uživatele i hesla si volím tak, aby v něm nebylo "y" ani "z"

[Dalibor Smolík]

Mám 1TB disk, místa mám hafo . Příkazem df si to ověřuji. /etc/nologin v systému nemám. Nicméně po odpojení druhého externího disku se problém už nezopakoval.

[Andrej]

Jedná se o stabilní verzi ..

Což znamená, že už ten bug nikdo nikdy neopraví.

[Dalibor Smolík]

Až do vydání nové stabilní verze ..