[bitfolk] Re: Ubuntu/Apt f*ckery

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 &lt;users(a)mailman.bitfolk.com&gt; You're subscribed as &lt;murray.crane(a)gmail.com&gt; Unsubscribe: < https://mailman.bitfolk.com/mailman/postorius/lists/users.mailman.bitfolk.c… or send an email to &lt;users-leave(a)mailman.bitfolk.com&gt;