Rechner startet Linux erst nach dem 2 mal.

[linrunner]

In den Startupmeldungen sind keine Fehler zu sehen. Ist auch eher selten, dass man dort Hinweise findet, das Problem kommt ja erst nach der letzten Meldung.

 

[kangundkodos]

alles klar, dann scheint da doch irgendwas anderes im argen zu liegen...Nun ist der Salat leider komplett, nachdem ich sudo startx angewendet habe kann ich mich nun nicht mehr anmelden. Die Anmelde-Maske erscheint ordnungsgemäß, aber mein Passwort wird nicht mehr akzeptiert.. Schlecht. Ich hab mich grundsätzlich damit abgefunden das ich das wahrscheinlich nochmal von Anfang an neu installieren muss, aber gibt es eine Möglichkeit mit der ich nochmal reinkomme, um meine Mail-Kontakte und Bookmarks, etc. zu sichern? Ich hab auch aus irgendeinem Grund eine falsche Version (32 bit) drauf, wie ich dazu gekommen bin weiß wahrscheinlich nur der Herr im Himmel ^^

komischelektronisch

Dank und Gruß

 

[supertux]

Und du bist dir sicher (nur) eine 64bit Version installiert zu haben mir scheint, das sich da eine (evtl früher mal Installierte) 32bit Version vorzudrängeln versucht (vllt. hast du da auch ein anderes Benutzerkonto angelegt? auf jeden fall komisch)
wenn du dich nicht anmelden kannst kann das auch an einem falschen Tastaturlayout liegen (englisch statt deutsch) vllt. mal versuchen das Passwort wie auf einer amerikanischen Tastatur einzugeben.

P.S: startx startet nur die graphische Oberfläche, dürfte also nichts kaputt machen.

 

[kangundkodos]

Nein, sicher bin ich mir nicht, leider -.- Ich installier das gleich alles nochmal .. Also ich denke nicht das es am falschen Passwort liegt (also falsch geschrieben) weil : nachdem ich Enter drücke, und somit meine Eingabe bestätige kommen diese Startup-meldungen, und dann macht es plopp (dieser komische ubuntu-anmelde-jingle), und ich stehe wieder an der anmeldung... doof!

egal

 

[SammysHP]

P.S: startx startet nur die graphische Oberfläche, dürfte also nichts kaputt machen.

Du hast sudo starx empfohlen.

nachdem ich Enter drücke, und somit meine Eingabe bestätige kommen diese Startup-meldungen, und dann macht es plopp (dieser komische ubuntu-anmelde-jingle), und ich stehe wieder an der anmeldung... doof!

Es liegen nach der sudo-Aktion nun Dateien mit root als Besitzer in deinem Home-Verzeichnis (z.B. Session-Informationen). Die können nun natürlich nicht mehr überschrieben werden.

Wenn aber auch andere Probleme aufgetaucht sind, empfiehlt sich eine Neuinstallation inkl. Löschen des Home-Verzeichnisses (ggf. Daten vorher sichern).

 

[Laberkopf]

X lässt sich aber (in der Standartkonfiguration) afaik nur mit rootrechten starten.

 

[SammysHP]

Seit wann das?!

 

[Laberkopf]

mach doch mal dpkg-reconfigure x11-common
Dann wirst du sehen, welche einstellung bei dir aktiv ist. Meines Wissens nach ist das nur root.

 

[SammysHP]

Also ich habe X noch nie in meinem Leben mit root Rechten gestartet. Ganz normal auf dem Terminal einloggen und startx aufrufen.

 

[supertux]

X lässt sich aber (in der Standartkonfiguration) afaik nur mit rootrechten starten.

Das ist auch mein Wissensstand, wobei es ziemlich egal sein dürfte, wer X startet (root oder user), da beim Ausschalten X sowieso beendet bzw. gekillt wird.

Es liegen nach der sudo-Aktion nun Dateien mit root als Besitzer in deinem Home-Verzeichnis (z.B. Session-Informationen).

