Was man bei der Installation von Siduction Linux NICHT tun sollte - Teil 3
veröffentlicht am 19.08.2019 mit 926 Worten - Lesezeit: 5 Minute(n) in * LINUX *
Inhaltsverzeichnis
Nach den Erfahrungen im zweiten Teil geht’s heute weiter mit ergänzenden/abschließenden Versuchen, eine meinen Bedürfnissen angepaßte Installation von Siduction durchzuführen. Ein paar Dinge sind noch abzuklären, bevor ich das Thema für mich beende - so oder so …
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.
Die Einstellungen des Installers bei der Einrichtung der Benutzer habe ich diesmal aber insoweit geändert, daß ich (wie bei Ubuntu und Mint üblich) auf ein separates Admin-Passwort verzichtet habe:
Ziel der Aktion: ich wollte sehen, ob und welchen Einfluß das auf die Gruppenzugehörigkeit des Benutzers hat.
Versuch 5: Manuelle Zuordnung der Partitionen, gemeinsames Paßwort für User und Admin
Begonnen habe ich auch hier wieder mit der manuellen Zuordnung der vorhandenen Partitionen:
und damit hat der Installer dann dieses zu erledigen:
Um es vorweg zu nehmen: Bei diesem Versuch konnte ich mal wieder keine Berechtigungen testen, denn der Installer fing wieder an, tausende von Dateien zu “bearbeiten”. Bei den üblichen 36% zeigte das Logfile mal wieder:
19:20:41 [6]: Starting job "fllfixhome"
19:20:41 [6]: Job file "/usr/lib/x86_64-linux-gnu/calamares/modules/fllfixhome/main.py"
19:20:41 [6]: Job description from __doc__ "fllfixhome" = "Remove some fll leftovers - thats what the fll-installer would do."
19:20:41 [6]: Running "chroot" ("/tmp/calamares-root-ho4c4q1s", "/bin/mv", "/home/siducer", "/home/{benutzername}")
19:20:42 [6]: Finished. Exit code: 0
19:20:42 [6]: Target cmd: ("/bin/mv", "/home/siducer", "/home/{benutzername}")
19:20:42 [6]: Target output:
19:20:42 [6]: Running "chroot" ("/tmp/calamares-root-ho4c4q1s", "chown", "-R", "{benutzername}:", "/home/{benutzername}")
19:20:42 [6]: Finished. Exit code: 1
19:20:42 [6]: Target cmd: ("chown", "-R", "{benutzername}:", "/home/{benutzername}")
19:20:42 [6]: Target output:
chown: invalid spec: '{benutzername}:'
19:20:42 [6]: Running "chroot" ("/tmp/calamares-root-ho4c4q1s", "/bin/sh", "-c", "/usr/bin/find /home/{benutzername} -type f -exec /bin/sed -i 's|/home/siducer|/home/{benutzername}|g' {} \\;")
bis ich das Unterfangen dann von Hand abbrach:
19:26:40 [0]: file:///usr/share/calamares/qml/calamares/slideshow/Presentation.qml:114: TypeError: Cannot read property 'delayPoints' of undefined
19:26:44 [8]: Shutting down Calamares...
19:26:44 [8]: .. Finished shutdown.
19:26:44 [0]: QProcess: Destroyed while process ("chroot") is still running.
Und wie die letzte Meldung zeigte, mußte ich auch hier den Prozess chroot separat abbrechen - hier am einfachsten durch Neustart: mit diesem Installationsversuch war sowieso kein funktionierendes System zu erwarten.
Also hab ich zurück in mein funktionierendes Linux Mint 18.3 gebootet, um das Dateichaos auf der zweiten Platte wieder in Ordnung zu bringen - waren rund 30GB an Files, die da “aktualisiert” wurden und die ich wieder auf den Originalstand bringen konnte.
Beispiel wie gehabt:
~/Dokumente $ stat 273_Windows_XP_wird_eingestellt__Tauchcenter_stellt_auf_Linux_um.pdf
Datei: 273_Windows_XP_wird_eingestellt__Tauchcenter_stellt_auf_Linux_um.pdf
Größe: 307795 Blöcke: 608 EA Block: 4096 reguläre Datei
Gerät: 804h/2052d Inode: 22157515 Verknüpfungen: 1
Zugriff: (0640/-rw-r-----) Uid: ( 1000/{benutzername}) Gid: ( 1000/ fuse)
Zugriff : 2019-08-18 19:20:54.858133771 +0200
Modifiziert: 2019-08-18 19:20:54.867133564 +0200
Geändert : 2019-08-18 19:20:54.867133564 +0200
Geburt : -
~/Dokumente $ stat 273_Windows_XP_wird_eingestellt__Tauchcenter_stellt_auf_Linux_um.pdf
und das Original auf der Mint-Platte:
~/Dokumente $ stat 273_Windows_XP_wird_eingestellt__Tauchcenter_stellt_auf_Linux_um.pdf
Datei: '273_Windows_XP_wird_eingestellt__Tauchcenter_stellt_auf_Linux_um.pdf'
Größe: 307795 Blöcke: 608 EA Block: 4096 Normale Datei
Gerät: 814h/2068d Inode: 35782712 Verknüpfungen: 1
Zugriff: (0640/-rw-r-----) Uid: ( 1000/{benutzername}) Gid: ( 1000/{benutzername})
Zugriff : 2019-08-14 22:59:40.210549829 +0200
Modifiziert: 2014-02-24 21:05:16.000000000 +0100
Geändert : 2019-08-17 22:22:57.319134452 +0200
Geburt : -
Die Gruppenzugehörigkeit wurde also von ursprünglich 1000/{benutzername} auf 1000/ fuse geändert - was immer das soll …
Versuch 6: Partition ersetzen, /home von Hand zuordnen, gemeins. Paßwort für Benutzer und Admin
Der letzte Versuch startet also mit dieser Konfiguration des Installers:
Und wie bei den vorherigen Versuchen dieser Art lief auch hier der Installer sauber durch und das neu installierte System startete. Auch hier habe ich wieder das /home-Verzeichnis in die /etc/fstab nachgetragen, das Benutzerverzeichnis zeigte schön den Inhalt der vierten Partition an.
Wenig gefiel mir hingegen die Abfrage des Benutzers
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)
Auch hier wieder: der aktive Benutzer wird der Gruppe 1005 zugeordnet, derweil die Gruppe 1000 hier mal wieder fuse heißt. Erklärung? keine.
Und das Chaos zieht sich munter durch das home-Verzeichnis des aktiven Benutzers durch (ich habe hier nur einen kleinen Auszug wiedergegeben):
~$ ls -Al
insgesamt 834744
drwxr-xr-x 16 {benutzername} fuse 12288 Aug 18 18:01 Bilder
drwxrwxr-x 4 {benutzername} fuse 4096 Aug 4 07:31 bin
drwxr-xr-x 9 {benutzername} {benutzername} 4096 Aug 18 20:02 .cache
drwxrwxr-x 5 {benutzername} fuse 4096 Aug 4 06:51 Cache
drwxr-xr-x 3 {benutzername} {benutzername} 4096 Aug 18 18:16 .cinnamon
drwxr-xr-x 13 {benutzername} {benutzername} 4096 Aug 18 18:38 .config
drwxr-xr-x 2 {benutzername} {benutzername} 4096 Aug 18 19:57 Desktop
-rw-r--r-- 1 {benutzername} {benutzername} 27 Aug 3 21:29 .dmrc
drwxr-xr-x 11 {benutzername} fuse 24576 Aug 18 19:20 Dokumente
drwxr-xr-x 29 {benutzername} fuse 12288 Aug 15 19:05 Downloads
drwxr-x--- 2 {benutzername} fuse 4096 Dez 10 2018 .filezilla
-rw------- 1 {benutzername} {benutzername} 5804 Aug 18 20:02 .ICEauthority
-rw-r--r-- 1 {benutzername} {benutzername} 140 Aug 3 21:29 .inputrc
drwxrwxr-x 10 {benutzername} fuse 4096 Dez 9 2018 ISO
drwxr-xr-x 3 {benutzername} {benutzername} 4096 Aug 18 18:16 .local
drwx------ 6 {benutzername} {benutzername} 4096 Aug 18 18:38 .mozilla
drwxr-xr-x 14 {benutzername} fuse 4096 Aug 7 21:43 Musik
drwxr-xr-x 2 {benutzername} fuse 4096 Dez 9 2018 Öffentlich
drwxr-xr-x 2 {benutzername} fuse 4096 Aug 15 19:05 Schreibtisch
drwxr-xr-x 14 {benutzername} fuse 4096 Aug 4 07:27 Videos
-rw------- 1 {benutzername} {benutzername} 106 Aug 18 20:02 .Xauthority
-rw-rw-r-- 1 {benutzername} fuse 370 Jan 11 2019 X.ini
-rw------- 1 {benutzername} {benutzername} 180404 Aug 18 20:03 .xsession-errors
Fazit von knapp 2 Wochen Installations-Tests:
Das Thema “Siduction” ist für mich erstmal durch. Im nächsten Versuch werde ich mal versuchen, wie sich denn ein “reinrassiges” Debian verhält: einmal das rolling release Debian Testing, und dann auch die Basis von Siduction, das originäre Debian Sid.
weitere Artikel
- Was man bei der Installation von Siduction Linux NICHT tun sollte - Teil 2
- 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