Beiträge von tuxali

Zitat von DenalB

Ich muss zugeben, dass ich in meinen Fedora-Installationen immer ziemlich schnell SELinux wegen Inkompatibilitäten komplett deaktiviert hatte. Tumbleweed läuft ja nun auch schon eine Weile mit SELinux statt AppArmor.

Sollte SELinux aktiviert bleiben oder ist es sinnvoll, es zu deaktivieren? Ich hatte damals bei meiner Recherche zu Fedora gelesen, dass SELinux eigentlich mehr Sinn auf Servern macht, als auf Desktops oder Laptops.

Was meint ihr?

Ich habe erst ca. 8 Wochen Erfahrung mit Tumbleweed; SELinux hat mir bisher genau einmal dazwischen gefunkt. Da ging es um den Zugriff eines Docker-Containers auf einen bind, also ein lokales Verzeichnis. Grundsätzlich mag es eine gute Idee sein, das zu unterbinden; da ich alleine an meinem Rechner arbeite, hat es mich eher gestört. Es ließ sich aber durch Neuanlegen einer entsprechenden Regel schnell beheben; ich habe SELinux aktiviert gelassen.

Zitat von steron69

Wenn Du das so nicht magst, kannst Du Flatpaks nutzen.

Ja, danke, wobei ich auch die Flatpaks auf ein Minimum zu reduzieren versuche. Meine Methode mit dem "Umweg" funktioniert ja auch und das AppImage liegt dort, wo ich es haben möchte. Derzeit habe ich auch nur ein oder zwei AppImages im Einsatz, falls es deutlich mehr werden, schaue ich mir gearlever gerne wieder an.

Zitat von tuxali

Ja, danke, das war wohl das Problem. Bin zurück auf einen schreibbaren Schnappschuss und mache von da aus weiter.Keine Ahnung, wie das passiert ist, ich benutze diesen Rechner nur äußerst selten.

Ich kann es nicht mehr genau nachvollziehen, aber offensichtlich muss ich mal aus einem snapshot gebootet haben und habe dann kein rollback vorgenommen; der Rechner wird selten benutzt, wie gesagt.
Ich denke, das Thema kann dann geschlossen werden; nochmals vielen Dank für die hilfreichen Hinweise

Zitat von Sauerland

Ich hoffe, du benutzt auch nur

Code

zypper dup

zum Updaten......

Edit:

Siehe nächster Beitrag

Yup, tue ich.

Zitat von Sauerland

Mit Schnappschuss starten, ausprobieren und wenn es funktioniert mit snapper den Schnappschuss wiederherstellen.

Ja, danke, das war wohl das Problem. Bin zurück auf einen schreibbaren Schnappschuss und mache von da aus weiter.Keine Ahnung, wie das passiert ist, ich benutze diesen Rechner nur äußerst selten.

Zitat von Sauerland

Startest du einen Schnappschuß?

Die sind nur ro.

df funktioniert bei btrfs nicht zuverlässig, dort ist btrfs dein Freund.

Ich habe nach der Aktualisierung den Rechner heruntergefahren und mit dem default-Eintrag in grub neu gestartet. Aber die Überlegung mit dem Schnappschuss macht natürlich Sinn. Ich muss mir mal anschauen, was grub da eigentlich anbietet und warum. Danke für den Hinweis.

Zitat von Sauerland

Was sagt denn

Code

mount

Festplatte evt. voll?

Eher nicht.

mount

/dev/sda8 on / type btrfs (rw,relatime,seclabel,space_cache=v2,subvolid=415,subvol=/@/.snapshots/152/snapshot)

devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=3725248k,nr_inodes=931312,mode=755,inode64)

tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel,inode64,usrquota)

devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=600,ptmxmode=000)

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)

securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)

cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate,memory_recursiveprot,memory_hugetlb_accounting)

none on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime,seclabel)

efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)

configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,size=1516180k,nr_inodes=819200,mode=755,inode64)

selinuxfs on /sys/fs/selinux type selinuxfs (rw,nosuid,noexec,relatime)

systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=38,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=8225)

none on /run/credentials/systemd-journald.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)

mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime,seclabel)

tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime,seclabel)

hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,seclabel,pagesize=2M)

debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime,seclabel)

fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)

tmpfs on /tmp type tmpfs (rw,nosuid,nodev,seclabel,nr_inodes=1048576,inode64,usrquota)

/dev/sda8 on /.snapshots type btrfs (rw,relatime,seclabel,space_cache=v2,subvolid=263,subvol=/@/.snapshots)

