1

Upgrade Warnings / libecm1

« Last post by finotti on 2026/02/05, 19:46:11 »

Something strange seems to be happening.  The packages libecm1 and libecm1-dev do not upgrade by default:

Code: [Select]

# apt dist-upgrade
Not upgrading:                 
  libecm1  libecm1-dev

Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 2

They are not held:

Code: [Select]

# apt-mark showhold



But they do not remove anything when installed...  (I meant to run "apt -s install libecm1 libecm1-dev", but I actually installed both, as I had tested before, but  forgot the "-s".  Oops...  )

Why was it being held back?   I was assuming it was the new solver preventing other packages to be removed, but it was not the case in this example.

Any ideas?

2

Upgrade Warnings / Re: F-U failed today on my laptop

« Last post by scholle1 on 2026/02/05, 13:03:18 »

ENGLISH  (deutsch weiter unten)

A solution if booting into the standard subvolume after a DU is no longer possible, even in emergency.target.
Btrfs file system; in this state, no rollback with snapper is possible.

Starting point for this example.
The paths must be adapted to your own circumstances.

• siduction installation with configured snapper and the siduction-btrfs package installed.
• The defective standard snapshot has the number 1716
• The snapshot used for recovery has the number 1712
• Determine the kernels present in snapshot 1712. (e.g., 6.18.6-1-siduction-amd64)
• Reminder: For Btrfs, snapshots are also subvolumes!

The solution.

• Boot the siduction live system from a USB stick,
  start the chroot helper on the affected hard drive/partition.
  Execute the following commands.
  
  btrfs sub li /
  The output is a list of the existing subvolumes for /.
  We are interested in the lines with
  [...] path @snspshots/1712/snapshot
  [...] path @snspshots/1716/snapshot
  
  btrfs sub snapshot /.snapshots/1712/snapshot /.snapshots/rescue
  This creates a snapshot with the path /@snapshots/rescue from subvolume no. 1712.
  Exit chroot and reboot.
• When the GRUB menu appears, press the "E" key. Then change the kernel and initrd lines.
  
  linux   /@snapshots/rescue/boot/vmlinuz-6.18.6-1-siduction-amd64 [...] rootflags=subvol=@snapshots/rescue [...]
  initrd  /@snapshots/rescue/boot/initrd.img-6.18.6-1-siduction-amd64
  The changed parts are highlighted in bold and underlined.
  
  Boot with F10. We are now in the rescue subvolume.
  Start a terminal and become root.
  The command
  
  btrfs sub li /
  now also shows us a subvolume with the path @snapshots/rescue, and
  the command
  
  snapper list
  shows a + instead of the usual * for snapshot 1716.
  This means that we are not in this snapshot, but it is still the default subvolume.
  Snapper does not recognize the subvolume @snapshots/rescue.
  We clean up the situation by performing another rollback with snapper.
  
  snapper -a classic rollback 1712
  Now continuity is ensured in snapper and we can leave the rescue subvolume with a reboot.
• Now that we have arrived at the new snapshot 1718, we should clean up.
  First, check the output in the root terminal:
  
  btrfs sub li /
  snapper list
  Both outputs show the additional snapshots 1717 and 1718.
  In snapper, there is a * next to 1718.
  Btrfs contains the subvolume with the path @snapshots/rescue. We dispose of it with
  
  btrfs sub delete /.snapshots/rescue
  The system is now clean again and, after extensive testing, any snapshots that are no longer needed should be removed.
  

I hope there are no typos in the commands. Good luck.

DEUTSCH

Ein Lösungsweg wenn booten in das Standardsubvolumen nach einem DU auch im emergency.target nicht mehr möglich ist.
Btrfs Dateisystem, in diesem Zustand kein Rollback mit snapper möglich.

Ausgangslage für dieses Beispiel.
Die Pfade müssen an die eigenen Gegebenheiten angepasst werden.

• siduction Installation mit konfiguriertem snapper und dem installierten Paket siduction-btrfs.
• Der defekte standard Snapshot hat die Nummer 1716
• Der Snapshot, der für die Wiederherstellung benutzt wird, hat die Nummer 1712
• Die im Snapshot 1712 vorhandenen Kernel ermitteln. (z.B. 6.18.6-1-siduction-amd64)
• Zur Erinnerung: Für Btrfs sind Snapshots genauso Subvolumen!

Der Lösungsweg.

