Writing as a person who has created deb packages from time to time:

The first thing I would suggest is to run dpkg --audit, which will run
some consistency checks and produce suggestions on how to fix anything
it spots.

The error _Not a directory_ is a curious one. It suggests that some path
component was present but not a directory. It shouldn't come about from
the standard kernel packaging scripts. Your error output identifies
linux-headers-4.4.0-210-generic as the troubled package.

If I were you I'd be looking at the pathnames dpkg complains about; do
you have a dangling symlink somewhere in there, or a file named for a
directory? This shouldn't happen, but it could be inadvertently done at
the command line. There is also a ton of questionable advice out there
which, if followed blindly, can leave your filesystem in a bad state.

If it's a broken symlink you might simply be able to remove it, or fix
it to point to wherever the files ended up, and then tell apt to try
again. It would of course be best to try to understand how your
filesystem got into this weird state, but that may be lost to the mists
of time.


Failing the above, you'll need to go deeper. The dpkg (apt) package info
database can be found in a series of plain text files
/var/lib/dpkg/info/<package-name>.* which you can edit by hand. This is
not recommended as a regular operation but may be a way to dig yourself
out of a hole.

Of primary interest in here is <package-name>.list . This is the list of
installed files which will be removed by a standard package removal.
Normally a missing file isn't a fatal error, but I'm not surprised that
ENOTDIR is causing dpkg to throw a rod.
You might care to write a quick script to iterate over this list and
identify the states of all the files listed (present, missing, ENOTDIR).
Off the top of my head this might be enough of a start:
for f in `cat linux-headers-4.4.0-210-generic.list`; do stat -t $f >
/dev/null; done

It might be appropriate to remove lines from the .list file, which will
cause apt to ignore them when you tell it to remove the package. Beware:
if the files were present but mislaid due to a symlink screw-up, they
would then _never_ be auto-removed in future. Naturally, if you're not
confident then take a copy of the files before you edit them.


Other files of note:

<package-name>.conffiles : list of configuration files which will be
removed on --purge (N.B. the file will not be present if there are none;
in which case 'purge' and 'remove' have the same effect).

<package-name>.postinst, prerm, preinst, postrm : pre/post
installation/removal scripts. These will only be present as necessary.
If one of these scripts fails, the dpkg operation that triggered it will
abort. I have on occasion had to hack these scripts by hand on a package
I had been working on, then fix up the damage.


Ross

_______________________________________________
BitFolk Users mailing list <users@mailman.bitfolk.com>
You're subscribed as <murray.crane@gmail.com>
Unsubscribe: <https://mailman.bitfolk.com/mailman/postorius/lists/users.mailman.bitfolk.com/>
or send an email to <users-leave@mailman.bitfolk.com>