zur Startseite

Druckausgabe von https://privat.albicker.org
Iveco Daily 4x4, Hunde und multithematisches Blog

Was man bei der Installation von Siduction Linux NICHT tun sollte - Teil 2

veröffentlicht am 18.08.2019 mit 768 Worten - Lesezeit: 4 Minute(n)

Nach den Erfahrungen im ersten Teil geht’s heute weiter mit weiteren Versuchen, eine meinen Bedürfnissen angepaßte Installation von Siduction durchzuführen. Einerseits hätte ich schon gerne zügig ein funktionierendes System, andererseits reizt mich die Analyse, was da so alles vor- und schiefgehen kann …

Wenn der Installer nicht schon gleich bei der Einrichtung des Systems mit meinen Partionen umgehen will, so läßt sich das vielleicht - wenn das System denn mal läuft - im Nachhinein reparieren(?).
Also auf ein Neues:

weitere Testinstallationen

Die Voraussetzungen sind nach wie vor dieselben: die Platte ist wie folgt aufgeteilt:

NAME     SIZE 
sda      1,8T  
├─sda1   200M  
├─sda2   65G  
├─sda3   24G  
└─sda4   1,7T  

mit einer zu 23 gefüllten vierten Partition. Die Daten dort liegen im Benutzerverzeichnis.

Einstellungen des Installers bei der Einrichtung der Benutzer:

Siduction Installer Benutzer anlegen

Versuch 4: die vierte Partition wird zunächst nicht eingebunden

Der Grundgedanke: Wenn der Installer “irgendwas” mit den Dateien auf der (späteren) /home-Partition tut, dann lasse ich ihn einen leeren /home-Ordner auf der root-Partition erstellen und binde die Partition selbst später in der /etc/fstab ein.

Das führt zu folgender Einrichtung der Partitionen im Installer:

=Bildbeschreibung=

Aus mir nicht nachvollziehbaren Gründen wurde mir diesmal die Option zur Verwendung der vierten Partition gar nicht angezeigt. Und so sieht die Zusammenfassung aus:

=Bildbeschreibung=

Und: Überraschung! Der Installer läuft durch, es läßt sich tatsächlich in das neue Betriebssystem booten!

Erwartungsgemäß zeigt lsblk drei verwendete Partitionen:

~$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0  1,8T  0 disk 
├─sda1   8:1    0  200M  0 part /boot/efi
├─sda2   8:2    0   65G  0 part /
├─sda3   8:3    0   24G  0 part [SWAP]
└─sda4   8:4    0  1,7T  0 part 
sr0     11:0    1 1024M  0 rom  

Die Datei /etc/fstab hat diesen Inhalt:

~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=AC99-DF83                            /boot/efi      vfat    defaults,noatime 0 2
UUID=18557377-cfec-4538-a1ff-xxxxxxxxd674 /              ext4    defaults,noatime 0 1
UUID=5bf38ce1-c80d-4a53-b41c-a694f4995feb swap           swap    defaults,noatime 0 2

Nachdem das Betriebssystem das erste Mal gestartet wurde, wird in der Datei /etc/fstab diese Zeile hinzugefügt:

UUID=22e837d9-27f3-44cc-811d-xxxxxxxx1f0a /home          ext4    defaults 0 2

und mittels mount -a die Partitionstabelle neu eingelesen. Anschließende Kontrolle durch lsblk:

~$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0  1,8T  0 disk 
├─sda1   8:1    0  200M  0 part /boot/efi
├─sda2   8:2    0   65G  0 part /
├─sda3   8:3    0   24G  0 part [SWAP]
└─sda4   8:4    0  1,7T  0 part /home
sr0     11:0    1 1024M  0 rom 

Die vierte Partition ist korrekt als /home eingebunden. Aber: der Schreibtisch ist voller Ordner und Dateien:

=Bildbeschreibung=

Was ist hier los? Wenn der so aussehen würde:

=Bildbeschreibung=

dann wäre das korrekt. Nun, dieses Problem ließ sich lösen durch Löschen aller versteckten Dateien im Benutzerverzeichnis und Neustart - da müssen irgendwelche alten Konfigurationsdateien des Cinnamon-Desktops nicht gepaßt haben. Bei der Analyse bin ich jedoch auf eine Merkwürdigkeit gestoßen:

Eine Abfrage der Eigenschaften des aktiven Benutzers erbringt:

~$ id
uid=1000({benutzername}) gid=1005({benutzername}) Gruppen=1005({benutzername}), 7(lp), 20(dialout), 24(cdrom), 25(floppy), 29(audio), 30(dip), 44(video), 46(plugdev), 100(users), 101(systemd-journal), 108(kvm), 114(lpadmin), 115(bluetooth), 116(netdev), 122(scanner), 1000(fuse), 1001(powerdev), 1002(storage), 1003(vboxusers), 1004(autologin)

Das unterscheidet sich hinsichtlich der Gruppenzugehörigkeit von allem, was ich bisher gesehen habe, denn da lautete die Zugehörigkeit in der Regel so: uid=1000({benutzername}) gid=1000({benutzername}) Gruppen=1000({benutzername}).

ls -lAF zeigt den Verzeichnisinhalt in ausführlicher Form an, auf die /home Partition angewandt werden die Benutzerverzeichnisse mit deren Berechtigungen (Benutzer und Gruppe) und Verzeichnisnamen angezeigt:

~$ ls -lAF /home
insgesamt 24
drwxr-xr-x 68 {benutzername} fuse      4096 Aug 11 09:53 {benutzername}/
drwxr-xr-x  3 1001           powerdev  4096 Dez  9  2018 {benutzer_no2}/
drwx------  2 root           root     16384 Dez  9  2018 lost+found/

Das würde erklären, was der Installer bei den ersten Installationsversuchen da so lange getrieben hat: Anpassung der Rechte der Files an die Benutzer-Eigenschaften.

Kleines “Schmankerl” zum Schluss der heutigen Folge:
Bei dem Versuch, Firefox zu starten, bekam ich diese hübsche Meldung:

Firefox Versionskonflikt Profil Datenbank

Siduction bringt mit:

~ $ firefox --version
Mozilla Firefox 68.0.1

und eine Gegenprobe bei Linux Mint 18.3 auf der anderen Platte erbringt die viel neuere Version:

~ $ firefox --version
Mozilla Firefox 68.0.1

… danke für’s Gespräch. Nicht einmal das Browserprofil läßt sich vernünftig weiterverwenden …

Erkenntnisse bis hierher:

Es erscheint nicht zielführend, Siduction auf einen Rechner zu installieren mit dem Ziel, ein bestehendes Nutzerverzeichnis in einfacher Weise einzubinden. Die Zuordnung der Gruppe zum Nutzer paßt nicht zu den Berechtigungen der vorhandenen Dateien im Benutzerverzeichnis.
(Das ist unproblematisch, wenn man Siduction auf einer gänzlich leeren Platte installiert und den Datenbestand erst danach in das /home-Verzeichnis kopiert)