• siduction live System vom USB Stick booten,
  den Chroot Helfer in die betroffene Festplatte/Partition starten.
  Folgende Kommandos ausführen.
   
  btrfs sub li /
  Ausgabe ist eine Lister der vorhandenen Subvolumen für /
  Für uns von Interesse sind die Zeilen mit
  [...] path @snspshots/1712/snapshot
  [...] path @snspshots/1716/snapshot
  
  btrfs sub snapshot /.snapshots/1712/snapshot /.snapshots/rescue
  Das erstellt einen snapshot mit dem Pfad /@snapshots/rescue vom Subvolumen Nr. 1712.
  Chroot verlassen und reboot.
• Wenn das GRUB Menü erscheint, die Taste "E" drücken. Dann die Kernel und initrd Zeilen ändern.
  
  linux   /@snapshots/rescue/boot/vmlinuz-6.18.6-1-siduction-amd64 [...] rootflags=subvol=@snapshots/rescue [...]
  initrd  /@snapshots/rescue/boot/initrd.img-6.18.6-1-siduction-amd64
  Die geänderten Teile sind fett und unterstrichen hervorgehoben.
  
  Mit F10 booten. Wir befinden uns im rescue Subvolumen.
• Ein Terminal starten und zu root werden.
  Der Befehl
  
  btrfs sub li /
  zeigt uns jetzt auch ein Subvolumen mit dem Pfad @snapshots/rescue und
  der Befehl
  
  snapper list
  zeigt beim Snapshot 1716 ein + statt des üblichen *.
  Das bedeutet, dass wir uns nicht in diesem Snapshot befinden, er aber nach wie vor das Standardsubvolumen ist.
  Snapper kennt das Subvolumen @snapshots/rescue nicht.
  Wir bereinigen die Situation, indem wir noch einmal einen Rollback mit snapper ausführen.
  
  snapper -a classic rollback 1712
  Jetzt ist die Kontinuität in snapper gegeben und wir können das rescue Subvolumen mit einem reboot velrassen.
• Im neuem Snapshot 1718 angekommen, sollten wir noch aufräumen.
  Zuerst im root Terminal die Ausgaben zur Kontrolle:
  
  btrfs sub li /
  snapper list
  Beide Ausgaben zeigen die zusätzlichen Snpshots 1717 und 1718.
  Bei snapper steht neben 1718 ein *.
  Btrfs enthält das Subvolumen mit dem Pfad @snapshots/rescue. Wir entsorgen es mit
  
  btrfs sub delete /.snapshots/rescue
  Jetzt ist das System soweit wieder sauber und nach ausführlichen Tests sollten nicht mehr benötigte Shnapshots entfernt werden.
  

Ich hoffe mir sind in den Kommandos keine Tippfehler unterlaufen. Gutes gelingen.

3

Upgrade Warnings / Re: F-U failed today on my laptop

« Last post by scholle1 on 2026/02/05, 11:03:29 »

d.) Do I have to do

If so, press the E key when the GRUB menu appears and add “ 1” to the kernel line.

on my failing current default? And collecting snapper list from there?

No, misunderstanding on my part regarding your terminal output.
If decryption fails with the subvolume in question, the hint is of no use.
I tested a solution on my laptop, but without an encrypted hard drive.
Next post.

4

Upgrade Warnings / Re: F-U failed today on my laptop

« Last post by micspabo on 2026/02/04, 22:22:04 »

Is Point 3b from <https://forum.siduction.org/index.php?topic=8832.msg70588#msg70588> already possible three years after that post?

No.
You need an r/w snapshot of the working subvolume.
Please take a look at
https://forum.siduction.org/index.php?topic=9305.msg78552#msg78552

Q: Is the GRUB menu visible, and does the system journal show this line?

Reached target local-fs.target

If so, press the E key when the GRUB menu appears and add “ 1” to the kernel line.
This is how you boot into emergency.targe whithout network connection, so the error shown above cannot occur.

Display the list of snapshots and perform a rollback.

Code: [Select]

snapper list
snapper -a classic rollback <nr>

a.) OK,- Point 3b is not possible. Thanks!

b.) What I read from your given link is that I expect I have to boot from a Siduction usb stick and prepare a "chroot" environment to proceed. Not sure what I have to do in there yet.

c.) When I do a fresh boot I am able to enter the passphrase for

Code: [Select]

Enter passphrase for hd1,gpt2 (xxx):
then I see the GRUB menu.
When I select the first entry to boot into "current default subvolume", the system get stuck and I cannot check journalctl,- I can only take a picture with my phone.
But I can successfully boot into submenu "siduction snapshots" and boot and login into snapshot number 1712, which I'd like to make the current default somehow. And I can successfully boot into my second OS, where I now writing from.

d.) Do I have to do

If so, press the E key when the GRUB menu appears and add “ 1” to the kernel line.

on my failing current default? And collecting snapper list from there?

5

Upgrade Warnings / Re: F-U failed today on my laptop

