Rust Coreutils Are Coming to Your Server 🦀

Ubuntu 26.10 completes a migration that started two releases ago: the GNU coreutils are replaced by uutils, a reimplementation in Rust. The last three holdouts — cp, mv and rm — were kept on their GNU versions in 26.04 LTS while a set of TOCTOU issues were fixed upstream. Those fixes landed, so 26.10 finishes the job.

If you run your own Linux server, this is the sort of change that is easy to wave past. The stated user impact is none: uutils aims for drop-in compatibility with GNU and treats any deviation as a bug. That is a real commitment and a good one.

It is also a claim about the common path.

What "drop-in" does and does not promise

Drop-in compatibility means the flags you use behave the way you expect, the output looks the same, and the exit codes match. For ls -la, cat, chmod, du, that is almost the whole story and you will genuinely never notice.

What it does not promise is that every behaviour some script somewhere depends on is specified behaviour. Shell scripts accumulate dependencies on things nobody documented:

• Exact stderr wording. Anything doing 2>&1 | grep 'No such file' is matching on a string that was never an interface.
• Ordering that was incidental. ls without --sort in a pipeline, or glob expansion order assumed to be stable.
• Flag combinations nobody tests. cp --reflink=auto --sparse=always on a filesystem that supports neither.
• The behaviour of a flag that does not exist. GNU-specific extensions used in a script that then runs on a system where the implementation differs.

None of these are failures of uutils. They are the ordinary cost of replacing an implementation that has been the reference for thirty years, and they land on whoever wrote the script.

The three that matter most are the three that were held back

It is not a coincidence that cp, mv and rm were the last to switch. They are the ones that touch your data destructively, and they were held back precisely because of time-of-check-to-time-of-use problems — the class of bug where a path is validated and then acted on, and something changes in between.

That is a good reason to have waited, and a good reason to pay attention now. These three are also the ones your backup scripts, your deploy scripts and your log rotation lean on hardest.

What to actually test, in about fifteen minutes

Do not audit every script. Run the ones that matter against the new binaries and diff the result.

# What implementation am I on?
cp --version | head -1        # "uutils coreutils" vs "cp (GNU coreutils)"
 
# Does my script's exact invocation still behave?
#   Run it against a scratch tree, not production.
mkdir -p /tmp/ct/{src,dst}
printf 'x' > /tmp/ct/src/file
ln -s file /tmp/ct/src/link
cp -a /tmp/ct/src/. /tmp/ct/dst/ && ls -la /tmp/ct/dst

Three specific things worth checking on a server you actually run:

1. Your backup or sync path. Anything using cp -a, --preserve, hardlinks, or sparse files. Verify permissions, ownership, symlinks and timestamps survive — not just that the files arrived.
2. Anything parsing output. grep your scripts for cp , mv , rm , ls followed by a pipe. Each one is a place where you depend on output format. Prefer exit codes and find -print0 over parsing.
3. Your error paths. Deliberately fail the operation — target read-only, source missing, disk full — and confirm your script still detects it. Exit-code contracts are the part most likely to be right, and the part your script most likely ignores in favour of string matching.

The upgrade discipline this rewards

Ubuntu 26.10 is an interim release: supported for nine months, not five years. If you run production on it, you have already accepted a faster cadence. If you run the LTS, you have until the next one to find your own breakage — and the interim release is exactly the place to find it, on a machine that is not serving anyone.

Which is the real recommendation. Not "audit your scripts" — nobody does that — but "run your deploy and backup scripts once, on 26.10, on a throwaway box, before the LTS makes it your problem."

The memory-safety argument for this migration is sound and the compatibility work has clearly been serious. Both of those can be true while your particular fifteen-year-old backup script is the exception. Fifteen minutes on a scratch VM tells you which.

Sources: OMG! Ubuntu · It's FOSS