[EN] [Solved] F-U failed today on my laptop

[micspabo]

Sorry - it failed, as after reboot systemd-cryptsetup was not able to decrypt root.  :'(
So be warned to follow that path too easily like me.

[terroreek]

Using my steps and rebooting my setup decrypted fine, not sure if I am using systemd-cryptsetup.

This is maybe a 2-3 year old install on my laptop.

Follow up, yes I am using systemd-cryptsetup to encrypt my laptop.

[campitosai]

I was able to work around it by downgrading busybox, by

Code: [Select]

dpkg -i /var/cache/apt/archives/busybox_1%3a1.37.0-7_amd64.debthen this command to finish all the failed upgrade

Code: [Select]

apt -f install
Worked for me.

Worked for me too.

Didn't find busybox_1.37.0-7_amd64.deb in /var/cache/apt/archives/ so :

Code: [Select]

wget http://ftp.debian.org/debian/pool/main/b/busybox/busybox_1.37.0-7_amd64.deb

Thank's

[n4ai9i522]

wow what a roll, confirm previous busybox was not in apt cache anymore nor in sid repos but the above post saved my day better than gemini could have, then I did

sudo apt-mark hold busybox

I like this particular community of nerds!

[T-ampfer]

I had the same problem last night, after a

Code: [Select]

apt purge cryptsetup-initramfs
the problem was solved. Please use it only if dosen't use cryptsetup.


Ich hatte letzte Nacht das selbe Problem, nach einem

Code: [Select]

apt purge cryptsetup-initramfs
war das Problem gelöst. Bitte nur anwenden wenn du cryptsetup nicht benutzt.

[dibl]

Sorry - it failed, as after reboot systemd-cryptsetup was not able to decrypt root.  ....

So

Code: [Select]

$ sudo apt depends cryptsetup-initramfs
cryptsetup-initramfs
 |Depends: busybox
.........
You can simply change your debian repo from unstable to stable, then

Code: [Select]

apt remove busybox cryptsetup-initramfs
apt update
apt install cryptsetup-initramfs (which should pull in busybox as a depedency)

Confirm it is all OK

Code: [Select]

dpkg --configure -a
Don't forget to change the debian repo back to unstable.

You can pin it like @n4ai9i522 says, or just wait until they fix the bug before doing a full-upgrade.

[eriefisher]

Looks like busybox has been fixed and there is a new version in the repos. If not it will be soon.

[alexsid]

Looks like busybox has been fixed and there is a new version in the repos. If not it will be soon.

Thanks for the update! I checked, it was updated, everything went smoothly. This glitch was fixed. 

[micspabo]

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


[scholle1]

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>

[micspabo]

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?

[scholle1]

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.

[scholle1]

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.

[micspabo]

ENGLISH  (deutsch weiter unten)

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

DEUTSCH

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

Thank you very much for all the details.

With a bit of more time I will try the emergency.target or the kernel parameter

Code: [Select]

systemd.unit=rescue.target
to see if I can get my fingers into the standard subvolume to execute a rollback from there.

Next autumn I would probably have a little more time to delve into the depths of btrfs – as my retirement is just around the corner.