/dev/sda8 on /srv type btrfs (rw,relatime,seclabel,space_cache=v2,subvolid=259,subvol=/@/srv)

/dev/sda8 on /opt type btrfs (rw,relatime,seclabel,space_cache=v2,subvolid=261,subvol=/@/opt)

/dev/sda8 on /root type btrfs (rw,relatime,seclabel,space_cache=v2,subvolid=260,subvol=/@/root)

/dev/sda8 on /usr/local type btrfs (rw,relatime,seclabel,space_cache=v2,subvolid=258,subvol=/@/usr/local)

/dev/sda8 on /home type btrfs (rw,relatime,seclabel,space_cache=v2,subvolid=262,subvol=/@/home)

/dev/sda8 on /var type btrfs (rw,relatime,seclabel,space_cache=v2,subvolid=257,subvol=/@/var)

/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)

binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)

none on /run/credentials/getty@tty1.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,seclabel,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)

tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=758088k,nr_inodes=189522,mode=700,uid=1000,gid=1000,inode64)

portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

tracefs on /sys/kernel/debug/tracing type tracefs (rw,nosuid,nodev,noexec,relatime,seclabel)

HP-LAPTOP-FR1BPUE3-LAN--30:/usr/lib/sysimage/rpm # df

Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf

/dev/sda8 417602560 33748128 382943728 9% /

devtmpfs 3725248 0 3725248 0% /dev

tmpfs 3790444 1884 3788560 1% /dev/shm

efivarfs 128 88 36 71% /sys/firmware/efi/efivars

tmpfs 1516180 1660 1514520 1% /run

none 1024 0 1024 0% /run/credentials/systemd-journald.service

tmpfs 3790444 8 3790436 1% /tmp

/dev/sda8 417602560 33748128 382943728 9% /.snapshots

/dev/sda8 417602560 33748128 382943728 9% /srv

/dev/sda8 417602560 33748128 382943728 9% /opt

/dev/sda8 417602560 33748128 382943728 9% /root

/dev/sda8 417602560 33748128 382943728 9% /usr/local

/dev/sda8 417602560 33748128 382943728 9% /home

/dev/sda8 417602560 33748128 382943728 9% /var

/dev/sda1 262144 193364 68780 74% /boot/efi

none 1024 0 1024 0% /run/credentials/getty@tty1.service

tmpfs 758088 72 758016 1% /run/user/1000

Hallo, ich habe vor ca. 1 h Tumbleweed auf einem alten und langsamen HP-Laptop von 2017 aktualisiert.

uname -a

Linux HP-LAPTOP-FR1BPUE3-LAN--30.fritz.box 7.0.12-1-default #1 SMP PREEMPT_DYNAMIC Wed Jun 10 05:12:39 UTC 2026 (8beab0b) x86_64 x86_64 x86_64 GNU/Linux

zypper lu zeigt keine neuen Aktualisierungen an. Wenn ich ein neues Paket installieren will, kommt eine Meldung, dass /usr/lib/sysimage/rpm/.rpm.lock nicht erstellt werden können wegen eines read-only-Dateisystems. Hier am Beispiel audacity, es klappt aber auch z.B. mit mc nicht:

zypper install audacity

Repository-Daten werden geladen...

Installierte Pakete werden gelesen...

Paketabhängigkeiten werden aufgelöst...

Das folgende empfohlene Paket wurde automatisch gewählt:

 audacity-lang

Die folgenden 11 NEUEN Pakete werden installiert:

 audacity audacity-lang libSoundTouch1 libsuil-0-0 libvamp-hostsdk3 libwx_baseu_net-suse-nostl16_0_0 libwx_baseu-suse-nostl16_0_0 libwx_baseu_xml-suse-nostl16_0_0

 libwx_gtk3u_core-suse-nostl16_0_0 libwx_gtk3u_html-suse-nostl16_0_0 libwx_gtk3u_qa-suse-nostl16_0_0

11 neue Pakete zu installieren.

Paketgröße zum Herunterladen:

| 14,0 MiB Gesamtpaketgröße

0 B | - 14,0 MiB bereits im Cache

Änderung der Installationsgröße des Pakets:

| 53,4 MiB erforderlich für Pakete, die installiert werden sollen

53,4 MiB | - 0 B freigegeben von Paketen, die entfernt werden sollen

Backend: classic_rpmtrans

Fortfahren? [j/n/v/...? zeigt alle Optionen] (j): j

Im Cache libSoundTouch1-2.3.3-1.5.x86_64.rpm (1/11), 49,6 KiB

Im Cache libsuil-0-0-0.10.22-1.4.x86_64.rpm (2/11), 17,8 KiB