Das tun sie in der Regel schon vorher, da der betreffende User (wenn er sudo Aktivitäten ausführen kann) root Rechte besitzt (wenn auch zu Sicherheitszwecken nicht dauerhaft aktiv).

Die können nun natürlich nicht mehr überschrieben werden.

Das ist so nicht ganz richtig, da ein User mit root Rechten natürlich Zugriff auf die eigenen Daten hat (nur muss das evtl. manuell erfolgen)
Wenn du uns noch sagen könntest, welche ominösen (Sperr-)Dateien das sein sollten, wären das ein paar Eingaben auf der Konsole und schon sind sie wieder weg ;-)

P.S: Das mit dem Starten von X war ein gut gemeinter Rat und ich entschuldige mich hiermit ausdrücklich dafür wenn dies den Fehler erzeugt/verschlimmert hat :facepalm:

 

[SammysHP]

Das ist auch mein Wissensstand, wobei es ziemlich egal sein dürfte, wer X startet (root oder user), da beim Ausschalten X sowieso beendet bzw. gekillt wird.

Das stimmt, wenn der Prozess beendet ist, ist's natürlich egal.

Das tun sie in der Regel schon vorher, da der betreffende User (wenn er sudo Aktivitäten ausführen kann) root Rechte besitzt (wenn auch zu Sicherheitszwecken nicht dauerhaft aktiv).

Öhm, nein. Prozesse des Nutzers starten mit den Rechten, die ihm standardmäßig zugeteilt wurden. Wenn man sudo nutzt, wird die Umgebung des neuen Prozesses entsprechend angepasst (mehr Rechte).

Das ist so nicht ganz richtig, da ein User mit root Rechten natürlich Zugriff auf die eigenen Daten hat (nur muss das evtl. manuell erfolgen)

Das versteh ich jetzt nicht. Abgesehen davon, dass ein Nutzer auch auf seine eigenen Dateien keinen Lese- oder Schreibzugriff haben kann (das kann er aber ändern!), ist er selbtverständlich nicht der Eigentümer von Dateien des Nutzers "root".

Wenn du uns noch sagen könntest, welche ominösen (Sperr-)Dateien das sein sollten, wären das ein paar Eingaben auf der Konsole und schon sind sie wieder weg ;-)

Es geht um Sessioninformationen bzw. Konfigurationsdateien. Das lässt sich ganz einfach mit einem anderen Programm (vim) demonstrieren. Im Homeverzeichnis:

- $ rm .viminfo
- $ sudo vim asfd
- :wq
- $ ls -l .viminfo

In der .viminfo wird u.a. gespeichert, wo der Cursor in einer Datei zuletzt war. Mit dem speichern von asfd sollte diese Datei angelegt worden sein. Wenn du dir jetzt mit ls -l die Rechte anzeigen lässt, wirst du sehen, dass sie etwa rw-r--r-- sind mit Eigentümer und Gruppe "root". Wie ist das passiert? Du hast einen Prozess (vim) mit veränderten Rechten (sudo) ausgeführt. Dabei wurde die Prozessumgebung verändert (Rechte), aber Umgebungsvariablen (wie z.B. $HOME) wurden nicht verändert. Deswegen wird die Datei in deinem Homeverzeichnis angelegt, durch sudo allerdings mit anderen Berechtigungen. Wenn du vim nun ohne sudo benutzt, wird die Cursorposition nicht mehr gespeichert, weil "anderen" die Schreibrechte bei der Datei .viminfo fehlen. Etwas ähnliches passiert bei sudo startx auch.

Dir ist die Arbeitsweise von sudo vielleicht noch nicht ganz klar. Wenn du in der sudo/admin-Gruppe bist ($ groups), hast du keine anderen Berechtigungen für deine Prozesse. Wenn du allerdings sudo ausführst, wird überprüft, ob du in der entsprechenden Gruppe bist, die Prozessumgebung des neuen Prozesses wird dann geändert. root ist immer noch root und der user immer noch der user.

 

[supertux]

... Etwas ähnliches passiert bei sudo startx auch.

