There are reports in Ubuntu of checkinstall "bricking" the system:

https://bugs.launchpad.net/ubuntu/+source/checkinstall/+bug/1847582
https://www.reddit.com/r/Ubuntu/comments/x08ex6/psa_checkinstall_can_brick_your_ubuntu_2204_system/

Debian has a variety of patches, but there is not a patch that I can see
for this issue.

There are also issues with checkinstall that prevent it from properly
functioning in some cases (requiring --fstrans=no).

I noticed these while trying to build:
https://mirror.team-cymru.com/gnu/gnats/gnats-4.1.0.tar.gz

This is concerning in no small part as the Debian wiki recommends use of
checkinstall:

https://wiki.debian.org/DontBreakDebian#checkinstall_is_a_better_option

From 2012 until November 2023 Ubuntu shipped a checkinstall that
disabled file system translation by default:
https://launchpad.net/ubuntu/+source/checkinstall/+publishinghistory

These reports seem to be related to that Ubuntu-only change?

cu
Adrian

I think there are two true bugs related to those reports, neither of them being the Ubuntu default.

The first is that various things cannot build without --fstrans=no (because the translation does not seem to work for what seem to be some pretty simple shell scripts).

The second is that --fstrans=no is DANGEROUS in its current implementation. Even if you're using --fstrans=no I think users should be able to assume that an interrupt should finish the restore to the prior file system state. This is not people being bit by a build that does something nasty, this is the tool breaking their system because they sent a SIGINT to it.

We're not talking about SIGKILL here, checkinstall should clean up after itself gracefully.

- Wyatt

From what i can see the defaults in debian do not break the system and i
think just using --fstrans=no itself doesn't either (with a very simple
test script for installation, maybe if the backup code triggers it might be
worse).

Do we have a concrete example of an invocation that breaks the system with
the version in trixie?

Of course checkinstall is from a time where doing all this safely was much
harder than it would be today with namespaces and overlay fs.
But do the current limitations make it useless?

 - Martin

A user ended up with the /lib symlink replaced by a real directory, which
didn’t help their system work correctly...

I don’t know exactly which version was involved, but I don’t see any relevant
changes in the last few years.

Regards,

Stephen

