Nach dem Wechsel von einer AMD zu einer NVIDIA-Graphikkarte blieb, trotz der Anweisung an den Uninstaller, bitte alles von AMD zu entfernen, noch das AMD External Events Utility als Dienst installiert, welches bei jedem Systemstart automatisch ausgeführt wurde. Leider ist unter “Programme und Funktionen” keine weitere Möglichkeit vorgesehen, den nicht mehr benötigten Dienst loszuwerden.

Der erste Weg sollte in die Dienst-Verwaltung von Windows führen, wo neben der Änderung des Starttyps auf “Deaktiviert” der Dienst auch direkt gestoppt werden kann.

Gleichzeitig kann aus diesem Dialog auch der interne Name des Dienstes (in diesem Fall identisch mit dem Anzeigenamen) sowie der Pfad zur ausführbaren Datei entnommen werden.

Die graphische Oberfläche bietet leider keine weiteren Möglichkeiten, einen Dienst aus dem System zu entfernen, dies kann aber über die Kommandozeile vorgenommen werden.

Nachdem man sich mit “query” nochmal vergewissert hat, auch den richtigen Dienst löschen zu wollen

C:\Windows\system32>sc query "AMD External Events Utility"

SERVICE_NAME: AMD External Events Utility
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 1  STOPPED
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

kann die eigentliche Löschung dann mittels dem Parameter “delete” der Dienst aus der Systemkonfiguration entfernt werden.

C:\Windows\system32>sc delete "AMD External Events Utility"
[SC] DeleteService ERFOLG

Wer mutig ist noch weiter aufräumen möchte, kann anschließend noch eine Säuberung des “%SYSTEMROOT%\System32”-Verzeichnisses vornehmen, in dem aber neben der eigentlichen Dienstdatei “atiesrxx.exe” noch weitere 37 Dateien zu finden sind, welche alle mit “ati*” beginnen.

Sollte Windows 7 das Erstellen eines Systemabbilds mit einem Fehler 0x8004231F “Nicht genügend Speicherplatz” abbrechen, so können die Ursachen vielfältig sein, liegen aber oft im Bereich der Volumenschattenkopie.

Ein erster Klick sollte deshalb in die Computerverwaltung führen, wo neben dem tatsächlich noch freien Platz in der Datenträgerverwaltung auch gleich der Status des Dienstes “Volumenschattenkopie” überprüft werden sollte: dieser darf nicht auf “Deaktiviert” stehen, sondern muß beim Starttyp “Automatisch” oder “Manuell” als Eintrag haben.

Als nächtes sollte in einer administrativen Eingabeaufforderung der Befehl “vssadmin list shadowstorage” ausgeführt werden, der Auskunft über die aktuelle Konfiguration gibt.

Sofern hier ein “Es wurde keine Ergebnisse für die Abfrage gefunden.” zurückgegeben wird, ist die Ursache lokalisiert: es ist zwar Speicherplatz auf dem Datenträger vorhanden und der Dienst wurde gestartet, es steht aber kein dedizierter Speicherplatz für die Schattenkopien zur Verfügung.

Dieser kann entweder manuell eingerichtet werden oder alternativ über ein kurzzeitiges Aktivieren (und anschließendes Deaktivieren) des Systemschutzes für das zu sichernde Laufwerk, damit ggf. die fehlenden Zuweisungen automatisch vorgenommen werden.

Standardmäßig ist bei Debian die NumLock-Funktion auf der Konsole nach dem Boot deaktiviert. Ist dies bei physikalischen Servern in der Regel kein größeres Ärgernis, da man nur selten direkt an der Konsole arbeitet und noch seltener neu startet, kann es bei einer auf dem lokalen Arbeitsplatz betriebenen virtuellen Maschine nerven: je nach verwendeter Virtualisierungslösung wird beim Boot der VM auch unter Windows die NumLock-Taste ausgeschaltet, was mehr als nervig ist.

bis Debian 7 “Wheezy”:

Die Lösung ist recht einfach - ein Skript namens “enablenumlock”

### BEGIN INIT INFO
# Provides: enablenumlock
# Required-Start: $syslog
# Required-Stop: $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Enables numlock on console
# Description: Enables numlock on console at boot time.
### END INIT INFO

# Aktionen
case "$1" in
 start)
 /usr/bin/setleds -D +num
 ;;
stop)
 /usr/bin/setleds -D +num
 ;;
restart)
 /usr/bin/setleds -D +num
 ;;
esac

exit 0

ins Verzeichnis “/etc/init.d” gepackt, ausfrührbar gemacht und dann mittels

update-rc.d enablenumlock defaults

in den Systemstart eingebunden. Beim nächsten Boot wird NumLock automatisch aktiviert.

ab Debian 8 “Jessie”:

Durch den Umstieg von sysvinit zu systemd funktioniert die oben geschilderte Lösung nicht mehr zuverlässig. Einfache Abhilfe schafft der Ansatz aus dem archlinux Wiki, welcher dem Dienst “getty@.service” zwei Zeilen hinzufügt:

# systemctl edit getty\@.service

[Service]
ExecStartPre=/bin/sh -c 'setleds +num < /dev/%I'

Nach einen Neustart ist Numlock dann wieder standardmäßig aktiviert. Wer sich an dem angezeigten Hint stört, findet im Wiki auch eine Möglichkeit, dessen Ausgabe zu unterdrücken.

Ein Upgrade von Debian Jessie nach Stretch ist schnell erledigt: in der Datei “/etc/apt/sources.list” alle Einträge, die auf “jessie” lauten durch “stretch” ersetzen und anschließend mit

apt-get update
apt-get upgrade
apt-get dist-upgrade

das System auf die neue Version aktualisieren.

Das Upgrade lief auch problemlos durch, allerdings war nach einem Reboot kein Netzwerk (mehr) vorhanden:

root@sandbox:~# ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Lokale Schleife)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Während vor dem Reboot die Netzwerkkarte noch mit “eth0” identifiziert wurde

root@sandbox:~# networkctl
WARNING: systemd-networkd is not running, output will be incomplete.

IDX LINK             TYPE               OPERATIONAL SETUP
  1 lo               loopback           n/a         unmanaged
  2 eth0             ether              n/a         unmanaged

2 links listed.

wurde nach dem Reboot die Netzwerkkarte als “enp0s3” erkannt:

root@sandbox:~# networkctl
WARNING: systemd-networkd is not running, output will be incomplete.

IDX LINK             TYPE               OPERATIONAL SETUP
  1 lo               loopback           n/a         unmanaged
  2 enp0s3           ether              n/a         unmanaged

2 links listed.

Nachdem in der Datei “/etc/network/interfaces” alle Einträge von “eth0” durch “enp0s3” ersetzt wurden, stand nach einem weiteren Reboot das Netzwerk wieder zur Verfügung.

Zwar hat Microsoft inzwischen im laufenden Betrieb die Werbung für Windows 10 weitesgehend eingestellt, dafür aber an anderer Stelle plaziert:

“Hier noch eine wichtige Information” prangt nach erfolgter Windows 7-Installation auf dem Bildschirm und der Text lässt vermuten, daß der Weg zur ewigen Glückseeligkeit ausschließlich im Upgrade auf Windows 10 liegt, während “Update auf Windows 7 (SP1)” (für das sehr wohl noch Windows Update-Sicherheitsfixes erhältlich sind) im gleichen Stil wie “Diese Meldung nicht mehr anzeigen” dargestellt wird. Daß auch nicht explizit darauf hingewiesen wird, wie man Windows 7 sicher betreiben kann, versteht sich fast von selbst …