Schon klar. Ich wollte aber mit meiner Aussage eher darauf hinaus, dass eben solche Dateien in so ziemlich jedem home Verzeichnis rumgammeln (entstehen bei jeder Programminstallation, da diese im Grunde einem sudo apt-get install ... entspricht)
Wie du selber bereits sagst, lässt sich aber dein Prozess (vim) trotz der veränderten Sessioninfo weiterhin ohne root rechten starten.

Anders verhält es sich aber mit sogenannten lock-files(Sperrdateien) die der betroffene User(sofern er der suodoers-group angehört) letztlich (z.B. nach einem Programmabsturz) manuell mit entsprechenden Befehlen noch löschen kann/muss.
Daher zielte meine Bemerkung eher darauf ab, ob dir die lock-files von X bekannt sind.

root ist immer noch root und der user immer noch der user.

Stimmt so nicht ganz, da bei einem sudo-Befehl nicht von user auf root gewechselt wird, sondern dem user vorübergehend root rechte zugewiesen werden (das home profil wechselt z.B. nicht)
(bin zwar kein linux Vollprofi (wie einige meiner Studienkollegen), aber was sudo ist weiß ich sehr wohl)

Zurück zum Thema:
Ich persönlich vermute aber (da ja x nicht abgestürzt zu sein scheint), dass das Tastaturlayout aufgrund des Startens von x mit root rechten auf default(meistens US) zurückgesetzt wurde.
Daher kann es sein, dass das System eigentlich korrekt funktioniert, aber Passworte (mit ö,ü,ä,j,z,...)falsch interpretiert werden (kommt bei uns an der Uni auch des Öfteren vor)
Ungewöhnlich ist hier aber, dass der Sound für eine erfolgreiche Anmeldung erfolgt (der sollte sich doch eigentlich von dem der Verweigerung unterscheiden)

 

[SammysHP]

Ich geb's auf. In deinem Post stimmt vieles nicht, der Rest wiederholt meine Worte.

- apt-get schreibt doch nichts in deinem Home-Verzeichnis?!
- Natürlich wird vim gestartet. Aber lies bitte meinen Post nochmal, vim wird ab da an die Cursorposition nicht mehr speichern.
- Hat nix mit dem Layout zu tun (da ein Login keine Layouteinstellungen ändert, wird das auch nicht auf default zurückgesetzt), Login geht ja. Sonst würde auch kein Ton kommen, wie du schon richtig sagtst. Abgesehen davon, dass beim Display Manger i.d.R. noch die Systemeinstellung gilt.
- Dass die Session wieder beendet wird, liegt an irgendeinem Fehler bei der Ausführung.
- Ich vermute, dass da Dateien mit Benutzer root rumliegen. $ find ~ -user root
- Fehler könnten in ~/.xsession-errors stehen

Konkrete Vorgehensweise: In einem Terminal einloggen (Strg+Alt+F1-6), schauen, was in .xsession-errors steht (falls vorhanden), mit "find ~ -user root" überprüfen, ob entsprechende Dateien im Home-Verzeichnis existieren. Diese ggf. löschen oder mit chown Benutzer und Gruppe anpassen.

@supertux
Ich habe keine Lust mehr mit dir über sudo zu disktutieren. Du scheinst dich mit vielen Innereien von Linux nicht auszukennen, schon "sudo startx" war absolut unnötig. Ich bin gerne bereit, Sachen zu erklären, aber du zeigst absolut kein Interesse und bleibst stur.

 

[supertux]

Nachdem ich auf meinem (absolut problemlos laufenden) Xubuntu System mit

find ~ -user root

28 Dateien des root users gefunden habe würde ich generell nicht empfehlen diese alle zu löschen.
Bei dem gegebenen Problemen

mit chown Benutzer und Gruppe anpassen

ist aber zumindest zu Debuggingzwecken eine sehr gute Idee
(wenn man gewissenhaft vorgeht sich alles merkt und keine Änderung des Problems erwirkt kann man danach die Rechte ja wieder zurücksetzen.)

