SystemRescue 12 lands with added bcachefs support

You might need that – the file system has some hard-to-squish bugs

A new version of the handy all-in-one bootable system toolkit distro is here, now with a whole new file system for you to play with.

Version 12.0 of SystemRescue, one of the more useful tools when faced with a balky PC, is a bit bigger than it was in 2022, with the ISO image now a little over 1 GB, but then again, most of us are.

A few years ago, we looked at SystemRescue twice, first when version 9 came out, which added in-kernel NTFS support, and again about a year later, when it gained RAM testing for UEFI machines. The recovery tools in this version are still largely the same as they were in 2022. The main changes in versions 10 and 11 were mainly to update the Linux kernel to new LTS versions.

System Rescue 12 has a lot of helpful tools – and bcachefs support too – click to enlarge

Now version 12 moves to kernel 6.12, which became the latest LTS kernel at the end of 2024. This brings a significant change, though. The LTS kernel includes support for the new bcachefs file system, which first appeared in kernel 6.7 in January that year.

Although various tools have been updated, SystemRescue 12 is otherwise largely the same toolkit as before. As well as hardware diagnostics and other utilities, it has both text-mode and graphical partitioning tools. It can copy disks or partitions, as well as make or restore images of them. It includes the little-known but very useful dd_rescue, which can copy defective, damaged or dying disks. dd_rescue can't work miracles, but it can save your day. It works like the classic Unix dd command, performing block-level duplication of one drive to another. The difference is that when dd hits an error, it stops running – but dd_rescue keeps going. So if you have some bad blocks on a drive, dd_rescue lets you copy all the good, working blocks onto another drive – then you can try to recover any files that are still intact from your copy, without working a possibly dying drive even harder.

The SystemRescue website has a list of tools included, as well as a list of the versions. This includes the bcachefs-tools package, which was present last time around as well – but is rather more useful now with a kernel that has built-in bcachefs support.

We did hit some problems booting it from a Ventoy multi-ISO USB key on some of our test fleet of geriatric ThinkPads. There was an issue between SystemRescue 11 and Ventoy, and this may be related. The SystemRescue website mentions Ventoy, so it ought to work.

However, Ventoy's option to load the ISO into RAM before booting worked fine. SystemRescue itself has a boot menu with safe graphics modes, including its own option to load into and run from RAM, but it failed to get that far unless we used Ventoy's built-in equivalent.

SystemRescue includes most of the things a BOFH might need when poking at a poorly PC. What's handy is that they're all in one place, in a one-gig distro – small enough to boot into RAM and still have a useful amount of working space left, even on a PC with just eight gigs of RAM.

Bootnote: bcachefs bug bashing

Speaking of the fancy new file system, as we reported in November, bcachefs developer Kent Overstreet sat out the release of kernel 6.13 on the naughty step. That means no changes in his file system since kernel 6.12.

That in turn means some bigger changes are coming in the under-construction kernel 6.14. The first patch to this release meant an on-disk format change, but this also means much faster repair operations:

fsck time on large file systems is improved by multiple orders of magnitude. Previously, 100 TB was about the practical max file system size, where users were reporting fsck times of a day+. With the new changes (which nearly eliminate backpointers fsck overhead), we fsck'd a file system with 10 PB of data in 1.5 hours.

However, one upgrader reported an unexpected error, and now the team is trying to find why before kernel 6.14 is released in about a week's time. The comments in the latest patch explain a bit more:

We just had a report of the assert for "btree in write buffer for non-write buffer btree" popping during the 6.14 upgrade.

What caused it is still being investigated. If this causes a delay in the kernel release cycle, we rather suspect that Mr Torvalds will not be a happy bunny penguin. ®