Recent posts
#51
Upgrade Warnings / Re: Automatische Budgie Instal...
Last post by harley-peter - 2026/08/21, 08:54:32 #52
Upgrade Warnings / Re: Automatische Budgie Instal...
Last post by Teriarch - 2026/08/20, 23:21:35Kann es sein, dass im Falle des Desktop Rechners gnome-shell als manuell
installiert vermerkt war? Das lässt sich mit
würde sich apt nämlich weigern, ersatzlos das Paket durch einen full-upgrade zu
entfernen (weil der Benutzer ja auf seinem Erhalt besteht). Und auf dem anderen
Rechner stand es mglw. auf auto mit all den Konsequenzen, die wir beobachtet
haben. Dies könnte das unterschiedliche Verhalten erklären.
Falls es manuell installiert ist, kann man es mit
installiert vermerkt war? Das lässt sich mit
Code Select
$ apt-mark showmanual gnome-shellleicht herausfinden (die andere Möglichkeit wäre showauto). In diesem Fallwürde sich apt nämlich weigern, ersatzlos das Paket durch einen full-upgrade zu
entfernen (weil der Benutzer ja auf seinem Erhalt besteht). Und auf dem anderen
Rechner stand es mglw. auf auto mit all den Konsequenzen, die wir beobachtet
haben. Dies könnte das unterschiedliche Verhalten erklären.
Falls es manuell installiert ist, kann man es mit
Code Select
$ sudo apt-mark auto gnome-shell (vs. $ sudo apt-mark manual gnome-shell)kurz zurücksetzen und sehen, ob dann der Rattenschwanz folgt. #53
Upgrade Warnings / Re: Automatische Budgie Instal...
Last post by harley-peter - 2026/08/20, 22:04:05Das ist ja das Seltsame, alle überprüften Pakete haben die selbe Versionsnummer und sind auch alle installiert. Trotzdem hält auf dem Desktop Rechner ein full-upgrade lediglich die Pakete gjs und libgjs0 von der Aktualisierung zurück, der Rest funktioniert völlig normal.
#54
Upgrade Warnings / Re: Automatische Budgie Instal...
Last post by Teriarch - 2026/08/20, 21:02:56> [...] ist alles wieder i. O., auch der ganze Budgie Mist ist vom Tisch:
ja, das hatte ich vermutet. Leider konnten wir den genauen Grund für
die neu erzeugten Abhängigkeiten nicht finden. Die Ursache hat jedenfalls
etwas mit der Entfernung von gdm3, gnome-browser-connector und gnome-shell
zu tun; deshalb wäre ich ebenfalls vorsichtig, auf Verdacht gnome relevante
Pakete zu entfernen. Der Abhängigkeitsgraph einer normalen Installtion besteht
aus mehreren tausend Knoten und Kanten; ich vermute, dass die gewaltsame
Entfernung zu einer Disfunktionalität geführt hätte, die der Paketmanager
vielleicht durch Recommend Direktiven und Voreinstellungen auszugleichen
versuchte. Dabei brachte er diese unübliche budgie Desktop Variante ins Spiel
(über welche Pfade im Graphen wissen wohl nur die Götter).
Das eigentliche Problem verschwindet erst mit einer Aktualisierung von
gnome-shell, deren veraltete Version das ganze Chaos verursacht hat.
Auch die intermediäre Version von libgjs0 wird ohne viel Lärm dem nächsten
Update zum Opfer fallen.
Nachtrag:
Dabei fällt mir ein: Du erwähntest, dass auf einem anderen Rechner das
gleiche Problem zwischenzeitlich verschwunden sei. Da jener Rechner über die
modifizierte libgjs0 Version nicht verfügen kann, frage ich mich, welche der
Pakete libgjs0, gjs, gdm3, gnome-browser-connector bzw. gnome-shell denn
dort fehlen?
ja, das hatte ich vermutet. Leider konnten wir den genauen Grund für
die neu erzeugten Abhängigkeiten nicht finden. Die Ursache hat jedenfalls
etwas mit der Entfernung von gdm3, gnome-browser-connector und gnome-shell
zu tun; deshalb wäre ich ebenfalls vorsichtig, auf Verdacht gnome relevante
Pakete zu entfernen. Der Abhängigkeitsgraph einer normalen Installtion besteht
aus mehreren tausend Knoten und Kanten; ich vermute, dass die gewaltsame
Entfernung zu einer Disfunktionalität geführt hätte, die der Paketmanager
vielleicht durch Recommend Direktiven und Voreinstellungen auszugleichen
versuchte. Dabei brachte er diese unübliche budgie Desktop Variante ins Spiel
(über welche Pfade im Graphen wissen wohl nur die Götter).
Das eigentliche Problem verschwindet erst mit einer Aktualisierung von
gnome-shell, deren veraltete Version das ganze Chaos verursacht hat.
Auch die intermediäre Version von libgjs0 wird ohne viel Lärm dem nächsten
Update zum Opfer fallen.
Nachtrag:
Dabei fällt mir ein: Du erwähntest, dass auf einem anderen Rechner das
gleiche Problem zwischenzeitlich verschwunden sei. Da jener Rechner über die
modifizierte libgjs0 Version nicht verfügen kann, frage ich mich, welche der
Pakete libgjs0, gjs, gdm3, gnome-browser-connector bzw. gnome-shell denn
dort fehlen?
#55
Upgrade Warnings / Re: Automatische Budgie Instal...
Last post by harley-peter - 2026/08/20, 20:29:52@Teriarch:
Nach den von dir vorgeschlagenen Installationen inklusive Patch ist alles wieder i. O., auch der ganze Budgie Mist ist vom Tisch:
Zum wiederholten Male vielen Dank für deine tolle Unterstützung.
@edlin und hendrikL:
Es wäre wirklich mal interessant heraus zu finden, was von dem gnome Zeug tatsächlich benötigt wird. Auf meinem Laptop sind das eine ganze Menge Pakete:
Allerdings traue ich mich dann doch nicht sie sukzessive nach dem try-and-error Prinzip zu entfernen, ich möchte mir nicht mein System zerschießen. Gerade bei den keyring und policykit Sachen hätte ich Bauchschmerzen.
Ich habe keines davon bewusst installiert und vermute, dass diese von Anfang an mit installiert wurden.
Code Select
apt -s full-upgrade gjs libgjs0
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
gir1.2-accountsservice-1.0 gir1.2-gweather-4.0 ibus-data linux-headers-7.1.6-1-siduction-amd64
gir1.2-atspi-2.0 gir1.2-ibus-1.0 im-config linux-image-6.19.14-1-siduction-amd64
gir1.2-gck-2 gir1.2-mutter-18 libkmlbase1t64 linux-image-7.0.12-1-siduction-amd64
gir1.2-gcr-4 gir1.2-nma4-1.0 libkmldom1t64 linux-image-7.1.4-1-siduction-amd64
gir1.2-gdesktopenums-3.0 gir1.2-rsvg-2.0 libkmlengine1t64 linux-image-7.1.5-1-siduction-amd64
gir1.2-gdm-1.0 gir1.2-upowerglib-1.0 libqt5concurrent5t64 linux-image-7.1.6-1-siduction-amd64
gir1.2-geoclue-2.0 gnome-session-bin linux-headers-6.19.14-1-siduction-amd64 python3-ibus-1.0
gir1.2-gnomebg-4.0 gnome-session-common linux-headers-7.0.12-1-siduction-amd64 switcheroo-control
gir1.2-gnomebluetooth-3.0 gnome-shell-common linux-headers-7.1.4-1-siduction-amd64
gir1.2-gnomedesktop-4.0 ibus linux-headers-7.1.5-1-siduction-amd64
Verwenden Sie »apt autoremove«, um sie zu entfernen.
Aktualisiere:
gjs libgjs0
Installiere Abhängigkeiten:
budgie-control-center gammastep libbudgie-plugin0 libpeas-2-0 libxcb-ewmh2 swaylock
budgie-control-center-data gir1.2-budgie-3.0 libbudgie-private0 libpeas-2-common libxdo3 wdisplays
budgie-core gir1.2-budgieraven-3.0 libbudgie-raven-plugin0 libraven0 network-manager-applet wlopm
budgie-desktop gir1.2-peas-2 libbudgie-windowing0 libseat1 plasma-version wlr-randr
budgie-desktop-services kwayland6-data libbudgietheme0 libsfdo0 slurp xdg-desktop-portal-wlr
budgie-desktop-view labwc libkwaylandclient6 libwlroots-0.20 swaybg xdotool
budgie-session libbudgie-appindexer0 libliftoff0 libxcb-errors0 swayidle
Vorgeschlagene Pakete:
gnome-software budgie-desktop-environment mako-notifier network-manager-openconnect-gnome network-manager-pptp-gnome
| gnome-packagekit gnome-terminal waybar network-manager-openvpn-gnome
gtklock-userinfo-module kanshi xwayland network-manager-vpnc-gnome
ENTFERNE:
gdm3 gnome-browser-connector gnome-shell
Zusammenfassung:
Aktualisiere: 2, Installiere: 41, Entferne: 3, Aktualisiere nicht: 0
Remv gdm3 [50.1-2]
Remv gnome-browser-connector [42.1-7]
Remv gnome-shell [50.3-1]
Inst budgie-control-center-data (2.1.3-1 Debian:unstable [all])
Inst budgie-control-center (2.1.3-1 Debian:unstable [amd64])
Inst budgie-session (1.0.1-2+b1 Debian:unstable [amd64])
Inst gammastep (2.0.11-1 Debian:unstable [amd64])
Inst libpeas-2-common (2.2.1-2 Debian:unstable [all])
Inst libpeas-2-0 (2.2.1-2 Debian:unstable [amd64])
Inst gir1.2-peas-2 (2.2.1-2 Debian:unstable [amd64])
Inst libbudgie-plugin0 (10.10.2-3+b1 Debian:unstable [amd64])
Inst gir1.2-budgie-3.0 (10.10.2-3+b1 Debian:unstable [amd64])
Inst libbudgie-raven-plugin0 (10.10.2-3+b1 Debian:unstable [amd64])
Inst gir1.2-budgieraven-3.0 (10.10.2-3+b1 Debian:unstable [amd64])
Inst libbudgie-private0 (10.10.2-3+b1 Debian:unstable [amd64])
Inst libbudgie-appindexer0 (10.10.2-3+b1 Debian:unstable [amd64])
Inst libbudgietheme0 (10.10.2-3+b1 Debian:unstable [amd64])
Inst libraven0 (10.10.2-3+b1 Debian:unstable [amd64])
Inst slurp (1.6.0really1.5.0-1 Debian:unstable [amd64])
Inst swaybg (1.2.2-1 Debian:unstable [amd64])
Inst swayidle (1.9.0-1 Debian:unstable [amd64])
Inst wlopm (1.0.0-1 Debian:unstable [amd64])
Inst libbudgie-windowing0 (10.10.2-3+b1 Debian:unstable [amd64])
Inst budgie-core (10.10.2-3+b1 Debian:unstable [amd64])
Inst network-manager-applet (1.36.0-5 Debian:unstable [amd64])
Inst libxdo3 (1:3.20160805.1-5.1+b2 Debian:unstable [amd64])
Inst xdotool (1:3.20160805.1-5.1+b2 Debian:unstable [amd64])
Inst wdisplays (1.1.3-1 Debian:unstable [amd64])
Inst wlr-randr (0.4.1-1 Debian:unstable [amd64])
Inst plasma-version (6.7.0 Debian:unstable [all])
Inst kwayland6-data (4:6.7.4-1 Debian:unstable [all])
Inst libkwaylandclient6 (4:6.7.4-1 Debian:unstable [amd64])
Inst budgie-desktop-services (1.0.2-4 Debian:unstable [amd64])
Inst budgie-desktop (10.10.2-3 Debian:unstable [all])
Inst budgie-desktop-view (10.10.2-2 Debian:unstable [amd64])
Inst gjs [1.88.1-1] (1.89.2-2 Debian:unstable [amd64]) []
Inst libgjs0 [1.88.1-1] (1.89.2-2 Debian:unstable [amd64])
Inst libsfdo0 (0.1.4-2 Debian:unstable [amd64])
Inst libliftoff0 (0.5.0-1.1+b2 Debian:unstable [amd64])
Inst libseat1 (0.9.3-1 Debian:unstable [amd64])
Inst libxcb-errors0 (1.0.1-4+b2 Debian:unstable [amd64])
Inst libxcb-ewmh2 (0.4.2-1+b2 Debian:unstable [amd64])
Inst libwlroots-0.20 (0.20.2-1 Debian:unstable [amd64])
Inst labwc (0.20.1-1 Debian:unstable [amd64])
Inst swaylock (1.8.6-1 Debian:unstable [amd64])
Inst xdg-desktop-portal-wlr (0.8.4-1 Debian:unstable [amd64])
Conf budgie-control-center-data (2.1.3-1 Debian:unstable [all])
Conf budgie-control-center (2.1.3-1 Debian:unstable [amd64])
Conf budgie-session (1.0.1-2+b1 Debian:unstable [amd64])
Conf gammastep (2.0.11-1 Debian:unstable [amd64])
Conf libpeas-2-common (2.2.1-2 Debian:unstable [all])
Conf libpeas-2-0 (2.2.1-2 Debian:unstable [amd64])
Conf gir1.2-peas-2 (2.2.1-2 Debian:unstable [amd64])
Conf libbudgie-plugin0 (10.10.2-3+b1 Debian:unstable [amd64])
Conf gir1.2-budgie-3.0 (10.10.2-3+b1 Debian:unstable [amd64])
Conf libbudgie-raven-plugin0 (10.10.2-3+b1 Debian:unstable [amd64])
Conf gir1.2-budgieraven-3.0 (10.10.2-3+b1 Debian:unstable [amd64])
Conf libbudgie-private0 (10.10.2-3+b1 Debian:unstable [amd64])
Conf libbudgie-appindexer0 (10.10.2-3+b1 Debian:unstable [amd64])
Conf libbudgietheme0 (10.10.2-3+b1 Debian:unstable [amd64])
Conf libraven0 (10.10.2-3+b1 Debian:unstable [amd64])
Conf slurp (1.6.0really1.5.0-1 Debian:unstable [amd64])
Conf swaybg (1.2.2-1 Debian:unstable [amd64])
Conf swayidle (1.9.0-1 Debian:unstable [amd64])
Conf wlopm (1.0.0-1 Debian:unstable [amd64])
Conf libbudgie-windowing0 (10.10.2-3+b1 Debian:unstable [amd64])
Conf budgie-core (10.10.2-3+b1 Debian:unstable [amd64])
Conf network-manager-applet (1.36.0-5 Debian:unstable [amd64])
Conf libxdo3 (1:3.20160805.1-5.1+b2 Debian:unstable [amd64])
Conf xdotool (1:3.20160805.1-5.1+b2 Debian:unstable [amd64])
Conf wdisplays (1.1.3-1 Debian:unstable [amd64])
Conf wlr-randr (0.4.1-1 Debian:unstable [amd64])
Conf plasma-version (6.7.0 Debian:unstable [all])
Conf kwayland6-data (4:6.7.4-1 Debian:unstable [all])
Conf libkwaylandclient6 (4:6.7.4-1 Debian:unstable [amd64])
Conf budgie-desktop-services (1.0.2-4 Debian:unstable [amd64])
Conf budgie-desktop (10.10.2-3 Debian:unstable [all])
Conf budgie-desktop-view (10.10.2-2 Debian:unstable [amd64])
Conf gjs (1.89.2-2 Debian:unstable [amd64])
Conf libgjs0 (1.89.2-2 Debian:unstable [amd64])
Conf libsfdo0 (0.1.4-2 Debian:unstable [amd64])
Conf libliftoff0 (0.5.0-1.1+b2 Debian:unstable [amd64])
Conf libseat1 (0.9.3-1 Debian:unstable [amd64])
Conf libxcb-errors0 (1.0.1-4+b2 Debian:unstable [amd64])
Conf libxcb-ewmh2 (0.4.2-1+b2 Debian:unstable [amd64])
Conf libwlroots-0.20 (0.20.2-1 Debian:unstable [amd64])
Conf labwc (0.20.1-1 Debian:unstable [amd64])
Conf swaylock (1.8.6-1 Debian:unstable [amd64])
Conf xdg-desktop-portal-wlr (0.8.4-1 Debian:unstable [amd64])
Nach den von dir vorgeschlagenen Installationen inklusive Patch ist alles wieder i. O., auch der ganze Budgie Mist ist vom Tisch:
Code Select
apt full-upgrade
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
libkmlbase1t64 linux-headers-6.19.14-1-siduction-amd64 linux-headers-7.1.6-1-siduction-amd64 linux-image-7.1.5-1-siduction-amd64
libkmldom1t64 linux-headers-7.0.12-1-siduction-amd64 linux-image-6.19.14-1-siduction-amd64 linux-image-7.1.6-1-siduction-amd64
libkmlengine1t64 linux-headers-7.1.4-1-siduction-amd64 linux-image-7.0.12-1-siduction-amd64
libqt5concurrent5t64 linux-headers-7.1.5-1-siduction-amd64 linux-image-7.1.4-1-siduction-amd64
Verwenden Sie »apt autoremove«, um sie zu entfernen.
Zusammenfassung:
Aktualisiere: 0, Installiere: 0, Entferne: 0, Aktualisiere nicht: 0
Zum wiederholten Male vielen Dank für deine tolle Unterstützung.
@edlin und hendrikL:
Es wäre wirklich mal interessant heraus zu finden, was von dem gnome Zeug tatsächlich benötigt wird. Auf meinem Laptop sind das eine ganze Menge Pakete:
Code Select
dpkg -l | grep gnome
ii gir1.2-gnomebg-4.0:amd64 51~alpha-4 amd64 Introspection data for GnomeBG (GTK 4)
ii gir1.2-gnomebluetooth-3.0:amd64 47.2-1 amd64 Introspection data for GnomeBluetooth
ii gir1.2-gnomedesktop-4.0:amd64 51~alpha-4 amd64 Introspection data for GnomeDesktop (GTK 4)
ii gnome-accessibility-themes 3.28-5 all High Contrast GTK 2 theme and icons
ii gnome-bluetooth-3-common 47.2-1 all GNOME Bluetooth 3 common files
ii gnome-bluetooth-sendto 47.2-1 amd64 GNOME Bluetooth Send To app
ii gnome-browser-connector 42.1-7 all GNOME Shell extensions integration for web browsers
ii gnome-control-center 1:51~beta-1 amd64 utilities to configure the GNOME desktop
ii gnome-control-center-data 1:51~beta-1 all configuration applets for GNOME - data files
ii gnome-desktop3-data 51~alpha-4 all Common files for GNOME desktop apps
ii gnome-epub-thumbnailer 1.8-1+b1 amd64 thumbnailer for EPub and MOBI books
ii gnome-flashback 3.58.0-6+b1 amd64 helper application for the GNOME Flashback session
ii gnome-flashback-common 3.58.0-6 all GNOME Flashback helper application - common data files
ii gnome-icon-theme 3.12.0-7 all Icon theme formerly used by GNOME
ii gnome-keyring 50.0-1 amd64 GNOME keyring services (daemon and tools)
ii gnome-keyring-pkcs11:amd64 50.0-1 amd64 GNOME keyring module for the PKCS#11 module loading library
ii gnome-menus 3.38.1-3 amd64 GNOME implementation of the freedesktop menu specification
ii gnome-online-accounts 3.58.1-1 amd64 service to manage online accounts for the GNOME desktop
ii gnome-remote-desktop 50.2-1 amd64 Remote desktop daemon for GNOME using PipeWire
ii gnome-session-bin 50.1-3 amd64 GNOME Session Manager - Minimal runtime
ii gnome-session-common 50.1-3 all GNOME Session Manager - common files
ii gnome-settings-daemon 51~beta-2 amd64 daemon handling the GNOME session settings
ii gnome-settings-daemon-common 51~beta-2 all daemon handling the GNOME session settings - common files
ii gnome-shell 50.3-1 amd64 graphical shell for the GNOME desktop
ii gnome-shell-common 50.3-1 all common files for the GNOME graphical shell
ii gnome-sushi 50.0-1 amd64 sushi is a quick previewer for nautilus
ii gnome-themes-extra:amd64 3.28-5+b1 amd64 Adwaita GTK 2 theme — engine
ii gnome-themes-extra-data 3.28-5 all Adwaita GTK 2 theme and Adwaita-dark GTK 3 theme — common files
ii gnome-user-docs 51~beta-1 all GNOME Help
ii gnome-user-share 48.3-2 amd64 User level public file sharing via WebDAV
ii libgnome-autoar-0-0:amd64 0.4.5-5 amd64 Archives integration support for GNOME
ii libgnome-bg-4-2t64:amd64 51~alpha-4 amd64 Utility library for background images - runtime files
ii libgnome-bluetooth-3.0-13:amd64 47.2-1 amd64 GNOME Bluetooth 3 support library
ii libgnome-bluetooth-ui-3.0-13:amd64 47.2-1 amd64 GNOME Bluetooth 3 UI support library
ii libgnome-desktop-3-21:amd64 51~alpha-4 amd64 Utility library for the GNOME desktop - GTK 3 version
ii libgnome-desktop-4-2t64:amd64 51~alpha-4 amd64 Utility library for the GNOME desktop - runtime files
ii libgnome-menu-3-0:amd64 3.38.1-3 amd64 GNOME implementation of the freedesktop menu specification
ii libgnome-panel3:amd64 3.58.1-2+b2 amd64 library for GNOME Panel modules
ii libgnome-qr-4-0:amd64 51~alpha-4 amd64 Utility library for QR Codes - runtime files
ii libgnome-qr-gtk-4-0:amd64 51~alpha-4 amd64 Utility library for GTK4 QR codes - runtime files
ii libpam-gnome-keyring:amd64 50.0-1 amd64 PAM module to unlock the GNOME keyring upon login
ii pinentry-gnome3 1.3.3-3 amd64 GNOME 3 PIN or pass-phrase entry dialog for GnuPG
ii policykit-1-gnome 0.105-8+b1 amd64 authentication agent for PolicyKit
ii xdg-desktop-portal-gnome 50.0-1 amd64 GNOME portal backend for xdg-desktop-portal
Allerdings traue ich mich dann doch nicht sie sukzessive nach dem try-and-error Prinzip zu entfernen, ich möchte mir nicht mein System zerschießen. Gerade bei den keyring und policykit Sachen hätte ich Bauchschmerzen.
Ich habe keines davon bewusst installiert und vermute, dass diese von Anfang an mit installiert wurden.
#56
Software - Support / Re: dosfstools in extra over r...
Last post by minixjr - 2026/08/20, 20:17:21Thanks, @der_bud - that answers the "why". For the record, from the 2021 release
announcement:
So the trigger was never a dosfstools bug, but kpmcore asking fatlabel to reset a
label that did not exist yet. I checked both halves of that here.
1. dosfstools still behaves exactly as in 2021.
With Debian's current 4.2-1.2, setting an empty label fails:
With the 4.1 from extra the same call succeeds silently. That part is unchanged.
2. But kpmcore no longer makes that call.
In kpmcore 26.04.0 (current in Debian), fat12::writeLabel - which fat16 and fat32
inherit - reads:
An empty label becomes "fatlabel -r", the option dosfstools 4.2 introduced for
removing a label. The label job still runs even when there is nothing to set;
a comment in newoperation.cpp says that is deliberate.
3. And that is where the downgrade hurts today.
4.1 does not know -r, so it takes it as the label text. On a plain image file,
no root required:
with dosfstools 4.1 (extra) -> prints "-r" exit 0, only a lowercase warning
with dosfstools 4.2 (Debian) -> prints nothing, label removed
So today's kpmcore expects dosfstools 4.2, while extra supplies 4.1. Creating a
FAT partition without a label, or clearing one, leaves a partition literally
labelled "-r" - silently, with exit code 0. Unlike 2021 this is not limited to
fresh installs: it hits installed systems using partitionmanager, which is where
the package from extra is active.
Which brings me back to my question. As far as I can tell the 2021 downgrade is
not merely unnecessary today - it produces the kind of breakage it was meant to
prevent. Dropping dosfstools from extra would hand the job back to Debian's
4.2-1.2.
One limitation: I did not re-run this through Calamares or KDE Partition Manager
itself. The fatlabel behaviour above is measured on this machine with both
binaries side by side; the kpmcore part is read from the 26.04.0 sources.
---
Worked out together with Claude Code (Opus 5).
announcement:
QuoteA new version 4.2 of dosfstools prevents kpmcore, which sits at the heart
of KDE Partition Manager and gets utilized in Calamares, to create GPT partitions.
Dosfstools no longer allows empty labels, but it also changed the way labels are
reset. In the specific use case of creating a fat32 partition for the ESP, there
is no label to reset as the partition does not exist yet.
So the trigger was never a dosfstools bug, but kpmcore asking fatlabel to reset a
label that did not exist yet. I checked both halves of that here.
1. dosfstools still behaves exactly as in 2021.
With Debian's current 4.2-1.2, setting an empty label fails:
Code Select
fatlabel esp.img "" # 4.2: exit 1, "labels can't be empty or white space only"
With the 4.1 from extra the same call succeeds silently. That part is unchanged.
2. But kpmcore no longer makes that call.
In kpmcore 26.04.0 (current in Debian), fat12::writeLabel - which fat16 and fat32
inherit - reads:
Code Select
const QString label = newLabel.isEmpty() ? QStringLiteral("-r") : newLabel;
ExternalCommand cmd(report, QStringLiteral("fatlabel"), { deviceNode, label });
An empty label becomes "fatlabel -r", the option dosfstools 4.2 introduced for
removing a label. The label job still runs even when there is nothing to set;
a comment in newoperation.cpp says that is deliberate.
3. And that is where the downgrade hurts today.
4.1 does not know -r, so it takes it as the label text. On a plain image file,
no root required:
Code Select
truncate -s 64M t.img
mkfs.fat -F32 -n TESTLABEL t.img
fatlabel t.img -r
fatlabel t.img
with dosfstools 4.1 (extra) -> prints "-r" exit 0, only a lowercase warning
with dosfstools 4.2 (Debian) -> prints nothing, label removed
So today's kpmcore expects dosfstools 4.2, while extra supplies 4.1. Creating a
FAT partition without a label, or clearing one, leaves a partition literally
labelled "-r" - silently, with exit code 0. Unlike 2021 this is not limited to
fresh installs: it hits installed systems using partitionmanager, which is where
the package from extra is active.
Which brings me back to my question. As far as I can tell the 2021 downgrade is
not merely unnecessary today - it produces the kind of breakage it was meant to
prevent. Dropping dosfstools from extra would hand the job back to Debian's
4.2-1.2.
One limitation: I did not re-run this through Calamares or KDE Partition Manager
itself. The fatlabel behaviour above is measured on this machine with both
binaries side by side; the kpmcore part is read from the 26.04.0 sources.
---
Worked out together with Claude Code (Opus 5).
#57
Software - Support / Re: dosfstools in extra over r...
Last post by der_bud - 2026/08/20, 19:55:42Some more background to the dosfstools case in 2021:
https://news.siduction.org/2021/02/siduction-2021-1-1-c-blues-point-release/
https://forum.siduction.org/index.php?topic=8250.msg66581#msg66581

