Womit erstelle ich aus der angepassten Distro eine Custom Live ISO

[ro_sid]

Aha,  ja den .sources-Effekt hatte ich tatsächlich ebenfalls, er tritt bei mir aber schon seit geraumer Zeit (drei Wochen?) nicht mehr auf.
Nur "apt" ist so aufdringlich mir dauernd noch eine "Anpassung" vorzuschlagen, ich werde aber nicht mehr zwangsbeglückt.

@hendrikL: Oh, verd... . Da habe ich mich vertan, das .sources-Problem existiert noch. Ich habe es nur deshalb nicht (mehr), weil ich diese immer lösche. Die .list tun es vollkommen.

Edit: Richtigstellung, daß das Problem derzeit doch noch existiert

[stefsion]

Ihr seid ja sehr schnell und wirklich hilfsbereit.  Ich habe zur Zeit leider viel auf der Arbeit zu tun und es dauert daher immer etwas länger bis ich auf Eure Vorschläge reagiere.

@hendrikL  die Austausch Partition ist häufig nicht eingehängt. Das mache ich dann manuell, wenn ich sie brauche. Hier die Ausgabe von df -h mit der eingehängten sda6:

Code Select Expand

siduman@siduman-t4310:~$ df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev            1,9G       0  1,9G    0% /dev
tmpfs           387M    4,6M  382M    2% /run
/dev/sda8        20G     15G  4,5G   76% /
tmpfs           1,9G    4,0K  1,9G    1% /dev/shm
tmpfs           5,0M    8,0K  5,0M    1% /run/lock
tmpfs           1,0M       0  1,0M    0% /run/credentials/systemd-journald.service
tmpfs           1,9G    8,0K  1,9G    1% /tmp
tmpfs           387M     88K  387M    1% /run/user/1000
/dev/sda6        49G    9,1G   40G   19% /media/siduman/Austausch


müsste ich dann in der Kommandozeile -o /media/siduman/Austausch/tmp/fll  eingeben, oder weis das System das Austausch die sda6 Partition ist und es würde -o /Austausch/tmp/fll reichen?


Hier die Ausgabe von cat /etc/fstab  :

Code Select Expand

# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=37181551-07aa-4796-9047-13c6fac3d36f /              ext4    defaults,noatime 0 1
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0


und hier die Ausbabe von blkid | grep /dev/sda6  :

Code Select Expand

/dev/sda6: LABEL="Austausch" UUID="704e81fe-5d44-471e-89cd-5c96cac123ea" UUID_SUB="78bbdaa5-ddde-4de0-aa8d-6ec8a8dbbcd7" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="addbdad4-06"


@ro_sid  das mit der Korrektur nehme ich zur Kenntnis, ob ich mir das merken kann bleibt abzuwarten :-)
Bei den vielen neuen Informationen und ein neues Betriebssystem überhaupt, bringe ich gerne mal etwas durcheinander und verliere auch des öfteren die Übersicht.
Welches von den vorhandenen Profilen im "conf" Ordner erzeugt eigentlich die kleinste Siduction Distro mit gui Desktop für 64bit Prozessoren?

LG stefsion

[hendrikL]

Bei -o als auch bei -b /media/........ den ganzen Pfad.

Vermutlich Xorg, um auf deine Frage zu antworten.
Die bekommt man auch noch geschrumpft.
Erst einmal ein ISO bauen, dann kommt der Rest.

[ro_sid]

64-bittig sind (in conf/) alle Konfigurationen mit _amd64 im Namen. Die offiziell unterstützten Desktops sind KDE, LXQt, Xfce und Xorg. Alle tragen diese Bezeichnung im Namen in der .conf-Datei. Die letztere ist die kleinste und geht "am schnellsten" zu bauen, weshalb die Empfehlung von @hendrikL mit dieser anzufangen sehr vernünftig ist.

Noch kleiner ist noX, aber sie enthält keinen graphischen Desktop, wie schon der Name nahelegt.

Viel Spaß und Erfolg!

[stefsion]

So ich habe versucht alles umzusetzen. Hoffe ich jedenfalls.
Meine Befehlzeile war wie folgt:
./fll -c conf/xorg_shine-on_amd64.conf  -b /media/siduman/Austausch/tmp/fll/ -o /media/siduman/Austausch/tmp/fll/
 
Dann kam am Anfang eine Meldung das er die Datei test-dev-null nicht anlegen kann:

Code Select Expand

2025-09-11 01:32:39,684 INFO  - reading configuration file...
2025-09-11 01:32:39,686 INFO  - No key for signing ISO hashes!
2025-09-11 01:32:39,687 INFO  - processing package profile (xorg)...
2025-09-11 01:32:39,708 INFO  - last depfile /media/siduman/Austausch/tmp/pyfll/packages/packages.d/env-xorg
2025-09-11 01:32:39,719 INFO  - bootstrapping debian sid amd64...
/usr/sbin/debootstrap: 1858: cannot create /media/siduman/Austausch/tmp/fll/fll_zm4_e4_a/amd64/test-dev-null: Permission denied


