Skip to content

Flatpak Paket zurückrollen

Linux
  • Ihr habt ein Paket was nicht so richtig läuft? z.B. Firefox 112 und man will auf 111 zurück?

    flatpak remote-info --log flathub org.mozilla.firefox
    

    Ausgabe

    root@debian:/home/frank/Downloads# flatpak remote-info --log flathub org.mozilla.firefox
         Kennung: org.mozilla.firefox
             Ref: app/org.mozilla.firefox/x86_64/stable
     Architektur: x86_64
           Zweig: stable
        Sammlung: org.flathub.Stable
    Herunterladen 90,8 MB
     Installiert: 251,2 MB
        Laufzeitumgebung: org.freedesktop.Platform/x86_64/22.08
             Sdk: org.freedesktop.Sdk/x86_64/22.08
    
          Commit: 840b89bc5fc47a5954548e415cb16c8f41b396750744dfa312f95915f1ae0f01
          Parent: 8d04ad9013400e338451f0a20dd087d4345e1bddcf8fc8cd1c159ae62174edc7
         Betreff: Export org.mozilla.firefox
           Datum: 2023-04-11 12:32:11 +0000
         Verlauf: 
    
          Commit: 8d04ad9013400e338451f0a20dd087d4345e1bddcf8fc8cd1c159ae62174edc7
         Betreff: Export org.mozilla.firefox
           Datum: 2023-03-21 17:31:04 +0000
    

    Das Paket vom 11.04 war das 112er, das Paket vom 21.03 das 111er. Zurückrollen mit

    flatpak update --commit=8d04ad9013400e338451f0a20dd087d4345e1bddcf8fc8cd1c159ae62174edc7 org.mozilla.firefox
    

    Fertig. Aufpassen, wenn man die Flatpak Pakete aktualisiert, dann wird natürlich wieder auf die 112 gerollt.

  • FrankMF FrankM hat am auf dieses Thema verwiesen
  • LibreOffice Security Update

    Linux
    1
    0 Stimmen
    1 Beiträge
    114 Aufrufe
    Niemand hat geantwortet
  • KDE Plasma 6 - Beta 2

    Linux
    2
    0 Stimmen
    2 Beiträge
    208 Aufrufe
    FrankMF
    Leider hat die Realität mich etwas vom Testen neuer Software abgehalten, aber jetzt geht es langsam wieder los. Den Start macht KDE Plasma 6 - Beta 2. Auch wenn ich schon brennend auf die RC1 warte, die lässt aber noch auf sich warten... https://pointieststick.com/category/this-week-in-kde/ Ok, also die Beta 2 auf meinen Stick und ab damit in mein Testsystem. Einmal starten, kurz danach taucht der KDE Neon Desktop auf. [image: 1705002299148-20240110_201838-resized.jpg] [image: 1705002324795-20240110_201852-resized.jpg] Und klick, wird die Installation gestartet. Danach begrüßt uns dieses Fenster. Ich weiß nicht, warum diese Information nicht automatisch ermittelt wird - nervig. [image: 1705002522434-20240110_201924-resized.jpg] Der Rest der Installation lief einwandfrei, ich habe aber keine besondere Installation vorgenommen. Ganze NVMe plattgemacht und alles drauf. Nichts verschlüsselt usw. Eine Installation, die ich so für meinen Haupt-PC nicht machen würde. Eine Kleinigkeit ist mir noch aufgefallen. Der Calamares Installer der benutzt wird, hat bei mir keine Sonderzeichen akzeptiert. Ich hoffe das wird bis zum Release gefixt. Hier noch kurz das Testsystem [image: 1705003417706-screenshot_20240111_210201.png] Ich nutze ausschließlich Wayland, das läuft einfach wesentlich besser. Aber, ich weiß da draußen gibt es viele die das nicht mögen. Das schöne an Linux - ihr habt die freie Wahl. Was war mir negativ aufgefallen? Installer - keine automatische Standortbestimmung Installer - nimmt keine Sonderzeichen für das PW an Login Window - nach Eingabe PW wird die Taste RETURN nicht akzeptiert. Muss ich mit der Maus anklicken. Skalierung auf meinem Monitor nicht optimal - Schrift unscharf Was ist mir positiv aufgefallen? Ich nutze einen 4K Monitor zum Testen. Die Skalierung war automatisch auf 175%. Eine fast perfekte Wahl, wenn da nicht die unscharfe Schrift wäre. Ich habe das auf 150% gestellt, danach war es deutlich besser. Updates kann man sich über das grafische Frontend holen Standby-Modus ging Und einen nervigen FF Bug konnte ich nicht nachstellen. Auf meinem aktuellen System, KDE Plasma 5, flackert der Bildschirm gelegentlich, wenn ich in der Taskleiste durch die geöffneten FF Fenster scrolle. Bei Plasma 6 konnte ich das bis jetzt noch nicht feststellen. Fazit Sieht gut aus, der Release von KDE Plasma 6 wird gut. Ich freu mich drauf. Und diesen komischen Updatevorgang den KDE Neon da benutzt, diesen M$ Style, den könnt ihr direkt wieder in die Mülltonne kloppen. Das möchte ich bei Linux nicht sehen. [image: 1705005840070-screenshot_20240111_214255-resized.png]
  • Links zu Vaultwarden

    Angeheftet Vaultwarden
    1
    0 Stimmen
    1 Beiträge
    138 Aufrufe
    Niemand hat geantwortet
  • Ansible - ein kurzer Test

    Linux
    1
    0 Stimmen
    1 Beiträge
    152 Aufrufe
    Niemand hat geantwortet
  • Ubiquiti ER-X - Installation

    Verschoben OpenWRT & Ubiquiti ER-X
    1
    1
    0 Stimmen
    1 Beiträge
    588 Aufrufe
    Niemand hat geantwortet
  • Kopia - Kopia-Server mit Kopia-UI

    Kopia
    1
    2
    0 Stimmen
    1 Beiträge
    417 Aufrufe
    Niemand hat geantwortet
  • LUKS verschlüsselte Platte mounten

    Linux
    2
    1
    0 Stimmen
    2 Beiträge
    1k Aufrufe
    FrankMF
    So, jetzt das ganze noch einen Ticken komplizierter Ich habe ja heute, für eine Neuinstallation von Ubuntu 20.04 Focal eine zweite NVMe SSD eingebaut. Meinen Bericht zu dem Thema findet ihr hier. Aber, darum soll es jetzt hier nicht gehen. Wir haben jetzt zwei verschlüsselte Ubuntu NVMe SSD Riegel im System. Jetzt klappt die ganze Sache da oben nicht mehr. Es kommt immer einen Fehlermeldung. unbekannter Dateisystemtyp „LVM2_member“. Ok, kurz googlen und dann findet man heraus, das es nicht klappen kann, weil beide LVM Gruppen, den selben Namen benutzen. root@frank-MS-7C37:/mnt/crypthome/root# vgdisplay --- Volume group --- VG Name vgubuntu2 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 1 Max PV 0 Cur PV 1 Act PV 1 VG Size <464,53 GiB PE Size 4,00 MiB Total PE 118919 Alloc PE / Size 118919 / <464,53 GiB Free PE / Size 0 / 0 VG UUID lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A --- Volume group --- VG Name vgubuntu System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size <475,71 GiB PE Size 4,00 MiB Total PE 121781 Alloc PE / Size 121781 / <475,71 GiB Free PE / Size 0 / 0 VG UUID jRYTXL-zjpY-lYr6-KODT-u0LJ-9fYf-YVDna7 Hier oben sieht man das schon mit geändertem Namen. Der VG Name muss unterschiedlich sein. Auch dafür gibt es ein Tool. root@frank-MS-7C37:/mnt/crypthome/root# vgrename --help vgrename - Rename a volume group Rename a VG. vgrename VG VG_new [ COMMON_OPTIONS ] Rename a VG by specifying the VG UUID. vgrename String VG_new [ COMMON_OPTIONS ] Common options for command: [ -A|--autobackup y|n ] [ -f|--force ] [ --reportformat basic|json ] Common options for lvm: [ -d|--debug ] [ -h|--help ] [ -q|--quiet ] [ -v|--verbose ] [ -y|--yes ] [ -t|--test ] [ --commandprofile String ] [ --config String ] [ --driverloaded y|n ] [ --nolocking ] [ --lockopt String ] [ --longhelp ] [ --profile String ] [ --version ] Use --longhelp to show all options and advanced commands. Das muss dann so aussehen! vgrename lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A vgubuntu2 ACHTUNG Es kann zu Datenverlust kommen, also wie immer, Hirn einschalten! Ich weiß, das die erste eingebaute Platte mit der Nummer /dev/nvme0n1 geführt wird. Die zweite, heute verbaute, hört dann auf den Namen /dev/nvme1n1. Die darf ich nicht anpacken, weil sonst das System nicht mehr startet. /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> /dev/mapper/vgubuntu-root / ext4 errors=remount-ro 0 1 # /boot was on /dev/nvme1n1p2 during installation UUID=178c7e51-a1d7-4ead-bbdf-a956eb7b754f /boot ext4 defaults 0 2 # /boot/efi was on /dev/nvme0n1p1 during installation UUID=7416-4553 /boot/efi vfat umask=0077 0 1 /dev/mapper/vgubuntu-swap_1 none swap sw 0 0 Jo, wenn jetzt die Partition /dev/mapper/vgubuntu2-root / anstatt /dev/mapper/vgubuntu-root / heißt läuft nichts mehr. Nur um das zu verdeutlichen, auch das könnte man problemlos reparieren. Aber, ich möchte nur warnen!! Nachdem die Änderung durchgeführt wurde, habe ich den Rechner neugestartet. Puuh, Glück gehabt, richtige NVMe SSD erwischt Festplatte /dev/mapper/vgubuntu2-root: 463,58 GiB, 497754832896 Bytes, 972177408 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Nun können wir die Platte ganz normal, wie oben beschrieben, mounten. Nun kann ich noch ein paar Dinge kopieren
  • checkmk - Dockerinstallation

    Verschoben checkmk
    9
    2
    0 Stimmen
    9 Beiträge
    1k Aufrufe
    FrankMF
    Und noch was Wichtiges. [image: 1628408271316-6777da6e-3b4f-41b9-bf6e-26496ae67cd8-grafik.png] Damit sichert man den Datenaustausch ab. Kapitel 7.4. Inbuilt encryption Den Ordner findet man hier -> /etc/check_mk/encryption.cfg