ISO-Bau liefert Fehler

[ro_sid]

Eine Beobachtung von der ich vermute, sie betrifft nicht nur mich:
Beim Versuch für mich eine KDE-ISO-Siduction-Variante zu bauen erlebe ich seit nicht ganz zwei Wochen, daß dies mit "dpkg"-Fehlern scheitert. Zunächst wollte ich das aussitzen, finde es aber inzwischen bedenklich.
Soweit ich das (beim Durchlaufen) verfolgen kann, beginnt der Fehler beim Setup von "x11-common". Das führt dann natürlich zu Folgefehlern, da das Paket recht grundlegend ist.

Kann das jemand freundlicherweise bestätigen und eventuell sogar beheben oder betrifft es lediglich mich?

[Teriarch]

> Beim Versuch für mich eine KDE-ISO-Siduction-Variante zu bauen...

Kannst Du zur Nachvollzihbarkeit in kurzen Worten den Weg beschreiben,
den Du zur Herstellung Deiner ISO Variante eingeschlagen hast?

Ich mache das auch regelmäßig und bin auf keine Probleme dieser Art gestoßen.

[ro_sid]

> Beim Versuch für mich eine KDE-ISO-Siduction-Variante zu bauen...

Kannst Du zur Nachvollzihbarkeit in kurzen Worten den Weg beschreiben,
den Du zur Herstellung Deiner ISO Variante eingeschlagen hast?

Ich mache das auch regelmäßig und bin auf keine Probleme dieser Art gestoßen.

Gerne. Ich verwende das "full-story" fll-script aus dem Siduction Git-Repository in pyfll/pyfll (./fll -c ../my_kde_shine-on_amd64.conf), wobei die Konfigurationsdatei weitgehend dem Original entspricht. Es wird lediglich ein apt-cache eingebunden und eine Datei in /etc/udisks2/ hinzugefügt.

[Teriarch]

Entschuldige, dass ich erst jetzt dazu komme, zu antworten. Ich konnte den Fehler noch immer nicht nach-
vollziehen, da mir beim Versuch, das ISO Image zu generieren der Speicher meiner virtuellen Machine zur Neige ging.

Mich verwundert ohnehin der imense Overhead, den dieses Python Skript erzeugt. Es werden ca. 2000 Pakete
heruntergeladen und ausgepackt, bevor mit der eigentlichen Installation begonnen wird (Ich versuche es aber
weiter).

Ich selbst benutze ein kleines shell Skript von ca. 45 Zeilen, um ein existierendes ISO Image auf den
neuesten Stand zu bringen. Das dauert in der Regel weniger als 5 Minuten. Neben den inkrementellen Updates
habe ich dabei außerdem die Möglichkeit, meine eigenen Wallpapers und Programme in die KDE siducer
Umgebung einzubringen und alles zu individualisieren.

Sag' bescheid, wenn der Fehler in der Zwischenzeit verschwunden ist.

[hsp]

Ist dein script geheim? Lass mal sehen ...

...

[ro_sid]

Entschuldige, dass ich erst jetzt dazu komme, zu antworten. Ich konnte den Fehler noch immer nicht nach-
vollziehen, da mir beim Versuch, das ISO Image zu generieren der Speicher meiner virtuellen Machine zur Neige ging.

Mich verwundert ohnehin der imense Overhead, den dieses Python Skript erzeugt. Es werden ca. 2000 Pakete
heruntergeladen und ausgepackt, bevor mit der eigentlichen Installation begonnen wird (Ich versuche es aber
weiter).

Ich selbst benutze ein kleines shell Skript von ca. 45 Zeilen, um ein existierendes ISO Image auf den
neuesten Stand zu bringen. Das dauert in der Regel weniger als 5 Minuten. Neben den inkrementellen Updates
habe ich dabei außerdem die Möglichkeit, meine eigenen Wallpapers und Programme in die KDE siducer
Umgebung einzubringen und alles zu individualisieren.

Sag' bescheid, wenn der Fehler in der Zwischenzeit verschwunden ist.

Zunächst: Kein Problem, passiert mir auch gelegentlich.
Dann: Nein, das Problem ist (bei mir) in der Zwischenzeit nicht verschwunden. Und wenn ich mir das leere Verzeichnis in "Testbuilds" ansehe vermute ich, unseren Gastgebern auch nicht .

Ja, der "Paketverbrauch" ist hoch, aber ich vermute dahinter die komplette "full-story" Installation. Und die Möglichkeiten sind ja auch beträchtlich angesichts des Umstands, alle (unterstützten) Varianten damit erstellen zu können - und die "freiwilligen" auch.