@SammysHP Ich bin auch nur freiwillig in diesem Forum, möchte anderen helfen und mich dabei nicht mit anderen streiten. Das ich gerne meine Aussagen verteidige liegt wohl in meiner Art und war nicht als Angriff auf dich bestimmt (sorry wenn es sich so gelesen haben sollte) wenn es dir möglich ist wäre ich dir dankbar mich nicht generell als Linux Neuling darzustellen (ich arbeite seit 3 Jahren an der Uni nahezu täglich mit Linux und irgendwelche Beschuldigungen helfen dem Threadersteller auch nicht wirklich weiter)

 

[SammysHP]

Auch, wenn's nicht wirklich zum Thema passt: Damit hast du 28 Dateien in deinem Homeverzeichnis, die da nicht liegen sollten. Jedenfalls nicht mit dem Eigentümer. Mich würde interessieren, wie diese Dateien heißen.

 

[supertux]

Da ist unter anderem eine

.openoffice.org/3/user/registry/data/org/openoffice/Office/Common.xcu

und eine

dialog_settings.xml

von eclipse (Programmierumgebung)
einige weitere (schreib grad vom Desktop, daher will ich die nicht alle abtippen)
und ein paar alte debugging Dateien von Programmabstürzen sind auch dabei (da hast du recht, die könnte ich unbesorgt löschen)

bei admin Dateien bin ich (als früherer Windows Nutzer) eher sparsam mit irgendwelchen Löschaktionen ;-)

P.S: sollten die home/benutzername/.programmname Ordner die bei Programminstallationen erstellt werden nicht auch root gehören? (oder steht da was anderes dahinter)

 

[SammysHP]

Die ".programmname" Verzeichnisse werden nicht bei der Installation von Programmen (genauer gesagt: Paketen) installiert. Wenn du ein Paket installierst, dann geschieht das Systemweit. Die Dateien werden dann quer verstreut in /usr/bin, /usr/share, /usr/lib etc. entpackt. In deinem Homeverzeichnis liegen dann lediglich deine persönlichen Konfigurationsdateien. Du darfst nicht vergessen, dass Linux als Mehrbenutzersystem konzipiert ist. Selbst wenn du dein Homeverzeichnis komplett löscht, können andere Benutzer ganz normal weiterarbeiten. Deswegen wird "sudo apt-get install..." auch keine Dateien in deinem Homeverzeichnis ablegen.

Wenn da "debugging Dateien von Programmabstürzen" mit root als Owner liegen, dann wirst du die mit sudo ausgeführt haben (warum?). Auch eclipse legt bei mir keine Dateien von root an. Wie auch - nur mit su-Rechten darf man den Dateieigentümer ändern. Da Eclipse ganz normal mit den Benutzerrechten arbeitet, ist das völlig unmöglich (wenn doch, dann ist da eine Sicherheitslücke in Linux).

 

[supertux]

ok, dann bin ich wohl an der dialog_settings.xml selbst schuld (war dann wohl mal 'ne unüberlegte Spontanaktion in einer Programmiernacht )
(die debugging dateien können noch aus der Zeit in der ich mit einem korrupten grafiktreiber zu schaffen hatte stammen (hatte da öfter kernel panics und hin und wieder mal einen Dateimanager mit sudo rechten offen)
das einzige was mich noch stutzig macht sind die dateien von openoffice, das hatte ich nämlich soviel ich weiß nie mit sudo rechten geöffnet
aber egal, mein System läuft ja und ich bin in Sachen Benutzerkontentrennung von Linux wieder mal schlauer geworden.

Bevor wir den Thread wieder seiner eigentlichen Bestimmung überlassen: Wieso arbeitet Sudo eigentlich weiterhin im aktuellen Nutzerkonto (des aufrufenden Sudoers)?

 

[SammysHP]

Weil du immer noch als dieser Benutzer eingeloggt bist. Der Prozess wird lediglich unter einem anderen Benutzer ausgeführt, das Environment bleibt aber gleich.

 

[supertux]

Zum Thema: falls es noch aktuell ist, dass noch Daten gesichert werden sollen, so müsste das von einer Live-CD aus funktionieren (es sei denn das System ist verschlüsselt)