Logowanie na pulpicie kończy się niepowodzeniem, terminal działa

12

Mam świeżo skonfigurowany system komputerowy 12,04 LTS (dysk SSD 120 GB, dysk twardy 1 TB, pamięć RAM 16 GiB); od kilku dni nie mogę już zalogować się do graficznego pulpitu: jest bardzo krótkie migające okno powłoki, które znika bardzo szybko ( edycja: patrz poniżej ), i ponownie pojawia się ekran logowania. Wierzę, że istnieje coś takiego modprobei vbox, ale nie mogę odczytać to dość szybko ...

Mogę zalogować się do terminala ( Ctrl+ Alt+ F1). Nie pomogło do chown całą zawartość mojego katalogu domowego do me: my-groupjak sugeruje tutaj .

Oto, co mogłem znaleźć /var/log, szukając daty i godziny (wstawiłem podział linii po <my-hostname>; wartości w czasie rzeczywistym zachowane):

auth.log:

<date> 22:43:01 <my-hostname>
    lightdm: pam_succeed_if(lightdm:auth): requirement "user ingroup nopasswdlogin" not met by user "tobias"
<date> 22:43:08 <my-hostname>
    lightdm: pam_unix(lightdm:session): session closed for user lightdm
<date> 22:43:08 <my-hostname>
    lightdm: pam_unix(lightdm:session): session opened for user tobias by (uid=0)
<date> 22:43:08 <my-hostname>
    lightdm: pam_ck_connector(lightdm:session): nox11 mode, ignoring PAM_TTY :0
<date> 22:43:08 <my-hostname>
    lightdm: pam_unix(lightdm:session): session closed for user tobias
<date> 22:43:09 <my-hostname>
    lightdm: pam_unix(lightdm:session): session opened for user lightdm by (uid=0)
<date> 22:43:09 <my-hostname>
    lightdm: pam_ck_connector(lightdm:session): nox11 mode, ignoring PAM_TTY :0
<date> 22:43:10 <my-hostname>
    lightdm: pam_succeed_if(lightdm:auth): requirement "user ingroup nopasswdlogin" not met by user "tobias"
<date> 22:43:10 <my-hostname>
    dbus[756]: [system] Rejected send message, 2 matched rules; type="method_call", sender="1:43" (uid=104 pid=1639 comm="/usr/lib/indicator-datetime/indicator-datetime-ser") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.15" (uid=0 pid=1005 comm="/usr/sbin/console-kit-daemon --no-daemon ")

kern.log:

<date> 22:43:00 <my-hostname>
    kernel: [   16.084525] eth0: no IPv6 routers present

syslog:

<date> 22:43:00 <my-hostname>
    kernel: [   16.084525] eth0: no IPv6 routers present
<date> 22:43:01 <my-hostname>
    ntpdate[1492]: adjust time server 91.189.94.4 offset -0.162831 sec
<date> 22:43:08 <my-hostname>
    acpid: client 969[0:0] has disconnected
<date> 22:43:08 <my-hostname>
    acpid: client connected from 1553[0:0]
<date> 22:43:08 <my-hostname>
    acpid: 1 client rule loaded

Mam zainstalowane Virtualbox i Truecrypt, ale nie mogę wymyślić powodu, dla którego mogłyby zapobiec graficznemu logowaniu.

Jestem zmieszany:

  • O co chodzi requirement "user ingroup nopasswdlogin" not met? I nie logować się za pomocą hasła, a hasło działa ok podczas logowania do terminala!
  • Czy mogę w jakiś sposób odczytać wyjście błędu, np. Opóźniając go, przekierowując do pliku lub prosząc system o naciśnięcie klawisza?
  • Czy prawdopodobnie jakaś ostatnia aktualizacja spowodowała mój problem? Czy powinienem zainstalować oczekujące aktualizacje? Jak przy okazji, bez dostępu do graficznego interfejsu użytkownika?

Mam trochę praktycznej wiedzy na temat powłoki Linux, ale jestem nowy w Ubuntu. Każda pomoc będzie mile widziana.

Edycja: Po wyłączeniu maszyny wczoraj ( sudo shutdown now) znalazłem na ekranie następujący tekst, który wydaje się być „migającym” tekstem wspomnianym wcześniej (sformatowanym; było trochę głupich początkowych białych znaków):