Zum "45 Zeilen" Skript: Ich vermute, das bringt die Live-Variante nach dem ISO-Laden auf den neuesten Stand, erzeugt aber keine neue (veränderte) ISO-Datei, richtig?
Mein Hauptgrund zum Selberbauen: Gewisse Pakete - etwa locales - benötigen recht lange für den Update-Durchlauf. Auch ist kein Kerneltausch/-update möglich. Daher baue ich immer wenn ich es angemessen finde eine neue ISO-Datei. Die bootet ziemlich schnell, wenn ich sie denn erzeugen kann .

[vinzv]

Ist dein script geheim? Lass mal sehen ...

...

Steht doch weiter oben:

Ich verwende das "full-story" fll-script aus dem Siduction Git-Repository in pyfll/pyfll (./fll -c ../my_kde_shine-on_amd64.conf), wobei die Konfigurationsdatei weitgehend dem Original entspricht. Es wird lediglich ein apt-cache eingebunden und eine Datei in /etc/udisks2/ hinzugefügt.

[towo]

Check das Script neu aus, ich habe das Problem behoben.

[Teriarch]

> Zum "45 Zeilen" Skript: Ich vermute, das bringt die Live-Variante nach dem
> ISO-Laden auf den neuesten Stand, erzeugt aber keine neue (veränderte) ISO-Datei, richtig?

Nein, das wäre trivial. Ausgehend von einem siduction_n.iso Image erzeugt es durch inkrementellen
Update ein siduction_{n+1}.iso Image. Während dieses Prozesses gestattet es in einer chroot
Umgebung, das im ISO Image enthaltene squashfs filesystem siduction.amd64 auf den neuesten
Stand zu bringen bzw. mit zusätzlichen eigenen Paketen zu verändern. Das geht i.d.R schnell, weil
nicht alle Pakete neu geholt werden müssen (nach 1-2 Wochen verändert sich nicht so viel). Danach
kannst Du (während des Skript Ablaufs) auch noch das Iso Image mit eigenen Programmen versehen
und so den Boot Prozess anpassen. Anschließend wird das so veränderte hybride ISO Image mit xorriso
in eine neue Datei geschrieben und die alte Version als Backup gesichert. Dieser Prozess ist unabhängig vom
verwendeten GUI (KDE, xfce, etc.). Das veränderte Image kann wie das alte von jedem Medium in legacy, UEFI
(und sogar mit weiteren Veränderungen im Secure Boot) Mode gestartet werden.

Ich kann das Skript zur Verfügung stellen, will es aber vorher noch ein wenig narrensicherer machen.
Viele (alle Anwesenden natürlich ausgeschlosen) starten solche Skripte nämlich ohne zu wissen, was
sie tun, und gefährden damit ihre eigene Installation. Und zu wissen, was man tut, ist der Preis, den man
für die 45 Zeilen zu zahlen hat.

[charlyheinz]

@triarch. Ich habe das wohl nicht mitgekriegt?! Funktioniert inzwischen eine UEFI- Installation im Seure-boot-mode. Und habt ihr das mit der Erneuerung/Änderung des Secure-boot-Schlüssels von Microsoft auch gelesen? Post ist hier vielleicht nicht ganz der richtige Platz.
Danke für Infos.

[ro_sid]

> Zum "45 Zeilen" Skript: Ich vermute, das bringt die Live-Variante nach dem
> ISO-Laden auf den neuesten Stand, erzeugt aber keine neue (veränderte) ISO-Datei, richtig?

Nein, das wäre trivial. Ausgehend von einem siduction_n.iso Image erzeugt es durch inkrementellen
Update ein siduction_{n+1}.iso Image.
[...]
Ich kann das Skript zur Verfügung stellen, will es aber vorher noch ein wenig narrensicherer machen.
Viele (alle Anwesenden natürlich ausgeschlosen) starten solche Skripte nämlich ohne zu wissen, was
sie tun, und gefährden damit ihre eigene Installation. Und zu wissen, was man tut, ist der Preis, den man
für die 45 Zeilen zu zahlen hat.

"Cool" in beiden Hinsichten - und bitte, ja, gerne, danke.

Check das Script neu aus, ich habe das Problem behoben.

Dafür ebenfalls ein herzliches Danke. Den neuen "Testbuild" habe ich schon zur Kenntnis genommen.
Mein eigener "Build" läuft gerade.