For su or sudo to work, the rootfs has to be mounted suid -- which is obvious when you know how it work or think about it. sudo is nice enough to hint us at it, but sud isn't.

Either way, when chrooting you need to make sure the partition holding your new root is not mounter nosuid. Any user-mounted partition usually is (for fairly obvious security reasons I guess), so if you're plugging in a drive, make sure you mount it manually or remount it mount -o remount,suid.
Then, su and sudo should work fine in the chroot (at least if you mounted all the bits like /proc, /sys, /dev, /dev/pts and al.).

Beware of shady stuff though, obviously.

I just had to try and recover a couple files that a buggy program replaced with empty files instead of their actually updated content. Context is an EXT4 FS, on a secondary data partition (and even disk, but that's unrelated).

Linked post is interesting, but a bit over-doing it: no need to actually back the journal up in my case (tho I did it), nor unmount the partition to use either tool.

Additionally the linked article talks about deleted files, whereas here I wanted to recover previous versions of the content of existing files. I guess this requires the program not having rewritten the same blocks, but in my case the program both writes to a temp file first and then renames over (although it happily replaced with an empty file), and wrote a 0-bytes file which likely wouldn't overwrite anything. Anyway, for this use case, the key is the -b option to give it a time frame that does not include the faulty rename.

So, basically what I did:

• Remount the partition read-only to avoid any additional writes that could corrupt the data blocks: `sudo mount /dev/sdb1 -o remount,ro
• Backup the EXT4 journal just in case (but I highly doubt that was of any use, I could have used the actual FS's journal): sudo debugfs -R "dump <8> $HOME/sdb1.journal" /dev/sdb1
• Trial version listing potential recoveries: sudo ext4magic /dev/sdb1 -a $(date -d "-2hours" +%s) -b $(date -d "-45minutes" +%s) -f relative/path/to/files/ -j ~/sdb1.journal -l
• Actual recovery: sudo ext4magic /dev/sdb1 -a $(date -d "-2hours" +%s) -b $(date -d "-45minutes" +%s) -f relative/path/to/files/ -j ~/sdb1.journal -r -d RECOVERY/

At this point I had the files in their state from 45 minutes ago, validated the recovery and remounted read-write. Done.

This was surprisingly easy, thanks to journaling FS :)
To be fair, having the lost data outside the root or home FSes helped a lot, not only because of random applications potentially writing stuff if any mutable data is stored there (/home, /var/run, /tmp and whatnot), but I could also easily install the tools I missed straight away without risks of overwriting precious data blocks.

Après une réinstallation fraîche d'une Debian Bookworm et réutilisation du /home d'une Bookworm mais celle-ci mise à jour depuis un installation initiale de 2017, j'ai perdu mes keyrings.
En fait, le chemin a changé : il ne sont plus stockés dans ~/.gnome2/keyrings/ mais dans ~/.local/share/keyrings/. Solution : arrêt du service gnome-keyring-daemon (moi j'ai simplement déloggué et pris un TTY), restauration de ~/.local/share/keyrings/ vers ~/.gnome2/keyrings/, et c'est reparti.

Je n'ai par contre pas encore étudie ce qui définit ce chemin et pourquoi il n'est plus identique alors qu'à priori l'ensemble du /home a été restauré. Peut-être pour un futur édit.