Could not write bytes: broken pipe
speech-dispatcher disabled; edit /etc/default/speed-dispatcher
* Starting VirtualBox kernel modules
* modprobe vboxdrv failed. Please use 'dmesg' to find out why
saned disabled; edit /etc/default/saned
* Checking battery state... [ OK ]

Po ręcznym skopiowaniu go wyłączyłem urządzenie, naciskając przycisk przez kilka sekund.

Być może problem dotyczy wirtualnej skrzynki (zainstalowany 4.2). Jeszcze dzisiaj dodam więcej ekstraktów plików dziennika (MET).

Edytuj , dla rekordów: Próbowałem następujące, z / a / 133754/103086 :

  • sudo apg-get install gdm(po wyświetleniu monitu wybierz GDM)
  • ponownie uruchomiony; logowanie nie powiodło się również w GDM
  • sudo dpkg-reconfigure lightdm, ponownie uruchomiony; logowanie nie będzie działać
  • mój ~/.Xauthorityplik jest pusty; usunięcie go i ponowne uruchomienie nic nie zmieniło

Ponadto:

  • odinstalował virtualbox ( sudo apt-get remove virtualbox-4.2), uruchomił się ponownie

Edycja : przesłałem archiwum zip wybranych / odfiltrowanych plików dziennika do http://www.tobias-herp.de/en/errors/ubuntu-gui-lockout . Przechowywane apt-get upgradeing niedawno, ale niestety problem nie został rozwiązany.

Tobiasz
źródło
Mam skrypt do wyodrębniania wierszy dziennika (i kopiowania plików z wierszami bez prefiksu), i załadowałbym archiwum zip (ponieważ byłoby to 1619 wierszy w 6 plikach, w tym 924 wierszy w dmesg), ale nie mogę dowiedz się, jak go przesłać ...
Tobias
Nie; ~/.Xauthorityplik jest completeliy „moje” ( tobias:tobias).
Tobias
Niedawno skonfigurowałem nowy pulpit 12.04 (mam już 5 innych) i nowy miał problemy z logowaniem się do GUI z użytkownikami ldap, ale nie lokalnie. Walczyłem z tym z ograniczonym sukcesem, a potem poddałem się i zainstalowałem Mint, który działał. Domyślam się, że w ostatniej aktualizacji jest jakiś regres. rant: ubuntu staje się kompletnym bałaganem. wystarczy spojrzeć na szaloną konfigurację pam z narzędziami konfiguracyjnymi, które są jeszcze bardziej skomplikowane i tajemnicze niż ręczna konfiguracja pam.
Cyklon

Odpowiedzi:

14

Usunięcie ~ / .Xauthority działało dla mnie

Andrzej
źródło
To samo tutaj, nawet jeśli ~/.Xauthoritybyło to z odpowiednim pozwoleniem i właściwym właścicielem (ja).
vaab
Podobnie to zadziałało dla mnie (na Ubuntu 13.04)
Stabledog
Tak, usunięcie pliku jest konieczne, ponieważ dane w pliku .Xauthority będą się różnić (być może istnieje kontekst pid lub data?). Samo pozwolenie nie jest zwykłym problemem.
Andrew
4

Miałem ten sam problem. Okazało się, że mój problem polegał na tym, że ~/.Xauthorityzostał zaktualizowany jako root i od tej pory tylko root mógł go odczytać. Powstrzymało mnie to od rozpoczęcia dowolnej sesji X z mojej nazwy użytkownika. Musiałem sudo rm ./.Xauthorityi potem wszystko działało dobrze.

Piotr
źródło
3

W końcu poddałem się i ponownie zainstalowałem system. Nie stanowiło to problemu, ponieważ system był dość świeży, a większość danych osobowych nie została jeszcze do niego zmigrowana. Nie wiem na pewno, że problem nie został spowodowany niestandardowym pakietem, więc ...

Więc zacząłem od nowa i podjąłem środki ostrożności, aby być lepszym następnym razem. Po instalacji zaktualizowałem system, zainstalowałem kilka kluczowych pakietów i zwróciłem uwagę na konfigurację:

sudo bash
apt-get upgrade
apt-get install ssh mercurial vim
cd /etc/
vim mercurial/hgrc
hg init .
hg add *
hg commit

Dlatego za każdym razem, gdy pojawia się nowy problem, powinienem mieć większą szansę dowiedzieć się, co mogło pójść nie tak.