Danach hat er aber einiges gemacht und endete mit einem Fehler:

Code Select Expand

I: Base system installed successfully.
Adding 'local diversion of /usr/sbin/policy-rc.d to /usr/sbin/policy-rc.d.REAL'
umount: /media/siduman/Austausch/tmp/fll/fll_zm4_e4_a/amd64/proc: target is busy.
2025-09-11 01:34:42,186 CRITICAL - umount failed for: /media/siduman/Austausch/tmp/fll/fll_zm4_e4_a/amd64/proc
2025-09-11 01:34:42,197 INFO  - cleaning up...
umount: /media/siduman/Austausch/tmp/fll/fll_zm4_e4_a/amd64/proc: target is busy.
2025-09-11 01:34:42,213 CRITICAL - umount failed for: /media/siduman/Austausch/tmp/fll/fll_zm4_e4_a/amd64/proc
Exception ignored in atexit callback <bound method FLLBuilder.cleanup of <__main__.FLLBuilder object at 0x7f18b174a660>>:
Traceback (most recent call last):
  File "/media/siduman/Austausch/tmp/pyfll/pyfll", line 867, in cleanup
    self._umount(dir)
  File "/media/siduman/Austausch/tmp/pyfll/pyfll", line 833, in _umount
    raise FllError
FllError:


Im /fll Ordner gibt es jetzt einen Unterordner fll_zm4_e4_a/
Dort befindet sich ein Ordner amd64 mit vielen Dateien und Ordnern die nach einer normalen Root Partition aussehen. Der Ordner hat aber nur eine Größe von 322 Mib, was wahrscheinlich zu wenig ist.

[hendrikL]

Zwei Fragen geistern durch meinen Kopf: Warum ein btrfs‑Filesystem und wie wird die Partition eingehängt (mit welchem Befehl)?

/usr/sbin/debootstrap: 1858: cannot create /media/siduman/Austausch/tmp/fll/fll_zm4_e4_a/amd64/test-dev-null: Permission denied

Brutalstmöglich abgesichert, das Ganze?

Code Select Expand

ls -l /media/siduman/ | grep Austausch und

Code Select Expand

ls -l /media/siduman/Austausch | grep tmp

umount: /media/siduman/Austausch/tmp/fll/fll_zm4_e4_a/amd64/proc: target is busy.

Deutet darauf hin, dass ein Prozess auf die Daten zugreift, z.B. ein geöffneter Dateimanager.
Ich habe beim ISO-Bau solch eine Meldung bis jetzt nicht gesehen.

[stefsion]

Oh je habe ich wieder wohl etwas falsch gemacht?
Ich habe irgendwo beim einarbeiten in Linux oder in einem Youtube Video war es, das btrfs das modernere Filesystem sein soll und ext4 irgendwan ablösen wird. Da dachte ich, dann verwende ich das für meine persönliche Daten, die ich über verschiedene Distros hinweg austauschen kann und sicherlich nicht wechseln werde wie Partitionen mit Distros.
Wenn das ein Fehler ist würde ich das natürlich ändern, nachdem ich die Daten auf einem externen Medium gesichert habe. Momentan sind auch noch nicht viele Daten drauf. Das wäre also kein großer Akt.

Als Dateimanager nutze ich den Thunar Manager, der bei der Siduction Distro standardmäßig dabei war. Da wird meine SDA6 beim Starten der Distro ausgehängt angezeigt, und wenn ich sie aufrufe, fragt Thunar nach dem Administrator Passwort. Dann hängt Thunar sie ins System ein.
Über einen Rechtsklick im Dateimanager rufen ich dann das Terminal für das Verzeichnis, in dem ich mich gerade befinde, auf. Da ich den Dateimanager nicht schließe ist der im Hintergrund noch offen.

Darf das nicht sein? Muss ich alle Dateimanager Fenster schließen, wenn ich pyfll ausführe?

Hier das Ergebnis von ls -l  /media/siduman/ | greb Austausch  ;

Code Select Expand

drwx------ 1 siduman fuse 204  9. Sep 03:49 Austausch

Und hier ls -l /media/siduman/Austausch  | greb tmp   :

Code Select Expand

drwxrwxr-x 1 siduman siduman         16 11. Sep 01:11 tmp

Das tmp Verzeichnis habe ich mit dem Thunar Dateimanager erstellt.

Sorry noch einmal für die viele Mühe die ich mache.

[scholle1]

Oh je habe ich wieder wohl etwas falsch gemacht?
Ich habe irgendwo beim einarbeiten in Linux oder in einem Youtube Video war es, das btrfs das modernere Filesystem sein soll und ext4 irgendwan ablösen wird.

