Beiträge von Sysform IT

    ok da weis ich bescheid. Neuinstallation habe ich erstmal keine Lust da mein Void soweit eingerichtet ist und gut läuft. :1f609:

    Verständlich. Ich habe Voidlinux auf meinem Textrechner laufen, aber nicht im produktiven Betrieb. Da ich ja dann so oft ich möchte einfach neuinstallieren.

    ich habe die aktuelle App nochmal probiert, bei mir kommt zum Schluss ISO-Erstellungder selbe Fehler wie gestern.

    Bei mir war der Fehler auch. Lag in Voidlinux. Irgendetwas verhindert die korrekte Ausführung des Creators.
    Erst als ich Voidlinux noch neu installiert habe, funktionierte es.

    Ich komme nicht richtig klar. Ich bitte um Hilfe.

    Ich habe mir die aktuelle ZIP heruntergeladen und entpackt.

    Ich habe mit dem Creator die Void-custum.iso erstellt.
    Starte die Iso dann mit einem Bootstick und erhalte (so wie gestern auch)
    dieses Anmeldefenster.
    (gibt für den Live Benuter auch ein Kennwort oder brauche ich den nicht?).
    Ich habe mich mit meinem Benutzer "sysform" angemeldet.

    Voidlinux Live startet, ich finde aber keine Möglichkeit zu installieren.

    ich habe es nochmal probiert, vorher auch in var temp gelöscht. Kommt zum Schluss wieder der Fehler, übrigends bis 80% ca. 5min von 80% bis fertig 25min.

    Das hängt bei der Kompression. Ist bei mir auch. Ich habe jetzt nochmal Voidlinux neu installiert. Man weiß nach nie und versuche es noch einmal.


    So, ich habe jetzt ein komplett frisches Voidlinux installiert.

    Und jetzt hat es komplett funktioniert.

    Warum es bei der alten Installation nicht funktioniert hat, wer weiß es schon :-).

    Ich habe anschließend den Rechner mit der neuen ISO installiert und mich mit meinen
    Sysform Logindaten angemeldet und hatte direkt ein fertig eingerichtetes Voidlinux.

    Halt also super geklappt.

    Vielen Dank Armin für deine unermütlichen Bemühungen!!!

    Komprimierung bleibt bei 80% im Verlauf stehen:

    (KomprimiereDateisystem (SquashFS)...)


    Terminalausgabe mit "python3 main.py"

    [sysform@geekom void-live-creator]$ sudo python3 main.py
    Passwort:
    /usr/local/bin/void-live-creator/main.py:135: DeprecationWarning: Gtk.TreeView.append_column is deprecated
    self.path_view.append_column(Gtk.TreeViewColumn("Pfade", Gtk.CellRendererText(), text=0))

    (python3:19307): Gtk-WARNING **: 17:40:09.226: Failed to set text '<i>Hinweis: NetworkManager & D-Bus werden automatisch aktiviert.</i>' from markup due to error parsing markup: Fehler in Zeile 1: Entität endete nicht mit einem Semikolon; wahrscheinlich haben Sie ein &-Zeichen benutzt, ohne eine Entität beginnen zu wollen – umschreiben Sie das »&« als &amp;

    (python3:19307): Gtk-WARNING **: 17:40:09.266: GtkGizmo 0x5587f1380400 (slider) reported min width -2, but sizes must be >= 0

    (python3:19307): Gtk-WARNING **: 17:40:09.266: GtkGizmo 0x5587f184ec60 (slider) reported min height -2, but sizes must be >= 0

    (python3:19307): Gtk-WARNING **: 17:40:09.285: GtkGizmo 0x5587f1d6ce80 (slider) reported min width -2, but sizes must be >= 0

    (python3:19307): Gtk-WARNING **: 17:40:09.285: GtkGizmo 0x5587f1d69e30 (slider) reported min height -2, but sizes must be >= 0

    Ein 2. Efi ist dann sinnvoll, wenn die 1. Efi evtl. zu klein konfiguriert wurde.
    Wenn jedes Betriebssystem eine eigene Efi hat, kann ich sofern beide
    Betriebssystem wahlweise über das UEFI-Bootmenü auswählen, sofern
    der Eintrag im Grub fehlerhaft ist und mit update auch nicht zu
    beheben ist.

    Bei meiner Voidlinux Installation gibt es nur 1 Efi, man kann hier auch bei
    manueller Partitionierung keine 2. EFI installieren.


    Ich komme im Moment leider nicht dazu, ich werde vermutlich snapper wieder entfernen, und erst Mal den Installer so stabil machen das alles richtig funktioniert

    Ich finde das es kein dringendes Problem darstellt.
    Gut Ding braucht Weile.

    Ich glaube ich mache mich langsam aber sicher unbeliebt.

    Während bei einer Dualboot Installation mit ext4 der Grub-Bootloader
    im letzten Schritt des Installationsablaufs, beide Installationen enthält,

    wird nach meiner Meinung bei einer Dualboot Installation mit btrfs
    der Grub-Bootloader nicht richtig konfiguriert.

    Im Grub steht nur die letzte Installation eingetragen.

    Lässt sich auch nicht mit "sudo update-grub" beheben.

    Das ist die Ausgabe nach dem Rollback:

    [sysform@geekom ~]$ sudo snapper --ambit classic rollback
    Passwort:
    Anwendungsbereich ist classic.
    Nur-Lesen-Schnappschuss des Standard-Subvolumes erstellen. (Schnappschuss 16.)
    Lesen-Schreiben-Schnappschuss des derzeit laufenden Subvolumes erstellen. (Schnappschuss 17.)
    Einstellung des Standard-Subvolumes zu Schnappschuss 17.
    [sysform@geekom ~]$

    Das System ist danach immer noch im "read-only" Modus.


    Es scheint so, als ob es jetzt bei mir auch mit "sudo snapper --ambit classic <ID> funktioniert hat.

    Sehrwahrscheinlich ist nicht jeder Snapshot bei mir zum Rollback geeignet gewesen (komisch).
    Ich habe mehrere Snapshots ausprobiert und jetzt scheint es zu funktionieren.

    Wenn ich jetzt "sudo snapper rollback" eingebe, kommt auch keine Fehlermeldung mehr.

    Auf jeden Fall hat er den über GRUB geladenen Snapshot, der "read only" war
    an dem Rollback in "writetable" gesetzt.

    Habe ich jetzt gemacht. Vorher gebetet bzw. gerequezillert (Grub im "read only" Modus ändern ist schwierig :-))

    Hat leider noch nicht funktioniert

    So sieht das jetzt aus:

    ID 256 gen 1332 top level 5 path @ (ich habe diese ID genommen)
    ID 258 gen 133 top level 5 path @snapshots
    ID 259 gen 1332 top level 5 path @var_log
    ID 260 gen 1329 top level 5 path @var_cache
    ID 261 gen 190 top level 5 path @var_tmp
    ID 262 gen 1332 top level 5 path @tmp
    ID 265 gen 54 top level 258 path @snapshots/1/snapshot
    ID 266 gen 124 top level 258 path @snapshots/2/snapshot
    ID 267 gen 130 top level 258 path @snapshots/3/snapshot
    ID 268 gen 132 top level 258 path @snapshots/4/snapshot

    So sieht es nach der Korrektur aus:
    UUID=61c10269-bf29-410a-99a5-7fd9f5bc8d5e / btrfs defaults,noatime,compress=zstd 0 1
    UUID=61c10269-bf29-410a-99a5-7fd9f5bc8d5e /home btrfs defaults,noatime,compress=zstd,subvol=@home 0 2
    UUID=61c10269-bf29-410a-99a5-7fd9f5bc8d5e /.snapshots btrfs defaults,noatime,compress=zstd,subvol=@snapshots 0 2
    UUID=61c10269-bf29-410a-99a5-7fd9f5bc8d5e /var/log btrfs defaults,noatime,compress=zstd,subvol=@var_log 0 2
    UUID=61c10269-bf29-410a-99a5-7fd9f5bc8d5e /var/cache btrfs defaults,noatime,compress=zstd,subvol=@var_cache 0 2
    UUID=61c10269-bf29-410a-99a5-7fd9f5bc8d5e /var/tmp btrfs defaults,noatime,compress=zstd,subvol=@var_tmp 0 2
    UUID=61c10269-bf29-410a-99a5-7fd9f5bc8d5e /tmp btrfs defaults,noatime,compress=zstd,subvol=@tmp 0 2

    ++++++++++++++++++++++++++++++++++++

    Nach dem Kommando. "sudo snapper rollback" kommt die Fehlermeldung:

    [sysform@geekom ~]$ sudo snapper rollback
    Passwort:
    Anwendungsbereich kann nicht erkannt werden, weil das Standard-Subvolume unbekannt ist.
    Das kann passieren, wenn das System nicht für Rollbacks eingerichtet wurde.
    Der Anwendungsbereich kann manuell durch die Verwendung der Option --ambit angegeben werden.
    [sysform@geekom ~]$

    ++++++++++++++++++++++++++++++++++++