« Last post by scholle1 on 2026/02/04, 15:02:10 »

Is Point 3b from <https://forum.siduction.org/index.php?topic=8832.msg70588#msg70588> already possible three years after that post?

No.
You need an r/w snapshot of the working subvolume.
Please take a look at
https://forum.siduction.org/index.php?topic=9305.msg78552#msg78552

Q: Is the GRUB menu visible, and does the system journal show this line?

Reached target local-fs.target

If so, press the E key when the GRUB menu appears and add “ 1” to the kernel line.
This is how you boot into emergency.targe whithout network connection, so the error shown above cannot occur.

Display the list of snapshots and perform a rollback.

Code: [Select]

snapper list
snapper -a classic rollback <nr>

6

Upgrade Warnings / Re: Nutzung des 'solvers' ...

« Last post by michaa7 on 2026/02/04, 10:21:01 »

...
Today it’s recommended to use plain apt full-upgrade and only consider solver 3.0 as a last-resort debugging tool, not for routine upgrades.

That's nonsense. There is no solver 3.0 last-resort debugging tool. solver 3.0 IS THE DEFAULT setting since apt 3.1 .

7

Upgrade Warnings / Re: Nutzung des 'solvers' ...

« Last post by riptidescorecard on 2026/02/04, 04:32:11 »

Solver 3.0 used to be very helpful in the past, especially with older apt versions.
However, current apt releases have a much improved default resolver, making --solver 3.0 unnecessary in most cases.
Today it’s recommended to use plain apt full-upgrade and only consider solver 3.0 as a last-resort debugging tool, not for routine upgrades.

8

Software - Support / Re: Kein Rootzugriff mehr nach chroot

« Last post by ro_sid on 2026/02/03, 18:01:21 »

Zu 1.: Datei entfernen - Platzverbrauch! Ist denn noch genügend freier "Plattenspeicher" frei? Sonst scheitert alles sowieso daran. Ferner der Hinweis, daß mit dem 'dbus' was nicht stimmt. Das wäre kritisch, wenn es sich nicht nur auf "Cups" bezieht.

Zu 2.: Man kann Linux in einen "Single user/Recovery"-Modus booten. Grub bietet das unter "Advanced" an. Der endet mit der Aufforderung das "root"-Paßwort einzugeben, danach kann man "einiges machen" - wenn's klappt. So etwa Updates/Upgrades sofern das Dateisystem unversehrt ist und man das Netzwerk zum Laufen bringt.

Zu 3.: Auch "vom Stick" gebootet kann das ein (Platten-)Speicherplatz-Problem sein, denn "chroot" wechselt ja auf System-'/' zum Updaten/Upgraden.

Frage: Ist es ein "ext"-Dateisystem oder ein "btrfs"? Bei "ext" im Single-user-Modus einen Filesystemcheck ('fsck') ausführen.

Für mich sieht es nach "voller Platte" oder einem Dateisystemfehler aus. Letzterer sollte in einem "Journalling Filesystem" wie "ext4" nicht mehr (kritisch) vorkommen.
[Auch "update" und "upgrade" setzen die Unversehrtheit bestimmter Dateien im Dateisystem voraus, sonst scheitern sie.]

Viel Erfolg!

9

Upgrade Warnings / Re: F-U failed today on my laptop

« Last post by micspabo on 2026/02/03, 12:25:32 »

Looks like I have to do my first desaster-rollback.
I identified the working snapshot number by booting into it, but I am not able to reboot back to the current default subvolume
because that gets stuck at

Code: [Select]

[ OK ] reached target remote-fs-pre.target - Preparation for Remote File System.
[ OK ] reached target remote-cryptsetup.target - Remote Encrypted Volumes.
[ OK ] reached target remote-fs.target - Remote File System.
[ ** ] Job dev-mapper-luks\x2d400d59ef\x2d905b\x2d47cd\x2d9d2b\x2daa1ccf74c098.device/start running (Xmin Ys / no limit)

As I am not able to boot into the current default subvolume,
how should I do the rollback in that case?

Is Point 3b from <https://forum.siduction.org/index.php?topic=8832.msg70588#msg70588> already possible three years after that post?

Code: [Select]

# dpkg -l | grep ii | grep siduction-btrfs
  ii  siduction-btrfs  0.4.0-1  all  Optimizes the boot menu and the description in Snapper


10

Software - Support / Re: Kein Rootzugriff mehr nach chroot

« Last post by Lanzi on 2026/02/02, 22:43:49 »

Zusatz; Die Fehlermeldung zu fuse ist weg.

cups lässt sich auf konsole als user mit systemctl stop cups beenden, staret aber nach unbestimmter Zeit neu