We believe that the bug you reported is fixed in the latest version of
checkinstall, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1107638@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Stephen Gelman <ssgelm@debian.org> (supplier of updated checkinstall package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 06 Aug 2026 17:10:56 -0500
Source: checkinstall
Architecture: source
Version: 1.6.2+git20170426.d24a630-6
Distribution: unstable
Urgency: medium
Maintainer: Stephen Gelman <ssgelm@debian.org>
Changed-By: Stephen Gelman <ssgelm@debian.org>
Closes: 785441 892985 1033483 1051180 1085196 1107638 1116590
Changes:
 checkinstall (1.6.2+git20170426.d24a630-6) unstable; urgency=medium
 .
   * Bump standards version to 4.7.4
   * Add loong64 support (Closes: #1085196)
     Thanks wuruilong for the patch! loongarch64 has no __xstat() to
     intercept, so the patch wraps stat(), lstat(), fstatat() and mknod()
     directly.
   * Make filesystem translation work against a current glibc, which covers
     most of what has been reported over the years as --fstrans=yes being
     broken (Closes: #1051180, #1116590):
     - Intercept the stat family through the symbols glibc exports. glibc 2.33
       turned stat(), lstat(), fstatat() and mknod() into ordinary functions,
       so a library defining only __xstat() no longer sees the stat calls that
       binaries in the archive make, and every tool that stats a path before
       acting on it was told the file did not exist. The loong64 wrappers
       above are needed here too, so the condition guarding them is the glibc
       version rather than the architecture.
     - Intercept statx()
     - Perform linkat() on the translated paths. It linked the paths it was
       given, so the hard link was made against the real filesystem even with
       --fstrans=yes
     - Intercept __open_2(), __openat_2() and their LFS64 spellings, which
       _FORTIFY_SOURCE substitutes for open() and openat()
     - Intercept the mkstemp family, which opens its file through an internal
       call the open() wrapper never sees
   * Stop backups from destroying symlinked directories such as /lib on
     merged-/usr systems (Closes: #1107638):
     - Resolve symlinks in the parent directories of a path before mirroring
       it into installwatch's backup tree, so restoring that tree over / can
       no longer replace a symlink with a real directory
     - Don't back up files on a read-only access() call
     - Pass --keep-directory-symlink to tar when restoring a backup, as a
       safety net
   * Record installed files under their real parent directories, so that a
     package built from an install writing to e.g. /lib/systemd/system ships
     /usr/lib/systemd/system and drops the aliased paths
   * Take option values as given rather than re-evaluating them through the
     shell. Values holding shell metacharacters, such as
     --maintainer="Jane Doe <jane@example.org>" and
     --requires="libc6 (>= 2.28)", now reach the package intact where they
     used to be dropped without a word (Closes: #785441)
   * Keep installed files whose path merely contains the name of the build
     directory. The check that finds them anchors its pattern, the one that
     dropped them did not, so building in /myapp also excluded
     /usr/include/myapp from the package (Closes: #1033483)
   * Fix the ld.so.conf guard in the postinstall script written for
     --addso=yes. It used "&>", which /bin/sh reads as a background command
     plus a stray redirection, so the guard never held and the library
     directory was appended again on every install (Closes: #892985)
   * Look for the shared libraries under the build directory when --addso=yes
     is given. checkinstall asked file(1) about their final absolute path,
     where filesystem translation leaves nothing, so it recognised no
     libraries and wrote no postinstall script
   * Drop "install -o root -g root" from the upstream install target. It fails
     under dpkg 1.22.13 and later, where a package that leaves
     Rules-Requires-Root unset runs its binary targets without (fake)root
Checksums-Sha1:
 63d044cf91bd669b4bbb399c050438b810c55575 2208 checkinstall_1.6.2+git20170426.d24a630-6.dsc
 ec61c95eb8a0147114bb85f1f293b8c1c19de218 31388 checkinstall_1.6.2+git20170426.d24a630-6.debian.tar.xz
 899c93723bf25df46fbd6aea839c687d70c69a0b 6980 checkinstall_1.6.2+git20170426.d24a630-6_amd64.buildinfo
Checksums-Sha256:
 f2320afdb59f316d0052255ac95d63849d0e0eef35477aaad84798215b232a8f 2208 checkinstall_1.6.2+git20170426.d24a630-6.dsc
 e20c33f67fc951dbc470abdb75474b119d2b0b11cc5ce5ab842174574f965b8c 31388 checkinstall_1.6.2+git20170426.d24a630-6.debian.tar.xz
 a7ec26582a569932417d44ab0f0e52f6aaf0e318a9d5a41b4c6e45f201c64704 6980 checkinstall_1.6.2+git20170426.d24a630-6_amd64.buildinfo
Files:
 1f9888ed4840024f6054b47e6403ff91 2208 admin optional checkinstall_1.6.2+git20170426.d24a630-6.dsc
 0dd7a615738d5ee98abf0d1b6a5328a1 31388 admin optional checkinstall_1.6.2+git20170426.d24a630-6.debian.tar.xz
 5518ab2143351693f8991518067f94d1 6980 admin optional checkinstall_1.6.2+git20170426.d24a630-6_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJGBAEBCgAwFiEEC77u8GTpSr6EMli0dUHPqvw16s8FAmp1CoUSHHNzZ2VsbUBk
ZWJpYW4ub3JnAAoJEHVBz6r8NerPQSoQAJrzZrQ2bOeAHAjWV+d6bHxeejE3zk7X
BT8ODGkl9b0dv0V1fhJeA4wUgpha7jbS3PEnCwYdsPit+NzhYHbYDQ+eDDvGNjPJ
yCpOzdNgExRo9Zrgzx0k3A3w2GVymsEMXEYKqdL7Afts+ODFx7EDoh4dLm956t3f
E2HVD93qsiDwaZlStFhHPKzr6lU1RHQeEfThAGpBQSPASSsx9PbJ25gTkesbZB+l
xj3LoNMmrm9mR0ik73lgaYhqK+sf3/ioAM1p/+X7bQtNp36DEeEwllpHEcO7Vri3
284qcm0VaVJaZi7/Ix4pPqo8b7dgyZuQHQc4uzc1PxLv+rssF0NO35UYKJ0eugtC
lFpDv33D2yqc2m8sUT300DPMb3Z/d1jMeix1cmyYgYcYyiLbRtG20/sPxedo5uDn
gLPorLvxkS5bZfnoJWj6C7pJo+oowH3L/oKOw/eSjVj8Tzh9Jbn28Gw/YWAZkbEY
5lHBFUq6wMtvSnJdFwk407KbByQAfDbW9od8N9GYMnLTWbzwXS64+8TSJGvov9qa
6tfX2GIJH0FTZi1hSc1PlvM2xlqqoKCzc+OVD8jmUAcLHsHB5EBtE4ireF/erYM4
aFGDDZ36xI2YHVwXdClgNMm/60L6VR8SYFpqsENuvmRUZsRjn+8+hRURul+7Jv3I
SFci2N7T4hPu
=bwf8
-----END PGP SIGNATURE-----