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 3

veröffentlicht am 19.08.2019 mit 926 Worten - Lesezeit: 5 Minute(n)

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 23 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:

Installer - gemeinsames Passwort für User und Admin

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:

Calamares Installer manuelle Zuordnung der Partitionen

und damit hat der Installer dann dieses zu erledigen:

Calamares Partitionierung Zusammenfassung

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:

Calamares: Partition ersetzen

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.