Im Cache libvamp-hostsdk3-2.10.0-1.28.x86_64.rpm (3/11), 103,3 KiB

Im Cache libwx_baseu-suse-nostl16_0_0-3.2.8-4.4.x86_64.rpm (4/11), 787,6 KiB

Im Cache libwx_gtk3u_core-suse-nostl16_0_0-3.2.8-4.4.x86_64.rpm (5/11), 2,3 MiB

Im Cache libwx_baseu_xml-suse-nostl16_0_0-3.2.8-4.4.x86_64.rpm (6/11), 42,9 KiB

Im Cache libwx_baseu_net-suse-nostl16_0_0-3.2.8-4.4.x86_64.rpm (7/11), 135,1 KiB

Im Cache libwx_gtk3u_html-suse-nostl16_0_0-3.2.8-4.4.x86_64.rpm (8/11), 276,9 KiB

Im Cache libwx_gtk3u_qa-suse-nostl16_0_0-3.2.8-4.4.x86_64.rpm (9/11), 67,5 KiB

Im Cache audacity-3.7.7-1.3.x86_64.rpm (10/11), 8,1 MiB

Im Cache audacity-lang-3.7.7-1.3.noarch.rpm (11/11), 2,1 MiB

Überprüfung auf Dateikonflikte läuft: .................................................................................................................................................[fertig]

error: can't create transaction lock on /usr/lib/sysimage/rpm/.rpm.lock (Read-only file system)

( 1/11) Installieren: libSoundTouch1-2.3.3-1.5.x86_64 .................................................................................................................................[Fehler]

Installation von libSoundTouch1-2.3.3-1.5.x86_64 fehlgeschlagen:

Fehler: Subprocess failed. Error: RPM fehlgeschlagen: Kommando mit Status 1 beendet.

Abbrechen, wiederholen, ignorieren? [a/w/i] (a): a

Das oben besagte Verzeichnis müsste für root eigentlich beschreibbar sein:

cd /usr/lib/sysimage/rpm

HP-LAPTOP-FR1BPUE3-LAN--30:/usr/lib/sysimage/rpm # ls -l

insgesamt 220556

-rw-r--r--. 1 root root 87265280 16. Jun 16:15 Index.db

-rw-r--r--. 1 root root 138580368 16. Jun 16:15 Packages.db

-rw-r--r--. 1 root root 0 13. Nov 2025 .rpm.lock

aber:

HP-LAPTOP-FR1BPUE3-LAN--30:/usr/lib/sysimage/rpm # touch test.txt

touch: 'test.txt' kann nicht angelegt werden: Das Dateisystem ist nur lesbar

Auf meinem Hauptrechner mit Kernel 7.0.11-1-default funktioniert die Installation normal.
Was könnte da los sein? SE Linux ?

Wäre dankbar für einen Tipp.

Zitat von steron69

Am besten du installierst Gear Lever, dann wird alles elegant per Mausklick gelöst und deine AppImage ist elegant in der Desktop Umgebung (Menü) integriert.

Danke für den Tipp, gearlever kannte ich noch nicht, es funktioniert auch so wie beschrieben. Leider belegt mit gearlever auch jedes AppImage Speicherplatz im home-Verzeichnis, das ist eher nicht so mein Ding. Das Problem mit den Desktop-Verknüpfungen besteht übrigens auch bei Verknüpfungen zu Dateien, also nicht nur bei Programm-Verknüpfungen.

Ich versuche, unter Tumbleweed/Plasma 6.6.5 eine Verknüpfung zu einem AppImage in einem Unterverzeichnis meines ~ über die Funktion "Neu erstellen / Verknüpfung zu Programm" im Kontextmenü von Plasma anzulegen. Die entsprechende .desktop-Datei wird auch im Verzeichnis ~/Schreibtisch angelegt, aber nicht in der Arbeitsflächen-Ordner-Ansicht auf dem Bildschirm angezeigt. Abmeldung und Neuanmeldung des Benutzers bewirkt nichts.
Wenn man die .desktop-Datei in einen anderen Ordner verschiebt, wird die Verknüpfung korrekt angezeigt in einer Arbeitsflächen-Ordner-Ansicht, die auf diesen anderen Ordner zeigt. Wenn man sie dann von dort via drag-and-drop wieder auf die erste Arbeitsfläche verschiebt, erscheint sie ganz normal dort auf dem Bildschirm, die Anwendung aus dem AppImage lässt sich starten und die .desktop-Datei liegt wie erwartet und ohne sichtbare Veränderung wieder im Verzeichnis ~/Schreibtisch.
Ist dieses Verhalten bekannt und woran liegt das?