Zu beachten ist dabei, daß in der Zeile
s=${s## }
nach dem ## ein Leerzeichen stehen muß.
Desgleichen muß in der Zeile
pid=${s%% *}
ein Leerzeichen vor dem * stehen.

Am schlimmsten ist mir aufgefallen, daß unter X (KDE) Speicherkarten mit Vfat im Card-Reader defaultmäßig mit bestimmten vorgegebenen Optionen gemountet werden (z. B. showexec). Die Option showexec bewirkt beim Einstecken einer Speicherkarte mit Vfat (Standard), daß nur bei .exe, .com und .bat files das Execute-Flag gesetzt werden kann.

Da es aber auch CDs/DVDs für Windows gibt, welche Software für Linux beinhalten, ist es unmöglich diese von der Speicherkarte zu starten. Das nachträgliche Remounten per mount oder udisks schafft keine Abhilfe, da das System offenbar seine vorgegebenen mount optionen NACH den User Optionen anfügt. Dadurch werden ev. gegebene Optionen des Users überschrieben.

Beispiel:
Da das Netbook kein CD-Laufwerk hat, habe ich eine CD mit Software für Windows und Linux auf eine Speicherkarte kopiert. Nun wird diese Speicherkarte beim Einstecken IMMER mit unpassenden Optionen gemountet, die es mir unmöglich machen die Linux-Software darauf zu benutzen.

Abhilfe ist (unter KDE) für USB-Massenspeichergeräte folgendermaßen möglich:

Bei den Kernel-Updates von Evergreen ist das Kernel-mode-setting standardmäßig eingeschaltet. Dies bewirkt u.a. daß die Schrift, wenn man per CLI arbeitet, so klein ist, daß man sie kaum lesen kann.

Für Abhilfe siehe unter openSUSE 12.2


openSUSE Linux 12.2

Die Installation von einem ISO-image auf Desktop-PC verlief reibungslos. Der 1. Start brachte dann aber eine Überraschung - es wird nun standardmäßig KMS benutzt. Das hat zur Folge, daß die Grafikkarte in die höchstmögliche Auflösung geschaltet wird. Wer in Runlevel 5 arbeitet, den wird's nicht stören. Wer aber in den Runlevel 3 bootet und per CLI arbeitet, der hat nun das Problem, daß man die Schrift mit einer Lupe lesen muß. Das betrifft auch die virtuellen Konsolen auf die man später von X her umschalten will, wenn man X per 'startx' gestartet hat.

Abhilfe ist auf 2 Arten möglich:

Auf einem Desktop-Rechner mit Standard-Hardware würde ich Möglichkeit 2 empfehlen. Auf einem Notebook/Netbook mit Hardware welche KMS benötigt, würde ich Möglichkeit 1 empfehlen.

Die nächste unangenehme Überraschung - es ist nicht mehr möglich /dev/shm mit dem tmpfs einzusetzen, d.h. man wird nun auf eine komfortable Ramdisk verzichten müssen.


openSUSE Linux 13.2

Die Installation an sich verlief reibungslos. Keine Probleme mit Geräten. Leider funktioniert der Apache nicht richtig - das Einrichten von virtual hosts will nicht mehr gelingen. Und die Umstellung von Sysinit auf Systemd bringt enorme Umstellungsschwierigkeiten mit sich. Wurde früher ein Init-Script einfach per pathname mit den Kommandos start/stop/restart usw. aufgerufen, so muß das jetzt per systemctl geschehen. Das sieht dann z.B. so aus:
systemctl KOMMANDO INIT-SCRIPT --> systemctl restart firewall
Habe seit Anfang 1998 Sysinit benutzt - und nun DAS! Ich kann/will mich einfach nicht daran gewöhnen :-/

Die anfänglichen Umstellungsschwierigkeiten sind überwunden. Zwar halte ich Systemd für eine unnötige Fehlkonstruktion (der Bootprozess von meiner SSD geht auch nicht schneller) aber da die Distribution nun so ausgelegt ist benutze ich sie so.


openSUSE Leap 15.2

2022 habe ich Leap 15.2 auf einem Notebook installiert. So weit so gut. Das System läuft rund. Aber das neue KDE System ist scheußlich! Es ist nicht mehr möglich virtuelle Desktops mit eigenen icons und eigenen Hintergrund Wallpapers zu benutzen. Was haben sich die KDE Leute dabei gedacht als sie das von einem guten Desktop Environment entfernt haben?! Sind die blöd?


openSUSE Leap 15.5

Vom 08.12.23 bis zum 09.12.23 habe ich einen neuen Rechner aufgebaut. Am 10.12.23 habe ich Leap 15.5 darauf installiert. Der Rechner ist super!!! Als erstes mußte ich eine neue Firmware auf die Hauptplatine flashen. Daß das sogar ohne CPU geht war mir neu.

Als Boot-Laufwerk ist eine SSD installiert. Die Installation ging dann ganz einfach von einer bereits erstellten DVD. Die Partitionierung der völlig leeren SSD habe ich meinen Vorstellungen angepaßt. Zuerst habe ich die EFI-Partition angelegt. Größe auf 200 MB, Name ist 'EFI System' und als Filesystem vfat. Hatte gedacht, daß Yast weiß welchen FS-Typ die EFI-Partition braucht. Alle gewünschten Partitionen angelegt und fertig. Wie immer Installationsprofil 'Grafisches Sys' gewählt und los gings. Eine zusätzliche HDD habe ich erst nach der Inbetriebnahme des Rechners eingebaut. Dies ist ein reines Daten-Laufwerk. Die Arbeit mit dem neuen Rechner und dem neuen System war prima. Mußte natürlich erst alles einrichten. Für die wichtigsten Dinge brauchte ich 2 Tage. Gewohnheitsmässig habe ich die Partitionen in der fstab mit den devicenamen (/dev/sdax, /dev/sdb1) angegeben. Am 3. Tag bootet das System dann in den Emergency Mode! Ein Blick ins Logfile offenbart mehrere Fehler:

a) 'EFI Partition nicht erkannt' oder so ä. Das Installations-Tool von Yast hat für die EFI-Partition FAT16 benutzt. Für Desktop Rechner sollte es FAT32 sein. Dies scheint aber nicht der Grund für das fehlerhafte booten zu sein.

