| Autor |
Nachricht |
|
|
|
Titel: Der Durchstart von meinem Spitfire Computer.
 Verfasst am: 17.11.2015, 12:45 Uhr
|
|
Anmeldung: 18. Okt 2006
Beiträge: 185
|
|
Hallo.
Ich betreibe schon einige Monate lang einen Computer mit Kanotix Spitfire, und bin mit dem insgesamt zufrieden.
Code:
dirk@Phoenix:~$ infobash -v
Host/Kernel/OS "Phoenix" running Linux 3.18.0-14-generic x86_64 [ Kanotix Spitfire-nightly Spitfire64 150612a KDE-special ]
CPU Info (1) AMD Athlon 64 X2 Dual Core 5000+ clocked at [ 1800.000 MHz ]
(2) AMD Athlon 64 X2 Dual Core 5000+ clocked at [ 1800.000 MHz ]
Videocard NVIDIA C61 [GeForce 6150SE nForce 430] X.Org 1.16.4 [ 1600x1200 ]
Processes 227 | Uptime 1day | Memory 1080.7/1874.1MB | HDD Size 320GB (26%used) | GLX Renderer GeForce 6150SE nForce 430/integrated/SSE2 | GLX Version 2.1.2 NVIDIA 304.125 | Client Shell | Infobash v2.67.2
dirk@Phoenix:~$
Zuletzt sah ich aber, daß er bei einem Neustart manchmal hängen blieb. Und ich habe sehr viel Software installiert, die dazu beitragen kann.
Es könnte eventuell möglich sein, daß das Verhalten von dem Paket
lm-sensors
verursacht wurde, was ich vor weniger als einem Monat installierte.
service lm-sensors start , bezw.
/etc/init.d/lm-sensors start
soll bei den moderneren Versionen des Pakets, schon Kernelmodule laden, die helfen sollen daten über die Hardware zu ermitteln.
Aber, so wie das Debian Paket konfiguriert ist, führt es keinen
/etc/init.d/lm-sensors stop
Befehl aus, wenn man dem Computer einen Neustart befehlt. Den Dienst zu stoppen, soll ein paar Module wieder entladen. Also könnten solche Kernelmodule gestört haben.
Das Paket habe ich jetzt deinstalliert, wobei der Paket-Manager auch deinstallierte Dienste stoppt. Ob das gewirkt hat werde ich sehen, bei dem nächsten Neustart.
Dirk |
Zuletzt bearbeitet von dirkmitt am 22.12.2015, 20:26 Uhr, insgesamt 2 Male bearbeitet
|
| |
|
|
|
 |
