Recreated part of /var/lib/dpkg/info; apt reinstall now fails with "Internal Error, No file name"

[Halvor Raknes]

This is what those 4 files look like on my system:
apt.list

Thank you for taking the time to post that.

I think we've now narrowed the problem down further. I managed to regenerate a substantial part of /var/lib/dpkg/info, so the issue no longer appears to be simply missing maintainer scripts.

The current blocker is different: dpkg --configure openssh-server still fails because openssh-server.postinst calls ucf, and a strace shows that ucf itself exits with status 10. Running the same ucf command manually succeeds, but when it is invoked from the package's post-installation script it fails.

So the investigation has shifted from recreating /var/lib/dpkg/info to understanding why ucf behaves differently when executed by dpkg.

 

[Halvor Raknes]

Clear the APT Cache first



Then fix pending packages

Thanks. I tried the equivalent already.


apt update completes successfully, /var/lib/apt/lists has been rebuilt, and apt-cache policy, apt-cache show and apt-cache gencaches all work normally.


The remaining problem is that dpkg --configure -a still fails because openssh-server.postinst invokes ucf, and ucf exits with status 10.


A strace shows the failure occurs inside ucf, not while reading the APT package lists. So at the moment I'm trying to determine why ucf exits with code 10 even though running the same ucf command manually succeeds.

 

[Halvor Raknes]

@Halvor Raknes wrote:






Resource constraints may be relevant. How much space is available on the drive? For example, on a machine here, the following command and output will show usage:

[~]$ df
Filesystem     1K-blocks     Used Available Use% Mounted on
udev             7901224        0   7901224   0% /dev
tmpfs            1600420     1764   1598656   1% /run
/dev/nvme0n1p3 463735568 46717292 412279176  11% /  <-------NOTE ROOT PARTITION USAGE
tmpfs            8002092      544   8001548   1% /dev/shm
efivarfs             192       98        90  53% /sys/firmware/efi/efivars
none                1024        0      1024   0% /run/credentials/systemd-journald.service
tmpfs            8002092     4216   7997876   1% /tmp
/dev/nvme0n1p1    486456     4936    481520   2% /boot/efi
none                1024        0      1024   0% /run/credentials/[email protected]
tmpfs            1600416       48   1600368   1% /run/user/1000

If, for example, one had deleted the /var/lib/dpkg/info file to create a bit more space, then the situation described in post #1 could result.

In any case, the situation appears dire to me because of the following considerations.

Since apt has missing metadata that is normally available in /var/lib/dpkg/info, then apt itself would need to be re-installed. Doubtless that missing metadata is implicated in the the failures of apt that you have described. Clearly, a fully functioning apt is necessary for normal installation using apt. Unfortunately, apt has numerous dependencies, as seen here:

[~]$ apt depends apt
apt
 |Depends: base-passwd (>= 3.6.1)
  Depends: adduser
  Depends: sqv (>= 1.3.0)
  Depends: libapt-pkg7.0 (>= 3.3.1)
  Depends: debian-archive-keyring
  Depends: libc6 (>= 2.38)
  Depends: libgcc-s1 (>= 3.0)
  Depends: libseccomp2 (>= 2.4.2)
  Depends: libssl3t64 (>= 3.0.0)
  Depends: libstdc++6 (>= 13.1)
  Depends: libsystemd0
  Conflicts: <apt-verify>
  Conflicts: <libnettle8> (<< 3.9.1-2.2~)
  Breaks: apt-transport-https (<< 1.5~alpha4~)
  Breaks: apt-utils (<< 1.3~exp2~)
  Breaks: aptitude (<< 0.8.10)
  Recommends: ca-certificates
  Suggests: apt-doc
 |Suggests: aptitude
 |Suggests: synaptic
  Suggests: wajig
  Suggests: dpkg-dev (>= 1.17.2)
 |Suggests: gnupg
 |Suggests: gnupg2
  Suggests: gnupg1
  Suggests: powermgmt-base
  Replaces: apt-transport-https (<< 1.5~alpha4~)
  Replaces: apt-utils (<< 1.3~exp2~)

To satisfy those dependencies, theoretically one could download all the relevant .deb files and then ask dpkg to install all of them. However, any of the those dependencies may have their own dependencies which can lead to "dependency hell" which could be a very long time-consuming activity to involve oneself in to try and get a fully functioning apt back on the system. The apt package manager was designed to manage and resolve just these dependency issues.

In the past, many years ago, I did follow dependencies on numerous occasons to try and catch them all to install a package that needed them. It was time-consuming, a headache for me, and what I learnt was that "dependency hell" isn't my favourite place to be, and that package managers are very handy software . At this point, I would be thinking of backing up and re-installing the system.

Thank you for the detailed explanation. I agree that if this turns out to require rebuilding the package management infrastructure manually, reinstalling the system may ultimately be the better option.


However, recent debugging has uncovered something more specific. openssh-server.postinst reaches the ucf invocation, and ucf exits with status 10. A strace of the process shows ucf printing "failed to open ... No such file or directory" immediately before exiting.


Since we now have evidence pointing to a specific failure inside ucf, I'd like to understand exactly what file or directory it is failing to open before concluding that a full reinstall is unavoidable.

 

[f33dm3bits]

It's not very nice to double post cross-forums as we can't follow two topics and neither can they on the Linux Mint forums.

https://forums.linuxmint.com/viewtopic.php?t=471898

Shall I lock this topic then since you decided to continue on the Linux Mint forums?

 

[f33dm3bits]

I have found a solution that works on a Debian vm that I have with a DE running. I renamed "/var/lib/dpkg/info" to "/var/lib/dpkg/info" and created a new "info" directory with "mkdir". This resulted in the same situation as the OP of this topic.

It seems fixed by running the following.

1. Reinstall ucf

apt-get --reinstall install ucf

Then reinstall all the packages on the system.

for i in $(dpkg -l|awk '/^ii/ {print $2}')
do
    apt-get --reinstall -y install $i
done

At some point it will ask which configuration file you want to keep just keep the "Default" by pressing "N".

After the re-installation was done of all the package on the system all the files under "info" were re-generated. I was able to install "openssh-server" again which previously
Credit goes to this topic from 13 years ago.

Debian removed /var/lib/dpkg/info/, is there a way to save the system?

Removed accidentally /var/lib/dpkg/info/, now I am having problems with installing/removing packages, it prompts errors, cause can not find the info about installed packages. Is there any way to ...

serverfault.com

What also would works is to just use "apt" instead.

apt reinstall ucf

for i in $(dpkg -l|awk '/^ii/ {print $2}')
do
    apt reinstall -y $i
done

I think this will work to re-generate the files under /var/lib/dpkg/info for your system as well without having to reinstall, it's worth a shot and if not you'll at least have tried it.

 

[Halvor Raknes]

It's not very nice to double post cross-forums as we can't follow two topics and neither can they on the Linux Mint forums.

https://forums.linuxmint.com/viewtopic.php?t=471898

Shall I lock this topic then since you decided to continue on the Linux Mint forums?

I had no idea that was frowned upon.

I shall make a reference at forums.linuxmint.com to the present thread and discourage any follow-ups over there!

 

[f33dm3bits]

I had no idea that was frowned upon.

I shall make a reference at forums.linuxmint.com to the present thread and discourage any follow-ups over there!

Just don't do it again in the future.

I re-created your situation on a Debian system and was able to fix it. Can you try that to see if it works for you?

 

[f33dm3bits]

Then reinstall all the packages on the system.

This took a while, so let it run until it finishes.