Die Lernkurve ist zuweilen recht steil. Und ja, ich hasse diese Superschlaules mit ihren ultimativen Tipps.
Btrfs ist meiner Meinung nach für die Installation von siduction ausgezeichnet geeignet. Es hat mir mit seinen Fähigkeiten in einigen, meist selbst verschuldeten, Situationen schon viel Arbeit erspart. Für ein Backupmedium ist es aber überdimensioniert. Bitte lese die Kapitel 7.4 Btrfs und 7.5 Snapper unseres Handbuches um einige grundlegende Informationen zu erhalten.

Darf das nicht sein? Muss ich alle Dateimanager Fenster schließen, wenn ich pyfll ausführe?

Du hast eine verschachtelte Einhängung. Erst dein externes Medium und darin das pyfll Arbeitsverzeichnis. Eventuell liegt darin die Ursache. Eine weitere Möglichkeit wäre der zeitliche Ablauf. Zum Beispiel wenn pyfll den umount Befehl absetzt bevor die Schreibvorgänge auf dem externen Medium abgeschlossen sind.
Aber beides sind von mir nur Spekulationen, eventuell mal testen. Natürlich ist es sinnvoll Programme vorher zu beenden, die Auswirkungen auf die von pyfll benutzten Pfade haben könnten.

[ro_sid]

Code Select Expand

drwxrwxr-x 1 siduman siduman         16 11. Sep 01:11 tmp

Da es auch Zugriffsprobleme gab, möchte ich darauf hinweisen, daß tmp-Verzeichnisse, insbesondere /tmp üblicherweise Rechte der Form drwxrwxrwt haben, also für alle(!) schreibbar, aber nur wer etwas dort angelegt hat, darf es löschen. Das muß hier kein Problem darstellen, könnte es aber.

Zum btrfs möchte ich noch sagen, daß ich wegen der "Schnappschüsse" oft nicht beurteilen kann, wieviel verwendbarer "freier" Platz wirklich noch zur Verfügung steht, aber das mag mein Problem sein.

[hendrikL]

Versuche mal, hänge das Verzeichnis wie gewohnt ein, schließe daraufhin den Dateimanager.
Öffne ein Terminal, und gib den vollen Pfad zum Starten von fll ein, wobei du in home bleibst.

Code Select Expand

sudo /media/siduman/Austausch/tmp/pyfll/fll -c  /media/siduman/Austausch/tmp/pyfll/conf/xorg_shine-on_amd64.conf  -b /media/siduman/Austausch/tmp/fll/ -o /media/siduman/Austausch/tmp/fll/

Wenn das der Pfad vom Homeverzeichnis zu pyfll ist.

Hier mal als Beispiel, wie ich den Bauprozess (build) anstoße:

Code Select Expand

root@hhl-2:/home/hhl/github/iso-bau/pyfll# ./fll -c conf/xorg_shine-on_amd64.conf -b /ablage/build -o /ablage/output


Wobei ich per su zu root wurde, sudo nutze ich weniger (reine Geschmackssache), und dann ins Verzeichnis iso-bau gewechselt bin, mit 'cd /foo/bar/usw/...'.
Wobei ~/github/iso-bau/pyfll auf /dev/sda5 liegt und /ablage auf /dev/sda2.

Auf meinem System werden die verschiedenen Partitionen via /etc/fdisk schon beim Systemboot eingehängt.

[stefsion]

Danke für die vielen Hinweise, die ich demnächst versuche umzusetzen und hoffe das Problem zu lösen. Ich bin jetzt für 2 Wochen im Ausland und kann leider nicht an meinen alten Laptop um weiter zu machen. Danach werde ich mich wieder melden wie ich weiter komme.

@scholle1 dann werde ich mir Kapitel 7.4 und 7.5 durchlesen um mein Wissen zu vertiefen. Meine Austausch Partition ist übrigens nicht auf einem externen Medium. Ich habe in dem Laptop eine einzige SSD Festplatte und SDA6 ist eine Partition im  Bereich der erweiterten Partition von dieser Festplatte. Aber vielleicht ist es trotzdem problematisch viele verschiedene Partitionen mit unterschiedlichen Formaten zu haben. Ich werde verschiedene Sachen einfach ausprobieren und hoffentlich herausfinden woran es liegt das es bei mir nicht klappt.

@ro_sid das mit den Zugriffsrechten unter Linux ist ein wirkliche mächtiges Tool, aber für Neueinsteiger auch recht verwirrend am Anfang. Vielleicht sollte ich versuchen ein anderes Verzeichnis zu erstellen mit einfachen Rechten um diese Fehlerquelle auszuschließen.

@hendrikL wirklich ausführliche Hilfestellung um mir den Einstieg zu erleichtern. Als erstes werde ich deine Befehlszeile ausprobieren, wenn ich wieder zurück bin. Das wäre natürlich die einfachste Lösung für mich, wenn es damit klappen würde.

Danke noch einmal an alle und bis in 2 Wochen. So lange habt ihr jetzt Ruhe vor mir