|
|
|
Titel: Der Durchstart von meinem Spitfire Computer.
Verfasst am: 17.11.2015, 19:20 Uhr
|
|
Anmeldung: 17. Dez 2003
Beiträge: 16792
|
|
Meistens liegt das an einem nachinstalliertem TeamViewer, also einfach
Code:
dpkg --purge teamviewer
|
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 17.11.2015, 21:33 Uhr
|
|
Anmeldung: 18. Okt 2006
Beiträge: 185
|
|
Es tut mir Leid Kano, aber das war mein Ergebnis:
Code:
dirk@Phoenix:~$ su
Password:
root@Phoenix:/home/dirk# dpkg --purge teamviewer
dpkg: warning: ignoring request to remove teamviewer which isn't installed
root@Phoenix:/home/dirk#
Jetzt ist mir aber etwas aufgefallen. Ich hatte mir vor einiger Zeit das Debian-Paket 'colord' installiert, um auf meinem Monitor (GPU-basierte) Farbkorrektur zustande zu bringen. Und um das Paket von dem System Settings Panel einstellen zu können, habe ich mir außerdem das Paket 'colord-kde' installiert. Aber das Paket 'colord-kde' unterscheidet sich von dem anderen, indem es nicht in den Debian-Repos vorkommt. Das habe ich mir als KUbuntu-Paket getrennt installiert, und es kontrolliert die Farbkorrektur erfolgreich. (!)
colord-kde startet den Dienst wie hier:
Code:
dirk@Phoenix:~$ ps fu -A | grep colord
colord 1053 0.0 0.4 347592 8728 ? Ssl Nov15 0:01 /usr/lib/colord/colord
dirk 28149 0.0 0.1 12720 2172 pts/1 S+ 17:33 0:00 \_ grep --color=auto colord
dirk@Phoenix:
Und wie Sie sehen können, läuft dieser Dienst unter dem Benützername 'colord' . Der Dienst wird auch im KDE System Settings Panel angezeigt.
Weiter dazu, gehorcht es scheinbar 'systemctl' :
Code:
root@Phoenix:/home/dirk# systemctl status colord
● colord.service - Manage, Install and Generate Color Profiles
Loaded: loaded (/lib/systemd/system/colord.service; static)
Active: active (running) since Sun 2015-11-15 19:30:41 EST; 1 day 22h ago
Main PID: 1053 (colord)
CGroup: /system.slice/colord.service
└─1053 /usr/lib/colord/colord
Nov 17 06:38:29 Phoenix colord[1053]: Automatic remove of PIXMA_MX922-RGB.. from cups-PIXMA_MX922
Nov 17 06:38:29 Phoenix colord[1053]: Profile removed: PIXMA_MX922-RGB..
Nov 17 06:38:29 Phoenix colord[1053]: device removed: cups-PIXMA_MX922
Nov 17 06:38:31 Phoenix colord[1053]: Profile added: PIXMA_MX922-Gray..
Nov 17 06:38:31 Phoenix colord[1053]: Profile added: PIXMA_MX922-RGB..
Nov 17 06:38:31 Phoenix colord[1053]: (colord:1053): Cd-WARNING **: failed to get session [pid 32418]: Unknown error -2
Nov 17 06:38:31 Phoenix colord[1053]: Automatic database add PIXMA_MX922-Gray.. to cups-PIXMA_MX922
Nov 17 06:38:31 Phoenix colord[1053]: Automatic database add PIXMA_MX922-RGB.. to cups-PIXMA_MX922
Nov 17 06:38:31 Phoenix colord[1053]: Automatic database add icc-45f8f9e131fcbc839dbcfd55800650da to cups-PIXMA_MX922
Nov 17 06:38:31 Phoenix colord[1053]: Device added: cups-PIXMA_MX922
root@Phoenix:/home/dirk#
Ich meine inzwischen bemerkt zu haben, daß nach einem unsauberen Neustart die Partition sda2 ('/home') mehr leidet, als die Partition sda1 ('/') .
Jedoch installiert dieses Paket keine Datei, in das Verzeichnis
/etc/init.d ... /colord
Vermutlich verwendet KUbuntu ein anderes System als Debian oder Kanotix, um solche Dienste eventuell zu stoppen. Ich bin der Meinung daß es unbedingt einen Eintrag in
/etc/rc6.d und
/etc/rc0.d
geben muß, um so einen Vorgang zu stoppen.
Also, Scham auf mich , daß ich mal wieder ein Paket installiert habe, das nicht direkt aus den Debian Repos kam.  Aber, mir gefällt die Farbkorrektur, und das Paket möchte ich weiter verwenden.
Was ich also zuletzt getan habe, war manuell in den Verzeichnissen '/etc/rc6.d' und '/etc/rc0.d' Symlinks einzufügen, die den Vorgang definitiv stoppen werden.
Code:
#!/bin/bash
### BEGIN INIT INFO
# Provides: colord_stop
# Required-Start:
# Required-Stop:
# Default-Start:
# Default-Stop: 0 6
# Short-Description: Initialize iptables rules.
# Description:
### END INIT INFO
# /etc/colord_stop
# Problem: colord-kde package has no /etc/init.d
# entry. Create one in rc6.d and rc0.d
PATH=/bin:/usr/bin:/sbin:/usr/sbin
systemctl stop colord
exit 0
Und zwar, vor dem kdm Stopp.
Ich schlage niemandem vor , sein System so zurecht zu Ferkeln , wie ich es hier gerade tue. Aber demnächst werde ich jetzt mit etwas besserer Zuversicht beobachten, ob der nächste Neustart vielleicht erfolgreich laufen wird.
Dirk |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 18.11.2015, 02:30 Uhr
|
|
Anmeldung: 17. Dez 2003
Beiträge: 16792
|
|
| Ubuntu hat vor 15.04 kein systemd sondern Upstart benützt. Als kleine Optimierung - insbesondere bei Autologin mit /home - in der /etc/fstab statt "nofail" lieber "defaults" in der Zeile mit /home verwenden. Vielleicht behebt das dein Problem. |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 18.11.2015, 07:37 Uhr
|
|
Anmeldung: 18. Okt 2006
Beiträge: 185
|
|
Diesen Ratschlag habe ich sofort in meine /etc/fstab eingebunden. Also, irgendwo zwischen den mehrfachen möglichen Lösung, dürfte es eigentlich eine geben, die funktioniert. Danke noch mal wegen der Hilfe. Etwas was diese Prognose etwas deprimiert, ist daß ja das Dateisystem mit /home bereits gemountet ist. Die neue Option im fstab tritt also nur ein, nachdem der nächste Neustart stattgefunden hat. Sollte das also die richtige Lösung sein, erfahre ich das erst beim übernächsten Neustart...
Dirk |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 18.11.2015, 15:54 Uhr
|
|
Anmeldung: 27. Jun 2007
Beiträge: 409
|
|
|
dirkmitt hat folgendes geschrieben::
Etwas was diese Prognose etwas deprimiert, ist daß ja das Dateisystem mit /home bereits gemountet ist. Die neue Option im fstab tritt also nur ein, nachdem der nächste Neustart stattgefunden hat. Sollte das also die richtige Lösung sein, erfahre ich das erst beim übernächsten Neustart...
Dirk
Man kann Änderungen an der /etc/fstab sofort wirksam werden lassen, in dem man anschließend
Code:
# mount -a
ausführt. |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 18.11.2015, 16:16 Uhr
|
|
Anmeldung: 17. Dez 2003
Beiträge: 16792
|
|
| In dem Fall ändert sich da nix - außer dass man wohl Tippfehler in der Datei finden würde. Es ist beim nächsten Start aktiv. Wie man auf den übernächsten kommt ist mir nicht klar. |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 18.11.2015, 19:55 Uhr
|
|
Anmeldung: 18. Okt 2006
Beiträge: 185
|
|
Was ich nur meinte war: Ich habe ja keine Probleme, das Dateisystem zu mounten. Es läuft sogar sehr gut. Nur habe ich den Verdacht, daß es vielleicht nicht richtig unmounted, wenn der Neustart nicht sauber war. Und die Option die Kano erwähnt hat, würde vermutlich dabei helfen (beim unmounten), wenn das Dateisystem mit der Option gemountet wurde. Was jetzt zwar in der fstab steht, was aber noch nicht als Parameter angewandt wurde, bei dem kommenden Mount-Befehl.
Dirk |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 22.12.2015, 20:30 Uhr
|
|
Anmeldung: 18. Okt 2006
Beiträge: 185
|
|
Bei der Server-Maschine scheint das Problem gelöst zu sein. Nachdem sie 32 tagelang lief, war mal wieder ein Update erforderlich, der daraufhin einen Neustart erforderte. Und als ich vom KDE-Menü den Neustart befahl, wurde der Shutdown auch vollständig und ohne Meldungen ausgeführt. Denn, bei "quiet" werden Meldungen nur angezeigt, wenn ein Fehlerzustand gemeldet wurde. Und deswegen gab es bei dem Start danach auch keinerlei Fehler oder Meldungen.
Dirk |
|
|
| |
|
|
|
|
|
|
|
|
|
|
