Nachdem ich meine Siduction Installation nach meinen Vorstellungen angepasst habe, würde ich gerne daraus eine Live ISO erstellen. Damit könnte ich dann noch einem anderem alten Rechner aufsetzen, den ich nicht mehr großartig anpassen müsste. Zudem würde ich gerne damit ein Windows Laptop booten und mit der Live ISO einzelne Partitionen des Laptops sichern.
Im Internet habe ich bereits etwas recherchiert und Distroshare-Ubuntu-Imager als eine Lösung zum erstellen von Live Images gefunden und Systembackup. Ich bin mir aber nicht sicher ob sie auch für die Siduction Distro geeignet sind.
Bevor ich mich also intensiver mit dem Thema beschäftige, würde ich gerne Eure Meinung wissen ob diese beiden Lösungen geeignet wären, oder ob es noch eine bessere Lösung für Siduction Distros gibt?
Danke im voraus schon einmal für Euer Interesse an meinen Fragen :-)
Da sich niemand sonst äußern mag, hier "meine" Variante:
Ich baue kein Live-Image aus einer installierten Variante, sondern baue es so, wie die Siduction-"Maintainer" selbst - halt mit meinen Änderungen. Das ist nicht wirklich schwierig.
Man verwende dazu das Siduction Git Repository https://github.com/siduction/ (https://github.com/siduction/) und dort speziell den Zweig "pyfll" und darin wiederum "pyfll" Im README ist sehr gut erklärt, wie man "(s)ein" ISO bauen kann. Jetzt muß man nur seine "Sonderwünsche" einbauen.
Persönlich nutze ich Debian live helper. Ich baue mindestens alle drei Wochen ca 15 angepasste DVDs.
Vielen Danke euch beiden. Ich werde mir beides ansehen und ausprobieren. Ich werde dann bei Zeiten berichten, wie ich mit euren Vorschlägen zurecht gekommen bin. Im Internet hatte ich auch noch ein Tool Namens Systembak gefunden. Das wollte ich auch einmal ausprobieren. Ich bin schon gespannt wie weit ich komme :-)
Ich habe mir Eure Vorschläge einmal angesehen.
@ro_sid ehrlich gesagt steige ich nicht ganz durch, wie ich bei pyfll vorgehen muss. Es liest sich so, als handelt es sich um ein Scriptfile. Damit kenne ich mich nicht aus. Bei Repositories handelt es sich doch um eine Zusammenstellung von verschiedenen Programmen aus denen man sich einige aussucht, oder? Aber wie binde ich das Reprository in das System ein? Das wäre dann auch meine Frage. Muss ich einfach nur eine Datei von der Github Seite herunter laden, die ich dann unter meinem Distrosystem ausführe, oder muss ich ein Paket runterladen wie ein DEB Paket das installiert werden muss?
@T-ampfer Es sieht so aus, das man sich mit dem Debian live helper eine komplett neue Distro zusammenstellt. Da verstehe ich nicht wo da der Bezug zu Siduction ist? Ist das dann eine ganz eigene Distrobution auf Debian Basis.? Dann wüsste ich natürlich nicht was es alles an grundsätzlicher Tools bedart, damit eine grafische Oberfläche erscheint und ein Dateimanager mit dem man Partitionen mounten oder unmounten kann. Außerdem wüsste ich auch nicht, welche Abhängigkeiten für ein Image Tool wie qt-fsarchiver alle vorher mit aufgenommen werden müssen, damit das Tool dann nachher auch funktioniert.
Bei dem Tool Systemback hatte ich leider keinen Erfolg und bei dem Versuch, die vorher angelegte Partitions Sicherung mit foxclone wieder zurück zu sichern, hat leider nicht richtig funktioniert.
Das zurücksichern an sich hat schon geklappt, aber grub hat dann beim erneuten booten einen Fehler gemeldet das es kein System gefunden hat. Ich habe dann letztendlich Siduction noch einmal neu installiert, damit der Fehler behoben wurde.
Mir ist natürlich mittlerweile klar, das es auch Befehle gibt die Grub Loader upzudaten und zu reparieren, Wo aber bei meinem 15 Jahre alten Laptop mit 4 verschiedenen Systemen befindet sich eigentliche der Grub Loader?
Ich habe wie geschrieben einen alten Laptop zum ausprobieren von Linux genommen, der noch mit einem MBR Bios arbeitet und die Möglichkeit das modernere GBT zu nutzen, indem man auf einer 8 MB großen Partition am Anfang der Festplatte eine Tabelle für das alte MBR Bios erstellt, habe ich bis jetzt noch nicht genutzt, da ich ja sonst mein System auf der ersten Partition verlieren würde.
Also frage ich mich jetzt für neuere Sicherungen, wie ich solche Fehler beim erneuten Sichern vermeiden kann und ohne Gefahr eine vermurkste Installation einfach auf den vorherigen Zustand zurücksichern kann. Also welchen Grub Loader müsste ich sichern und wie? Den in dem MBR Reckord am Anfang der Festplatte, oder einen Grub Loader auf einen der bootbaren Partitionen mit den unterschiedlichen Distros?
Es wäre nicht schlecht wenn es eine Lösung gäbe, mit der ich eine Rescue ISO starten könnte wenn der Laptop keine System mehr starten kann, und die vorher erstellte Sicherung zurück schreibt und der Grub Loader auch wieder wie vor der Sicherung fuktionieren würde.
Ich hoffe das geht jetzt nicht zu weit und ich müsste dafür ein neues Thema erstellen.
LG und vielen Dank für Euer Interesse an meinen Problemen
Quote@ro_sid ehrlich gesagt steige ich nicht ganz durch, wie ich bei pyfll vorgehen muss. Es liest sich so, als handelt es sich um ein Scriptfile. Damit kenne ich mich nicht aus. Bei Repositories handelt es sich doch um eine Zusammenstellung von verschiedenen Programmen aus denen man sich einige aussucht, oder? Aber wie binde ich das Reprository in das System ein? Das wäre dann auch meine Frage. Muss ich einfach nur eine Datei von der Github Seite herunter laden, die ich dann unter meinem Distrosystem ausführe, oder muss ich ein Paket runterladen wie ein DEB Paket das installiert werden muss?
Bei pyfll (in pyfll/) handelt es sich tatsächlich um ein einzelnes Skript, welches die komplette Arbeit übernimmt, jedoch "seine Arbeitsumgebung" dafür braucht, die man anpassen kann. Dort werden unter anderem auch die Repositorys und die Pakete aufgeführt, die man jedoch seinem Bedarf anpassen kann.
Zum Ausführen sollte/muß man das gesamt Verzeichnis "pyfll" lokal zur Verfügung haben. Das kann man gut mit dem Kommandozeilenprogramm "git" machen. Falls man das nicht kann oder will, gibt es im Web-Browser "in pyfll" aber auch rechts oben den "Knopf" "<> Code". Wenn man da drauf klickt, ist eine Wahl "Download [als] ZIP". Diese Datei herunterladen, auspacken und so verfahren, wie es im Web-Browser angezeigt wird, wenn man auf das Verzeichnis (links) "pyfll" klickt und dann nach unten scrollt.
[Das ist die README.md-Datei dort. Eine Markdown-Datei die auch in dem ZIP-Baum enthalten ist.]
Zunächst zur Übung einfach mal eine ISO Datei erstellen, so wie im README.md beschrieben. Dann erkunden, wie man die Auswahl anpassen kann.
Leider funktioniert das augenblicklich
nicht, was aber daran liegt, daß so kurz nach dem "stable" werden von Trixie, der "unstable" Zweig noch nicht wieder vernünftig "funktioniert" - die Abhängigkeiten sind nicht erfüllt/ausbalanciert! Das sollte sich jedoch schnell wieder ändern.
QuoteIch habe wie geschrieben einen alten Laptop zum ausprobieren von Linux genommen, der noch mit einem MBR Bios arbeitet und die Möglichkeit das modernere GBT zu nutzen, indem man auf einer 8 MB großen Partition am Anfang der Festplatte eine Tabelle für das alte MBR Bios erstellt, habe ich bis jetzt noch nicht genutzt, da ich ja sonst mein System auf der ersten Partition verlieren würde.
Grub arbeitet sowohl mit dem MBR-, als auch dem GPT-Format. [Für UEFI und BIOS sind das allerdings zwei verschiedene "Pakete".] Wichtig ist, daß die Konfigurationsdatei (grub.cfg) gefunden wird.
QuoteEs wäre nicht schlecht wenn es eine Lösung gäbe, mit der ich eine Rescue ISO starten könnte wenn der Laptop keine System mehr starten kann, und die vorher erstellte Sicherung zurück schreibt und der Grub Loader auch wieder wie vor der Sicherung fuktionieren würde.
Für solche Zwecke eignet sich etwa das Programm REAR (relax and recover), das (auch) als Debian-Paket (.deb) im Repository verfügbar ist und "beliebige" (Linux-)Rechner durch Sichern auf ein (externes) Speichermedium wieder lauffähig machen kann. Es sichert allerdings nicht den kompletten Rechner, sondern nur "was es braucht" - das kann auch der ganze Rechner sein ;).
Edit: Klarstellung, daß die verschiedenen GRUB-Pakete von UEFI und BIOS abhängen, nicht direkt von MBR oder GPT.
Super ausführliche Antwort ro_sin. Recht herzlichen Dank.
Ich habe nicht alles verstanden, aber ich werde mich versuchen reinzufuchsen und sicherlich vieles im nachhinein verstehen.
Auf jeden Fall wieder viel Input an dem ich mir Zähne ausbeißen kann :-).
Die Grub.cfg finde ich ja eigentlich bei jeder der 4 Partitionen mit einer eigenen Distro. Dort im /boot/grub Verzeichnis. In dem MBR kann ich natürlich nicht nachschauen. Entscheidet man das dann selbst von welcher grub.cfg der Computer nachschauen soll wenn er startet?
QuoteDie Grub.cfg finde ich ja eigentlich bei jeder der 4 Partitionen mit einer eigenen Distro. Dort im /boot/grub Verzeichnis. In dem MBR kann ich natürlich nicht nachschauen. Entscheidet man das dann selbst von welcher grub.cfg der Computer nachschauen soll wenn er startet?
Jein :), gerade beim BIOS/MBR-Grub liegt die Information (leider) binär hinter dem MBR-Bereich. Im UEFI-Fall ist das leichter in der zugehörigen FAT-Partition zu finden.
Allerdings ist GRUB ein Superprogramm - falls man bereit ist sich mit dem eingebauten Kommandozeilenprogramm auseinanderzusetzen. Es lohnt sich.
So kann man, egal von wo man GRUB gestartet hat, mit Drücken auf "c" sobald das Boot-Menü erscheint in diesen Modus kommen. Mit "ls" kann man sehen, welche Datenspeicher wie angesteuert werden und so mittels "configfile"-Kommando tatsächlich das Boot-Menü einer beliebigen .cfg-Datei auslösen.
Erstellen einer Siduction-Live-ISO:
QuoteLeider funktioniert das augenblicklich nicht, was aber daran liegt, daß so kurz nach dem "stable" werden von Trixie, der "unstable" Zweig noch nicht wieder vernünftig "funktioniert" - die Abhängigkeiten sind nicht erfüllt/ausbalanciert! Das sollte sich jedoch schnell wieder ändern.
Es geht nun wieder :)!
Wunderbar. Danke für die Info.
Ich bin dieses Wochenende unterwegs und werden leider nicht dazu kommen es auszuprobieren, aber nächste Woche werde ich es auf jeden Fall versuchen.
In der Zwischenzeit habe ich versucht mit dem Tool penguin-eggs aus dem bestehendem System eine Iso zu erstellen. Das wollte erst nicht, da es die Distro nicht kannte, aber mit Hilfe des Entwicklers habe ich es in einer Configurationsdatei eintragen können. Der Prozess des Erstellens hat zwar geklappt, aber ich habe zur Zeit nur einer 34 kbit große Iso mit zusätzlichen 3 Verzeichnissen.
Ich habe den Entwickler noch einmal kontaktiert und um Hilfe gebeten. Mal schauen ob ich daraus eine startbare Iso hinbekomme. Ich werde dann berichten wie es weiter ging.
@ro_sid Da es mit einem Update von eggs penguin auch nicht geklappt hat, eine iso Datei zu erstellen, habe ich versucht pyfll ein neue ISO zu erstellen.
Leider habe ich auch hier Probleme und mache wieder irgendetwas flasch.
Ich habe das ganze Paket runter geladen und entpackt und nach Anleitung die fll.conf in das höhere Verzeichnis kopiert und editiert. Da ich erst einmal grundsätzlich Testen wollte habe ich nur die Sprache auf nur Deutsch geändert und alles andere belassen. Bei dem Versuch das Script mit dem angebenen Befehl auszuführen habe ich allerdings gleich eine Fehlermeldung bekommen mit der ich nichts anfangen kann:
siduman@siduman-t4310:/media/siduman/Austausch/Downloads/Pyfll/pyfll-master/pyfll$ sudo ./fll -c ../fll.conf -b /tmp/fll/ o- /tmp/fll/
[sudo] Passwort für siduman:
Requires root!
Traceback (most recent call last):
File "/media/siduman/Austausch/Downloads/Pyfll/pyfll-master/pyfll/pyfll", line 8, in <module>
from configobj import ConfigObj
ModuleNotFoundError: No module named 'configobj'
In der fll.conf finde ich in Zeile 8 kein configobj und auch an keiner anderen Stelle in der Datei. Auch der Versuch das ganze als Root auszuführen brachte das gleiche Ergebnis.
apt install python3-configobj
Danke für die Info @towo. Das hat schon mal geklappt. Die Fehlermeldung mit fehlendem configobj kommt nicht mehr. Leider kommen jetzt aber noch andere Fehlermeldungen die wohl auf fehlende Konfigurationen hinweisen. Gibt es eigentlich eine einfache Anleitung wie genau die fll.config aufgebaut sein muss?
Mit der der Anleitung aus der readme.md Datei bin ich leider überfordert,
Hier die neue Ausgabe nach der Installation von phyton3-configobj:
2025-09-04 00:50:16,218 INFO - reading configuration file...
Traceback (most recent call last):
File "/media/siduman/Austausch/Downloads/Pyfll/pyfll-master/pyfll/pyfll", line 2561, in <module>
fll.main()
File "/media/siduman/Austausch/Downloads/Pyfll/pyfll-master/pyfll/pyfll", line 2449, in main
self.parseConf()
File "/media/siduman/Austausch/Downloads/Pyfll/pyfll-master/pyfll/pyfll", line 576, in parseConf
self.conf = ConfigObj(self.opts.c)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/configobj/__init__.py", line 1224, in __init__
self._load(infile, configspec)
File "/usr/lib/python3/dist-packages/configobj/__init__.py", line 1313, in _load
raise error
configobj.ParseError: Invalid line ('\tde_DE') (matched as neither section nor keyword) at line 32.
siduman@siduman-t4310:/media/siduman/Austausch/Downloads/Pyfll/pyfll-master/pyfll$
Danke noch einmal an alle für die Unterstützung bis hier hin
Sind denn jetzt alle Pakete die im README als "Dependencies" stehen installiert (apt install ...)?
Denn python3-configobj gehört ja auch dazu und war es offensichtlich nicht:
Zur Erinnerung:
Dependencies:
-------------
python3
python3-apt
python3-configobj
cdebootstrap | debootstrap
xorriso
squashfs-tools
reprepro (for liveapt functionality and extras (uefi))
Recommends:
gdisk (for gpthybrid used with grub, not needed if using isolinux)
Suggests:
isolinux (and the following syslinux* if you want to use isolinux)
syslinux
syslinux-utils
@ro_sid Das müsste ich dann noch einmal kontrollieren. Ich hatte mich an deinen Vorschlag gehalten und unter den Code Knopf das Pyfll Zip Packet runtergeladen und entpackt und dachte, damit alle nötigen Pakete zu haben. Da habe ich dann wohl etwas falschen verstanden.
Da muss ich dann wohl noch etwas nachsitzten :-)). Entschuldigung
So ich habe jetzt alle Abhängigkeiten installiert oder upgedatet und habe das fll.config zur Probe nur kopiert und nicht verändert und dann folgenden
Befehl nach Anleitung aus der readme.md als Root ausgeführt. Leider wieder ohne Erfolg, aber wahrscheinlich muss ich an irgendeiner Stelle in der fll.config nur
ein oder zwei # Zeichen entfernen. Nur welche weis ich leider nicht.
root@siduman-t4310:/media/siduman/Austausch/Downloads/Pyfll/pyfll-master/pyfll# ./fll -c ../fll.conf -b /tmp/fll/ -o /tmp/fll/
Requires root!
2025-09-07 04:04:44,811 INFO - reading configuration file...
Traceback (most recent call last):
File "/media/siduman/Austausch/Downloads/Pyfll/pyfll-master/pyfll/pyfll", line 2561, in <module>
fll.main()
~~~~~~~~^^
File "/media/siduman/Austausch/Downloads/Pyfll/pyfll-master/pyfll/pyfll", line 2449, in main
self.parseConf()
~~~~~~~~~~~~~~^^
File "/media/siduman/Austausch/Downloads/Pyfll/pyfll-master/pyfll/pyfll", line 577, in parseConf
self._processConf()
~~~~~~~~~~~~~~~~~^^
File "/media/siduman/Austausch/Downloads/Pyfll/pyfll-master/pyfll/pyfll", line 425, in _processConf
self.conf['archs'] = {arch: dict()}
~~~~~~~~~^^^^^^^^^
File "/usr/lib/python3/dist-packages/configobj/__init__.py", line 602, in __setitem__
Section(
~~~~~~~^
self,
^^^^^
...<2 lines>...
indict=value,
^^^^^^^^^^^^^
name=key))
^^^^^^^^^
File "/usr/lib/python3/dist-packages/configobj/__init__.py", line 504, in __init__
self[entry] = value
~~~~^^^^^^^
File "/usr/lib/python3/dist-packages/configobj/__init__.py", line 579, in __setitem__
raise ValueError('The key "%s" is not a string.' % key)
ValueError: The key "b'amd64'" is not a string.
Quote from: stefsion on 2025/09/07, 04:26:13
So ich habe jetzt alle Abhängigkeiten installiert oder upgedatet und habe das fll.config zur Probe nur kopiert und nicht verändert und dann folgenden Befehl nach Anleitung aus der readme.md als Root ausgeführt. Leider wieder ohne Erfolg, aber wahrscheinlich muss ich an irgendeiner Stelle in der fll.config nur ein oder zwei # Zeichen entfernen. Nur welche weis ich leider nicht.
root@siduman-t4310:/media/siduman/Austausch/Downloads/Pyfll/pyfll-master/pyfll# ./fll -c ../fll.conf -b /tmp/fll/ -o /tmp/fll/
Requires root!
2025-09-07 04:04:44,811 INFO - reading configuration file...
Traceback (most recent call last):
File "/media/siduman/Austausch/Downloads/Pyfll/pyfll-master/pyfll/pyfll", line 2561, in <module>
fll.main()
~~~~~~~~^^
[...]
Eventuell nur ein Schreibfehler?
/fll -c
../fll.conf -b /tmp/fll/ -o /tmp/fll/
fll.conf, nicht fll.config. Ich weiß nicht, ob es reicht beim "-c" den "gewollten Dateinamen" anzugeben oder ob er einfach .conf heißen muß.
Sorry ein Schreibfehler von mir hier im Board. Da ich die Datei einfach kopiert habe um das Script zu testen, heißt sie in Wirklichkeit im übergeordneten Verzeichnis fll.conf. Ich habe sie auch so in der Befehlszeile aufgerufen.
Muss ich denn irgendetwas in der fll.conf anpassen um das Script testen zu können? Mein Laptop hat einen Intel 64 bit Prozessor.
Danke aber für den Hinweis meines Fehlers in der Beschreibung ro_sid.
Also ich empfehle die Datei "shine-on.conf" (derzeitiges Siduction!) im Unterverzeichnis "templates" von "pyfll" als Konfigurationsdatei anstelle von fll.conf in "pyfll" zu nehmen. In letzterer ist ja fast nichts ausgewählt. [fll.conf habe ich - glaube ich - auch nie ausprobiert.]
(Die "Shine-On"-Datei kann man (dann) natürlich noch an eigene Bedürfnisse anpassen.)
Folgendes ausgeführt, um die Abhängigkeiten aufzulösen?
apt install python3 python3-apt python3-configobj debootstrap xorriso squashfs-tools reprepro gdisk isolinux syslinux syslinux-utils
Ich habe seit Langem (es ist Ewigkeiten her) kein ISO mehr gebaut, lokal und dann noch auf meinem Laptop, und interessehalber mal einen Build angestoßen.
Zu Testzwecken habe ich ,,nox" als kleinstes ISO gewählt, unverändert!
Vorher habe ich eine ISO-Bau-Datei Ordner angelegt und pyfll dahin kopiert, davor pyfll mit 'git pull' aktualisiert.
Mit folgendem Befehl habe ich den Buildprozess angestoßen:
./ffl -c conf/nox_shine-on_amd64.conf -b /tmp/fll/ -o /tmp/fll/
Das hat dann auch funktioniert.
Edit: Denk daran, es braucht eine Menge Platz zum Bauen, /tmp bzw. der Ort, an dem gebaut wird (-o /foo/fll und -b /bar/fll) sollte groß genug sein!
Danke für die Hilfe ro_sid und hendrikL. Ich habe leider das Gefühl ich verstehe immer weniger.
Ich habe jetzt die shine-on.conf genommen und versucht unverändert das Ganze auszuführen:
oot@siduman-t4310:/media/siduman/Austausch/Downloads/Pyfll/pyfll-master/pyfll# ./fll -c ../shine-on.conf -b /tmp/fll/ -o /tmp/fll/
Da gab es wieder eine Fehlermeldung dass das @flavour@ Profil nicht vorhanden ist.
2025-09-08 17:03:38,062 INFO - reading configuration file...
2025-09-08 17:03:38,064 INFO - No key for signing ISO hashes!
2025-09-08 17:03:38,066 INFO - processing package profile (@FLAVOUR@)...
2025-09-08 17:03:38,066 CRITICAL - no such package profile file: /media/siduman/Austausch/Downloads/Pyfll/pyfll-master/pyfll/packages/@FLAVOUR@
Und ja es ist im Packages Ordner auch keine Datei Namens flavour vorhanden. Eine Datei Namens nox schon. Deine Befehlszeitle
./ffl -c conf/nox_shine-on_amd64.conf -b /tmp/fll/ -o /tmp/fll/
verstehe ich aber leider nicht. kombiniert man verschiedene Provfile in dem man sie mit einem Unterstrich vereinigt? Oder hast du eine neue Datei mit den Profillen von nox, shine-on und amd64 erstellt und hast sie dann so benannt?
Und wieviel heist denn viel? Also wieviel hast du für deinen Versuch mit nox gebraucht? Ich will eigentlich auch nur eine kleine GUI Distro mit einem zusätzlichen Archivierungsprogramm erstellen.
Quote
verstehe ich aber leider nicht. kombiniert man verschiedene Provfile in dem man sie mit einem Unterstrich vereinigt? Oder hast du eine neue Datei mit den Profillen von nox, shine-on und amd64 erstellt und hast sie dann so benannt?
Ich habe weder verschiedene Profile zusammengeführt noch eine neue Datei erstellt!
Ich habe eine vorhandene Datei genommen.
:~/github/iso-bau/pyfll/pyfll/conf$ ls -1
archive
kde_shine-on_amd64.conf
lxqt_shine-on_amd64.conf
netinstall_next_amd64.conf
nox_shine-on_amd64.conf
used-gpgkeys
xfce_shine-on_amd64.conf
xorg_giants_i386.conf
xorg_shine-on_amd64.conf
In diesem Falle von "nox", wie oben zu sehen, sind da auch zwei Unterstriche dabei.
Man muss schon den korrekten Dateinamen nehmen und keinen Fantasienamen.
Diese Konfigurationsdateien sollte man auch nur ändern, wenn man weiß was man tut!
Die Änderungen werden unter packages.d gemacht.
Dort können Pakete hinzugefügt bzw. auskommentiert werden.
Für den Anfang würde ich aber erst einmal zum Testen und Üben eine vorhandene Konfiguration nehmen. xorg zB. klein und schnell, wobei klein reltiv ist.
Wenn du ein ISO bauen kannst, ohne etwas zu ändern, dann kann man weitersehen.
./fll -c conf/xorg_shine-on_amd64.conf -b /tmp/fll/ -o /tmp/fll/
Nimm genau diesen Befehl!
EDIT fixed typo s/ffl/fll/g
Ich habe mit penguin-eggs erfolgreich meine persönliche ISO-Datei erstellt!
Beim zweiten Mal muss man einige Wartungsbefehle zuvor ausführen:
eggs kill
eggs tools clean
eggs dad -d
Dann kann man erneut loslegen mit z.B. eggs produce --standard
Falls das nicht erfolgreich durchläuft, kann es (z.B. bei mir) daran liegen, dass man zuerst das vorherige Produktionsverzeichnis löschen muss:
for m in $(mount | awk '{print $3}' | grep "^/home/eggs"); do sudo umount -lf $m; done && \
rm -rf /home/eggs
Für mich hat es so gut funktoniert. Ich habe eine 6,9 GB große ISO-Datei erhalten!
Danke für den Hinweis handrikL. Wer lesen kann ist klar im Vorteil :) . Das Verzeichnis conf war für mich nicht relevant gewesen. Ich dachte die conf Dateien liegen alle im Packages Verzeichnis. Zuerst wollte es nicht funktionieren, bis mir auffiel, das in deiner Befehlszeitle ein Buchstabendreher drin ist. ./ffl steht dar und nicht ./fll (ist mir auch schon häufig passiert). Danach läuft der Prozess durch, bis er wegen zu wenig Speicher abbricht.
Need to get 1943 MB of archives.
After this operation, 7037 MB of additional disk space will be used.
E: You don't have enough free space in /var/cache/apt/archives/.
2025-09-09 04:01:34,115 CRITICAL - command failed with return value: 100
2025-09-09 04:01:34,121 INFO - cleaning up...
In der Partition habe ich nur noch 4GB frei.
Ich dachte er macht alles im /tmp Verzeichnis. Das wäre für mich meine Austausch Partition auf der ich ca 35 GB frei habe.
Ist /tmp die oberste Ebene der Partition auf der ich pyfll Verzeichnis habe, oder ist das die Partition auf der die Distro installiert ist?
Kann ich dem Script per Schalter sagen das er alles auf der Partition ausführen soll wo mein pyfll Verzeichnis ist und von der ich das Script starte?
@samtfalterbau
mit der neusten eggs-penguin Version habe ich es auch hinbekommen eine ISO von meiner momentanen Distro zu erstellen. Also mit dem Befehl
sudo eggs produce --clone
Aber ich glaube man erstellt aus der Vorhandenen Distro eine neue ISO. 6,4 GB fände ich schon sehr groß. Ich würde gerne nicht größer als ca. 2GB werden.
Da soll wirklich nur das nötigste reinkommen, wie ein einfacher Desktop, ein Terminal, ein Dateiexplorere, Gpartet, ein einfacher Editor und das Image Programm zum Sichern verschiedener Rechner.
Geht das auch mit eggs-penguin?
Aber wo die nette User sich so viel Mühe geben mir zu helfen, will ich das mit pyfll auch zu Ende bringen. Dann kann ich ja vergleichen und entscheiden, was für mich die praktikablere Vorgehensweise ist.
Wieder einmal recht herzlichen Dank bis hierhin für die Unterstützung an alle Beteiligten.
Quote
E: You don't have enough free space in /var/cache/apt/archives/.
Dieses hat nichts mit /tmp zu tun.
/var liegt in /.
In diesem Falle ist für den Download von apt nicht genug Platz.
Hast Du schon einmal ein 'apt clean' durchgeführt, um den Cache zu löschen?
Zeig uns mal die Ausgabe von
df -hUnd um Deine Frage zu beantworten: Mit '-o' und '-b' gibst Du an, wo gebaut wird und wo das Ergebnis am Ende liegt.
EDIT
Ich habe ganz vergessen zu schreiben, dass die ISOs, die im Moment gebaut werden, den ein oder anderen Fehler enthalten können und nach der Installation nachgearbeitet werden muss.
Das Ganze ist zurzeit ein ,,Work in Progress".
Es hat Gründe, warum wir zurzeit kein neues ISO auf die Menschheit loslassen, abgesehen vom Warten auf Plasma 6.5.
Also entweder man holt sich unter testbuilds.siduction.org ein relativ aktuelles ISO seiner Wahl und installiert es, passt es an und clont mit 'eggs' das Ergebnis, oder man nimmt die kleinen Fehler in Kauf und muss dann halt nacharbeiten.
Danke für die Info hendrikL. Das mit -o und -b hatte ich mir schon gedacht. Mit den Pfadbezeichnungen komme ich immer noch durcheinander. Das ist macht der Gewohnheit von Windows, wo eine Partition immer einen Buchstaben hat und die oberste Pfadebende sich immer nach der jeweiligen Partition richtet auf der man sich befindet. In Linux ist das ja nicht so und eine Partition kann ja an beliebiger Stelle mit einer beliebigen Bezeichnung eingehängt werden, wenn ich das richtig verstehe.
Ich hatte mir eine extra Partition eingerichtet, wo ich Dateien von verschiedenen Distros oder auch Windows austauschen möchte. Die befindet sich auf sda6 in der erweiterten Partition und hat die Bezeichnung "Austausch". Dort habe ich ein Verzeichnis tmp angelegt für pyfll. Wie würde ich also dieses Verzeichnis für -o und -b eintragen? Höchstwahrscheinlich nicht mit /tmp auch wenn ich mich im pyfll Verzeichnis auf sda6 befinde, oder?
Hier die gewünschte Ausgabe von dem df -h Befehl.:
[sudo] Passwort für siduman:
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
Mh, also ich sehe keine Ausgabe von /dev/sda6 /Austausch in der Ausgabe von 'df -h'.
Ist /dev/sda6 überhaupt eingehängt, oder hängst Du /dev/sda6 händisch ein?
mkdir /Austausch/tmp/fll wenn nicht schon geschehen, dann:
'-o /Austausch/tmp/fll -b /Austausch/tmp/fll', wenn dies der komplette Pfad ist.
Gib mal die Ausgabe von
cat /etc/fstab und blkid | grep /dev/sda6
@stefison: Eine Korrektur zu meinem früheren Posting in dem ich mich bei der Konfiguration auf das Verzeichnis "templates" bezog. Das war falsch und @hendrikL hat recht damit, daß es "conf" sein muß.
@hendrikL:
QuoteIch habe ganz vergessen zu schreiben, dass die ISOs, die im Moment gebaut werden, den ein oder anderen Fehler enthalten können und nach der Installation nachgearbeitet werden muss.
Das Ganze ist zurzeit ein ,,Work in Progress".
Also für die KDE-Varianten habe ich keine solchen Probleme beobachtet, seitdem sich die ISOs überhaupt wieder "bauen" lassen. Die jüngste Version ist von vorgestern und zeigt keine Probleme.
@ro_sid
QuoteAlso für die KDE-Varianten habe ich keine solchen Probleme beobachtet, seitdem sich die ISOs überhaupt wieder "bauen" lassen. Die jüngste Version ist von vorgestern und zeigt keine Probleme.
Mh, beim Xorg-ISO sind noch die *.list Dateien zusätzlich zu den *.sources Dateien in /etc/apt/sources.list.d/ vorhanden.
Apt möchte da doch bitte ein modernize durchgeführt haben.
Weiterhin fehlen in den Dateien extra.sources und fixes.sources die Kommentarzeichen (#) vor den Ländernamen.
P.S.: Ein Fix ist schon in Arbeit.
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
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:
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 :
# <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 :
/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
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.
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!
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:
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:
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.
Zwei Fragen geistern durch meinen Kopf: Warum ein btrfs‑Filesystem und wie wird die Partition eingehängt (mit welchem Befehl)?
Quote/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?
ls -l /media/siduman/ | grep Austausch und
ls -l /media/siduman/Austausch | grep tmpQuoteumount: /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.
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 ;
drwx------ 1 siduman fuse 204 9. Sep 03:49 Austausch
Und hier ls -l /media/siduman/Austausch | greb tmp :
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.
Quote from: stefsion on 2025/09/11, 21:01:57
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.
QuoteDarf 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.
Quotedrwxrwxr-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.
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.
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:
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.
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. 8)
@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 :)