Tobiasz
źródło
Dla przypomnienia: po chwili nawet nowy system instalacyjny napotyka ten sam problem. Zdecydowałem się całkowicie usunąć Ubuntu i zamiast tego zainstalowałem system Windows (z wirtualną maszyną z systemem Linux).
Tobias
Dla przypomnienia: to, co robisz z „hg”, odbywa się automatycznie dzięki pakietowi „etckeeper” (i możesz wybrać mercurial, bazar, git ...)
vaab 23.09.13
2

W moim przypadku było to spowodowane błędem, ~/.dmrcjak wyjaśniono tutaj . Można to wykryć dzięki temu, ~/.xsession-errorsże miałem następujący błąd:

x-terminal-emulator: krytyczny błąd we / wy: klient zabił konsolę (1598) Konsola :: SessionManager :: ~ SessionManager: Konsole SessionManager zniszczony z sesjami wciąż aktywnymi

BenC
źródło
2
też dla mnie pracował. Kubuntu 12.04, KDE. Usunąłem zarówno .dmrc, jak i autoryzację. Dzięki!
MountainX
2

Podobny problem przytrafił mi się po dodaniu export PATH=$PATH:/home/<user>/SomeFolderna końcu /etc/profile. Po zalogowaniu się do terminala, usunięciu tej linii i ponownym uruchomieniu, mogłem zalogować się normalnie i problem zniknął.

Dokumentacja:

  • Przed ekranem logowania pojawiał się następujący migający tekst:

    Could not write bytes: broken pipe
    * Starting VirtualBox kernel modules
    
    saned disabled; edit /etc/default/saned
    
  • Ubuntu 12.04 LTS, 64-bitowy, Intel Core i5, 6 GB.
  • Mam zainstalowany VirtualBox 4.2.18, ale wydaje się, że działa dobrze.
  • Uruchamiam podwójnie z Windows 8 za pomocą GRUB.
jRT
źródło
Czy to mógł być problem? Nie wiem Zwykle mam ~/binkatalog, który lubię mieć w PATH, ale instalacja już nie istnieje.
Tobias
Popchnąłeś mnie we właściwym kierunku, rozwiązując problem, który pojawił się również na moim netbooku, który wciąż ma Ubuntu. Jeden z skryptów powłoki, który automatycznie pozyskałem podczas logowania, spowodował błąd i tam jako wiersz ~/.xsession-errors; kiedy spróbowałem w skorupce, wszystko wyglądało dobrze. Wyłączyłem jednak ładowanie skryptów i mogę ponownie zalogować się graficznie.
Tobias
0

Natknięcie się na to teraz za pomocą lightdm + dowolnego powitania niejednorodności. Jeśli ustawię greeter na unity-greeter w /etc/lightdm/lightdm.conf, wydaje się, że działa. Nie mam pojęcia dlaczego.

Edycja: zredagowane. Coś, co właśnie ściągnąłem z aktualizacją, musiało to spowodować, a teraz nawet program do przywiązywania jedności nie działa.

Paweł
źródło
1
Rzuciłem okiem na ten plik; w sekcji (jedynej) SeatDefaultswartość greeter-sessionjest unity-greeterjuż. Jakaś inna wartość, której mógłbym spróbować?
Tobias
0

W moim przypadku dodałem kilka poleceń do .xprofile, które spowodowały powrót do ekranu logowania zaraz po zalogowaniu. Znalezione błędy były takie same. Usuń wszystko, co nie jest niezbędne z ~ / .profile, a ~ / .xprofile powinno przywrócić normalną sytuację.

Dalf
źródło
0

Dla mnie tak się stało, gdy w pliku .profile znajduje się nieprawidłowy wpis ścieżki make. Kiedy go usunąłem, działało idealnie. Sprawdź plik .xsession-error pod kątem zgłaszanego błędu

savyan
źródło
0

Ten sam błąd wystąpił dla mnie na Ubuntu 14.04.02 LTS. Otworzyłem plik dziennika /var/log/lightdm/lightdm.logi widzę komunikat podobny do ...not enough disk space for .Xauthroity.... Potem odkryłem, że na dysku jest naprawdę zero miejsca. Więc usunąłem niektóre pliki i błąd zniknął.

Paul Annekov
źródło