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) in * LINUX *
Inhaltsverzeichnis
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 2/3 gefüllten vierten Partition. Die Daten dort liegen im Benutzerverzeichnis.
Einstellungen des Installers bei der Einrichtung der Benutzer:
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:
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:
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:
Was ist hier los? Wenn der so aussehen würde:
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:
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)
weitere Artikel
- Was man bei der Installation von Siduction Linux NICHT tun sollte - Teil 3
- Was man bei der Installation von Siduction Linux NICHT tun sollte
- Linux-Installation (Debian) mit verschlüsseltem Datenträger (LUKS, LVM)
- Warum eine neue/andere Linux-Distribution?
- Überzählige UEFI-Booteinträge löschen