b) Der fsck der 1. Partition der 2. Disk (eine HDD) prodzuierte einen Fehler weil der Superblock nicht lesbar war. Eine Restauration des Superblocks half nicht. Eine Analyse der HDD ergab dann, daß aufgrund zunehmender Fehler wohl das Ende der Lebenszeit dieser HDD erreicht sei. Sie sollte deshalb so bald als möglich durch eine neue ersetzt werden. Habe sie dann gegen eine neue SSD ausgetauscht.

c) Die Einträge in der fstab waren nicht in der Reihenfolge wie das System sie gerne hätte. In meinen ganzen Jahren mit Linux hatte das nie eine Rolle gespielt. Aber nun fing das System deswegen an zu meckern. OK - hab also die Einträge in der richtigen Reihenfolge angelegt.

d) Die Laufwerksbuchstaben werden alle paar boots vertauscht (ich habe eine SSD als Boot-Laufwerk und eine HDD als reines Daten-Laufwerk verbaut).

Punkt b) und c) waren also korrigiert. Bleiben noch Punkt a) und d).
a) es lag offensichtlich an dem falschen Laufwerksbuchstaben durch die Vertauschung (Von der Daten-disk kann nicht gebootet werden). Deshalb ging das natürlich in die Hose und das System bootete in den Emergency Mode. Bei der nächsten Vertauschung war der Reboot dann wieder OK. Das ging so jeden 2. - 3. Tag. Meine Lösung: Ersetzen der devicenamen durch Angabe der jeweiligen UUID in der fstab. Seitdem bootet der Rechner nun endlich korrekt.
Gegen das Vertauschen der Laufwerksbuchstaben habe ich noch keine Lösung gefunden. Es könnte an dem geflashten BIOS des Mainboards liegen oder am Kernel der LEAP 15.5.