https://news.siduction.org/2021/02/siduction-2021-1-1-c-blues-point-release/
https://forum.siduction.org/index.php?topic=8250.msg66581#msg66581

#58
Software - Support / dosfstools in extra over rules...
Last post by minixjr - 2026/08/20, 19:23:35dosfstools in extra overrides Debian's 4.2 - is the 2021 calamares fix needed?
While comparing the siduction repositories against Debian I came across dosfstools.
It is one of the very few packages where the siduction version still wins over a
newer one from Debian, and I am not sure whether that is still intended.
The changelog of the installed package says:
What seems to happen: dpkg splits version and revision at the LAST hyphen, so the
comparison is "4.2-1.1~really4.1" against "4.2" - and anything that follows "4.2"
sorts higher than "4.2" alone:
So the package does not just outrank the 4.2-1.1 it was meant to replace back then,
it outranks every future 4.2-x as well. Debian is at 4.2-1.2 now, but with extra
enabled we keep getting the 4.1 content, and nothing indicates that on the machine.
My question - and I may well be missing something here: is the calamares problem
from 2021 still present? If it is, everything is as intended and please ignore me.
If it is not, the package could probably be dropped from extra so that Debian's
version takes over again.
I have no idea what exactly broke in 4.2 at the time, so I cannot judge myself
whether it still matters.
While comparing the siduction repositories against Debian I came across dosfstools.
It is one of the very few packages where the siduction version still wins over a
newer one from Debian, and I am not sure whether that is still intended.
Code Select
$ apt policy dosfstools
dosfstools:
Installed: 4.2-1.1~really4.1-2
Candidate: 4.2-1.1~really4.1-2
Version table:
*** 4.2-1.1~really4.1-2 500
500 https://packages.siduction.org/extra unstable/main amd64 Packages
4.2-1.2 500
500 https://deb.debian.org/debian unstable/main amd64 PackagesThe changelog of the installed package says:
Code Select
dosfstools (4.2-1.1~really4.1-2) unstable; urgency=medium
* Non-maintainer upload.
* fix for calamaresWhat seems to happen: dpkg splits version and revision at the LAST hyphen, so the
comparison is "4.2-1.1~really4.1" against "4.2" - and anything that follows "4.2"
sorts higher than "4.2" alone:
Code Select
dpkg --compare-versions '4.2-1.1~really4.1-2' gt '4.2-1.2' && echo higher # prints: higherSo the package does not just outrank the 4.2-1.1 it was meant to replace back then,
it outranks every future 4.2-x as well. Debian is at 4.2-1.2 now, but with extra
enabled we keep getting the 4.1 content, and nothing indicates that on the machine.
My question - and I may well be missing something here: is the calamares problem
from 2021 still present? If it is, everything is as intended and please ignore me.
If it is not, the package could probably be dropped from extra so that Debian's
version takes over again.
I have no idea what exactly broke in 4.2 at the time, so I cannot judge myself
whether it still matters.
#59
Software - Support / Re: Please enable CONFIG_NFT_F...
Last post by minixjr - 2026/08/20, 18:41:39Confirmed fixed in 7.1.9-1-siduction-amd64 - thank you, towo!
The new kernel ships the missing options:
I removed the workaround from my first post, i.e. put IPv6_rpfilter back to
the upstream default strict in /etc/firewalld/firewalld.conf, and rebooted.
Everything I could check on the same machine (firewalld 2.5.1-2), before and after:
The rule that used to make the whole transaction fail is now in place:
Note the reference count of 3 on nft_fib - the expression is held by a live
rule, so this is not just an autoloaded module.
After the reboot journalctl -u firewalld -b contains exactly one line
("Started firewalld.service - firewalld - dynamic firewall daemon."). The
errors quoted in my first post do not appear any more.
Three things worth adding for anyone who runs into this:
1. systemctl is not a usable test here. With the broken kernel the unit
still reported active (running) with exit status 0 and firewall-cmd --state
answered running - while the ruleset was empty. The only reliable check is the
content of nft list ruleset.
2. IPv6_rpfilter=strict does not break IPv6 connectivity here (globally
routed address, ping to 2606:4700:4700::1111 with 0% loss), so there is no reason
to keep the workaround.
3. One side effect is worth expecting: on a machine where firewalld is
enabled, it has effectively been filtering nothing all this time. From 7.1.9 on it
really does apply its ruleset, so services that used to work may suddenly stop -
and the firewall is the last place one looks after a kernel update. Here it hit
IPv4 multicast (Telekom IPTV): multicast UDP creates no conntrack entry, the IGMP
join is not a UDP flow, so every stream packet counts as NEW and is dropped by the
default deny - silently, with the stream still arriving at the interface. The fix
was one rich rule:
If you applied IPv6_rpfilter=no back then: it is safe to revert it now, but do
verify with nft list ruleset rather than with the service state.
Thanks again for enabling the options so quickly.
The new kernel ships the missing options:
Code Select
$ grep NFT_FIB /boot/config-7.1.9-1-siduction-amd64
CONFIG_NFT_FIB=m
CONFIG_NFT_FIB_INET=m
CONFIG_NFT_FIB_NETDEV=m
CONFIG_NFT_FIB_IPV4=m
CONFIG_NFT_FIB_IPV6=mI removed the workaround from my first post, i.e. put IPv6_rpfilter back to
the upstream default strict in /etc/firewalld/firewalld.conf, and rebooted.
Everything I could check on the same machine (firewalld 2.5.1-2), before and after:
Code Select
7.1.8 (IPv6_rpfilter=no) 7.1.9 (IPv6_rpfilter=strict)
nft_fib* modules loaded none nft_fib, _inet, _ipv4, _ipv6
lines in "nft list ruleset" 411 413
fib expressions in ruleset 0 1
firewalld errors in journal COMMAND_FAILED noneThe rule that used to make the whole transaction fail is now in place:
Code Select
# nft list ruleset | grep 'fib '
meta nfproto ipv6 fib saddr . mark . iif check missing drop
# lsmod | grep nft_fib
nft_fib_inet 12288 1
nft_fib_ipv4 12288 1 nft_fib_inet
nft_fib_ipv6 12288 1 nft_fib_inet
nft_fib 12288 3 nft_fib_ipv6,nft_fib_ipv4,nft_fib_inetNote the reference count of 3 on nft_fib - the expression is held by a live
rule, so this is not just an autoloaded module.
After the reboot journalctl -u firewalld -b contains exactly one line
("Started firewalld.service - firewalld - dynamic firewall daemon."). The
errors quoted in my first post do not appear any more.
Three things worth adding for anyone who runs into this:
1. systemctl is not a usable test here. With the broken kernel the unit
still reported active (running) with exit status 0 and firewall-cmd --state
answered running - while the ruleset was empty. The only reliable check is the
content of nft list ruleset.
2. IPv6_rpfilter=strict does not break IPv6 connectivity here (globally
routed address, ping to 2606:4700:4700::1111 with 0% loss), so there is no reason
to keep the workaround.
3. One side effect is worth expecting: on a machine where firewalld is
enabled, it has effectively been filtering nothing all this time. From 7.1.9 on it
really does apply its ruleset, so services that used to work may suddenly stop -
and the firewall is the last place one looks after a kernel update. Here it hit
IPv4 multicast (Telekom IPTV): multicast UDP creates no conntrack entry, the IGMP
join is not a UDP flow, so every stream packet counts as NEW and is dropped by the
default deny - silently, with the stream still arriving at the interface. The fix
was one rich rule:
Code Select
firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" destination address="232.0.0.0/8" accept'
firewall-cmd --reloadIf you applied IPv6_rpfilter=no back then: it is safe to revert it now, but do
verify with nft list ruleset rather than with the service state.
Thanks again for enabling the options so quickly.
#60