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

[Halvor Raknes]

When you delete system files...there's only one fix..reinstall.

This is why it's so important to backup your system with a system image created with Foxclone and Rescuezilla.

I have major resource restraints, i.e. storage space and money.

 

[Halvor Raknes]

I investigated further.

• apt-cache policy, apt-cache show, and apt-cache showpkg all look normal.
• The relevant .deb files exist in /var/cache/apt/archives/.
• apt reinstall fails for openssh-server, rsyslog, and samba-common with:

E: Internal Error, No file name for <package>:amd64

Additionally:

$ dpkg -V apt apt-utils
dpkg: warning: files list file for package 'apt' missing
dpkg: warning: files list file for package 'apt-utils' missing

and

$ ls /var/lib/dpkg/info | grep '^apt'
aptkit.conffiles
aptkit.list
aptkit.md5sums

There are no apt.* or apt-utils.* files under /var/lib/dpkg/info, although

dpkg -l apt apt-utils

reports both packages as installed (ii).
Could the missing metadata for apt itself explain the repeated No file name internal error, or is there another APT state that I should investigate?

 

[Condobloke]

major resource restraints, i.e. storage space and money.

A great number of us are familiar with that feeling.

 

[Halvor Raknes]

I have changed the thread title to reflect the current focus of my troubleshooting.

At this point, it seems that the internal apt/dpkg malfunction needs to be resolved before attempting any broad package reinstallation. My repeated apt reinstall attempts consistently fail with:

E: Internal Error, No file name for <package>:amd64

so I believe that issue should be understood first.

 

[craigevil]

sudo apt distclean
sudo apt update

If the above doesn't work take a look at:

Chapter 2. Debian package management

How to Fix dpkg "Broken Packages" Errors

Fix dpkg broken package errors step by step: configure pending packages, repair dependencies with apt --fix-broken, force-remove stuck packages, and rebuild the dpkg database.

linuxjunkies.org

Number 13 here has a good answer https://unix.stackexchange.com/questions/161866/how-to-recreate-var-lib-dpkg-status

You can re-create

/var/lib/dpkg/status by copying the backup from /var/backups/​

 

[Halvor Raknes]

sudo apt distclean
sudo apt update

If the above doesn't work take a look at:

Chapter 2. Debian package management

How to Fix dpkg "Broken Packages" Errors

Fix dpkg broken package errors step by step: configure pending packages, repair dependencies with apt --fix-broken, force-remove stuck packages, and rebuild the dpkg database.

linuxjunkies.org

Number 13 here has a good answer https://unix.stackexchange.com/questions/161866/how-to-recreate-var-lib-dpkg-status

You can re-create

/var/lib/dpkg/status by copying the backup from /var/backups/​

Thanks. apt update completes successfully, and /var/lib/dpkg/status appears to be intact.

The remaining blocker is that every apt reinstall ends with


E: Internal Error, No file name for <package>:amd64


even though:

• apt-cache policy looks correct,
• apt-cache show reports the expected Filename:,
• the corresponding .deb file exists in /var/cache/apt/archives/.

Also, dpkg -V apt apt-utils reports that the .list files for apt and apt-utils are missing from /var/lib/dpkg/info.

Do you think that missing metadata for apt itself could explain the "No file name" internal error?

 

[craigevil]

Try the fix shown here: https://deverrors.com/errors/apt-internal-error-no-filename

you could also try doing:

sudo dpkg -i /var/cache/apt/archives/*.deb
dpkg --configure -a

 

[deb_user]

I have major resource restraints, i.e. storage space and money.

This demands more careful actions. Having a system backup is the best way to prevent disaster, but if that isn't possible, disaster must be avoided by thinking carefully about everything before pressing the Enter key. Live and learn, but I'm not sure you can do much other than live with what you have or reinstalling. Neither is ideal, but the ideal fix of restoring from a backup isn't possible, so the choices become limited.

 

[Halvor Raknes]

Try the fix shown here: https://deverrors.com/errors/apt-internal-error-no-filename

you could also try doing:

sudo dpkg -i /var/cache/apt/archives/*.deb
dpkg --configure -a

Are you recommending dpkg -i /var/cache/apt/archives/*.deb because you've actually used this to recover from "E: Internal Error, No file name", or is it a general suggestion?

 

[Halvor Raknes]

Update


I think the focus has shifted from recreating /var/lib/dpkg/info to an internal APT/DPKG metadata problem.


Current findings:

• apt reinstall fails for multiple packages (openssh-server, rsyslog, samba-common) with:
  
  E: Internal Error, No file name for <package>:amd64
• openssh-server.postinst itself appears to execute almost completely when traced, but dpkg still returns:
  
  installed openssh-server package post-installation script subprocess returned error exit status 10
• I also discovered that several core packages are missing their metadata in /var/lib/dpkg/info. For example:

dpkg -V apt
dpkg -V ucf
dpkg -V debconf


all report:




warning: files list file for package '...' missing


and:




ls /var/lib/dpkg/info/apt.*
ls /var/lib/dpkg/info/ucf.*
ls /var/lib/dpkg/info/debconf.*


reports that those files do not exist.


Since openssh-server.postinst uses both ucf and debconf, I'm beginning to suspect that the package failures are symptoms of missing dpkg metadata rather than the packages themselves.


Does this suggest that repairing the metadata for essential packages (apt, apt-utils, ucf, debconf, etc.) should be the next step before attempting any large-scale reinstall?