checkinstall leaves root filesystem unusable if interrupted

my lord, but that was hard to recover from. I had to boot from a thumb drive, use cryptsetup to decrypt the drive, faff about with lvm to get it to recognise the logical volumes, then mount the drive, and eventually figure out that what it had done was to break /lib. removing /lib and replacing it with a symlink to usr/lib (apparently that's the default in 19.04?) seems to have given me a working system again.

This is because Ubuntu has decided to disable fs translation by default (https://bugs.launchpad.net/ubuntu/+source/checkinstall/+bug/78455). In my opinion that is a very unsafe default and the bug doesn't seem severe enough to justify it (mkdir -p is broken). I'm tracking this bug in Debian at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717778 and hope to figure out what the issue is soon.

Thanks for the instructions to repair. I would never expect an utility like checkinstall to break a system in this way. I think it should be pulled from the repositories before it gets repaired.

I've also been bitten by this. Thanks so much for the solution @hjwp2

Uhh, this has cost me a lot of wasted time and 3 reinstalls, thx @hjwp2.
This nasty evil should be removed from the feeds.

Status changed to 'Confirmed' because the bug affects multiple users.

I was just a victim of this package not listening to the --install=no instruction and destroying my system completely after an install has crashed (ironically it was for the BUP backup utility which I wanted to use to back up my system). Thanks to @hjwp2 for the quick fix. This package needs to be removed from the repositories ASAP.

Yep. Very sad that this is still open... One day of my life wasted cus this was a remote PC that I don't have immediate access.

Thank you @hjwp2! Your fix is so much faster than reinstalling Ubuntu 22.04!

Horrible issue! Faced it today, broke my system completely. Thanks for the tip, restoring the symlink helped.

(My system is Ubuntu 20.04.4 LTS)

This issue is the cause of probably the worst experience I've ever had, in over 20 years, with a misbehaving Linux utility.

I hit CTRL-C mid-way through a checkinstall and *everything* stopped working! I couldn't 'ls', open a new terminal, or even boot. Yet when I used a Ubuntu "LiveCD" (USB) to boot, mount and examine the filesystem, it all looked seemingly OK...

But it was that new /lib directory causing the problem, and replacing it with the symlink to usr/lib did fix it for me.

That was one of the worst hours of my life, so far at least. I could have lost my job over this if it had been a different computer. Not impressed!

But what great fortune that I found this thread... thank you all for finding such a simple fix.

Actually it's worse than I thought. I have a third-party cmake/make project that breaks mid-install (make: *** No rule to make target 'install'. Stop.), and this also triggers the issue. This means it's possible to create projects that will, at least for inexperienced users, brick their Ubuntu installation if you try to "checkinstall" it. Surely this is a critical bug?

I think I'll be running checkinstall inside a Docker container from now on!

For anyone coming across this in future, and in case it's not clear from reading the entire thread, you can avoid sudo/root and potentially breaking your system by using, as a regular user:

    $ checkinstall -install=no --fstrans=yes make install

This will create the .deb package safely, and you'll have to install it yourself afterwards, if you want to do that.

Since this bug hasn't been fixed after three years, please remove that package from the repositories as it should be considered abandoned on the ubuntu-side at the very least.

Just got bit by this bug. In my case, I had "aptitude" running in another terminal, so the dpkg lock was taken and the deb file couldn't be installed, so checkinstall failed and destroyed the running system. Was able to get a shell running using busybox, and eventually figured out the same "mv /lib{,-broken} ; ln -fs /usr/lib /lib" solution posted here.

I came here to report this, and now see that this has been going on for years.

Checkinstall should truly be considered abandonware at this point. Guess I should step up and fix it.

The suggestion from "David A (davi-d-a)" is a great idea!

I've been bitten by this bug twice. In my case, it simply removed the symlink from /lib to /usr/lib. Restoring this made my machine bootable again, but I don't know what else it could have hosed. This is using:

ackage: checkinstall
Version: 1.6.2+git20170426.d24a630-2ubuntu1

but checkinstall --version yields checkinstall 1.6.3. This is from a fresh install as of last week (when I was bitten by the bug the first time)

Coworker just got hit by this bug too. I think it really should be fixed, this bricks machines