System will not upgrade, can't remove old kernel

[henryWho]

apt will not longer work. No matter what I try the first thing it tries to do is upgrade the kernel and it fails.
I'm desperate, this has plauged me for days!

Do you want to continue? [Y/n]
Reading changelogs... Done
Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 75940 files and directories currently installed.)
Removing linux-image-3.2.0-4-amd64 (3.2.93-1) ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.2.0-4-amd64 /boot/vmlinuz-3.2.0-4-amd64
update-initramfs: Deleting /boot/initrd.img-3.2.0-4-amd64
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.2.0-4-amd64 /boot/vmlinuz-3.2.0-4-amd64
run-parts: /etc/kernel/postrm.d/zz-update-grub exited with return code 255
Failed to process /etc/kernel/postrm.d at /var/lib/dpkg/info/linux-image-3.2.0-4-amd64.postrm line 212.
dpkg: error processing package linux-image-3.2.0-4-amd64 (--remove):
subprocess installed post-removal script returned error exit status 2
Errors were encountered while processing:
linux-image-3.2.0-4-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

[debiman]

please post the output of

Code: Select all

uname -rv
cat /etc/*release*
apt update

[henryWho]

Firstly thank you for responding.

# uname -rv
4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19)

# cat /etc/*release*
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

# apt update
Ign:1 http://ftp.fr.debian.org/debian stretch InRelease
Hit:2 http://ftp.fr.debian.org/debian stretch Release
Get:3 http://security.debian.org stretch/updates InRelease [62.9 kB]
Fetched 62.9 kB in 0s (170 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
97 packages can be upgraded. Run 'apt list --upgradable' to see them.

[debiman]

it seems you have too few sources.
strange.
mine shows much more, and it's not far from a vanilla install.

are you running all this as root? or why the '#'?
anyhow, now try 'apt upgrade'.

how did you install that ancient kernel in the first place?

have you played with your sources? how?
explanation first, then output of

Code: Select all

cat /etc/apt/sources.list
echo ============
cat /etc/apt/sources.list.d/*

please use code tags for output, here on the forum.

stab in the dark:
maybe you have to re-enable sources to remove the old kernel?

[henryWho]

I've already stated, apt does not work. It will not grogress past the kernel removal.
The machine was installed with wheezy, then upgraded to jessie then upgraded to stretch.

source.list was updated before each upgrade.

Code: Select all

cat /etc/apt/sources.list
# deb http://ftp.fr.debian.org/debian wheezy main

#deb http://ftp.fr.debian.org/debian wheezy main non-free contrib
#deb-src http://ftp.fr.debian.org/debian wheezy main non-free contrib

#deb http://security.debian.org/ wheezy/updates main contrib non-free
#deb-src http://security.debian.org/ wheezy/updates main contrib non-free

# wheezy-updates, previously known as 'volatile'
#deb http://ftp.fr.debian.org/debian wheezy-updates main contrib non-free
#deb-src http://ftp.fr.debian.org/debian wheezy-updates main contrib non-free

#deb http://www.bunkus.org/debian/wheezy/ ./
#deb-src http://www.bunkus.org/debian/wheezy/ ./
#deb http://ftp.fr.debian.org/debian/ stretch main
#deb-src http://ftp.fr.debian.org/debian/ stretch main

deb http://ftp.fr.debian.org/debian/ stretch-updates main contrib

deb http://ftp.fr.debian.org/debian stretch main non-free contrib
deb-src http://ftp.fr.debian.org/debian stretch main non-free contrib

deb http://security.debian.org/ stretch/updates main contrib non-free
deb-src http://security.debian.org/ stretch/updates main contrib non-free

# wheezy-updates, previously known as 'volatile'
#deb http://ftp.fr.debian.org/debian stretch-updates main contrib non-free
#deb-src http://ftp.fr.debian.org/debian stretch-updates main contrib non-free

cat /etc/apt/sources.list.d/*
 cat: '/etc/apt/sources.list.d/*': No such file or directory

[pylkko]

You are trying to remove a package that has no repo in sources.list

Try to add wheezy to the list, update, and remove it with "purge".

Or use dpkg

Code: Select all

dpkg --purge package_name

[p.H]

You are trying to remove a package that has no repo in sources.list

So what ?

Apt is working fine. It is just the execution of the script /etc/kernel/postrm.d/zz-update-grub which returns an error.
What does

Code: Select all

update-grub

return ?

[debiman]

^ i think you nailed it.
it says in post #1 that it returned 255.
not sure why that would be a problem.

@op: i suspect something's wrong with your grub! which version?

[pylkko]

Ok. So maybe I'm wrong, but I was under the impression that you can end up with a corrupt /var/lib/dpkg/status file when you remove the source.list entries and apt-get clean. After all, you no longer get the packages.gz from that repo then I guess? But if anyone really knows more about this, I'm all ears. I have understood that all clients using libapt attempt to keep track of the status and itsdependencies and if the status is incorrect then you can get into situations where doing something a requires doing something b which is impossible to do, whereas dpkg does not keep track of dependencies at all (https://askubuntu.com/questions/40011/h ... ies-for-me ) Something like this certainly has happened to me and also with a kernel package. I no longer remember the details but after readding the source and updating apt however was able to understand. Something like what is described here:
https://openforums.wordpress.com/2013/0 ... -packages/

But here the error message is indeed pointing ts zz-update-grub which contains some conditions and then

Code: Select all

	if [ -e /boot/grub/grub.cfg ]; then
		exec update-grub
/

It says

Code: Select all

subprocess installed post-removal script returned error exit status 2

. Exit status 2 = "Misuse of shell builtins (according to Bash documentation)"

source:
http://www.tldp.org/LDP/abs/html/exitcodes.html

but why would that fail?

Edit: this post might have an incorrect account of how dpkg and apt work

[p.H]

I was under the impression that you can end up with a corrupt /var/lib/dpkg/status file when you remove the source.list entries and apt-get clean

I don't see how. AFAIK dpkg has nothing to do with sources.list.
If you were right, distribution upgrades would not be possible.

dpkg does keep track of dependencies. It won't let you install a package if the dependencies are not satisfied.

[pylkko]

If you have a wheezy 3.2 kernel on your startch system and you then use apt to upgrade, how would it know that that kernel is from wheezy if you don't have that data in your sources.list? dpkg could of course uninstall it nevertheless, because like I said, and then you said, it does not care about sources.list and you can use it even on a device with no network connection or any kind of repository at all. But that is beside the point. If however, the package is from source "not available", how could upgrading possibly know to uninstall the package? In this case you could then either manually uninstall it... or add the old repository and apt update, after which it would be marked as "from wheezy". I don't think that upgrading or even dist-upgrading removes packages that are installed manually. A lone wheezy kernel package on a stretch machine.. would that not be as if a manually installed deb (i.e not from any source)?

Something similar happens when your status file is corrupted and it thinks that a package exists or does not when this is not the case. Then when apt tries to take care of the dependecies it might fail when doing thing a requries thing b which is impossible. When you clear the file and refetch the repository data it works again.

Well, the man page does not seem to give any answer to this. Of course, I could, if I wanted, try by installing a wheezy kernel and all that.

[p.H]

If you have a wheezy 3.2 kernel on your startch system

What is "startch" ? Do you mean "stretch" ?
I generally do not mind so much about typos, but two in the same word is a lot.

how would it know that that kernel is from wheezy if you don't have that data in your sources.list?

It doesn't know. Why would it need to know ?

If however, the package is from source "not available", how could upgrading possibly know to uninstall the package?

Multiple possible reasons :
- the old package conflicts with a new package and will be removed before upgrade.
- the package is marked as automatically installed (by dependency of the meta-package linux-image-$arch), and is no longer needed. Even in this case I do not thinl the package is removed on upgrade. It can be removed later with apt-get autoremove.
Anyway, it is irrelevant whether the package is still in the sources or not.

would that not be as if a manually installed deb (i.e not from any source)?

Yes. And it is equally irrelevant regarding the removal.

[pylkko]

Startch = autocorrect

Sorry about misleading this thread.

Although I am not convinced about your argument (do any of those even apply to a kernel package) , I don't believe that fact that the post removal script fails has anything to do with the scenario that I suggested earlier and that is a seperate issue, distracting what is at hand here

[p.H]

Startch = autocorrect

I do not understand what this means.

I am not convinced about your argument (do any of those even apply to a kernel package)

From the point of view of the pakage management system, a kernel package has nothing special. It is just a package like others. It is tagged "Priority : optional", so is not even a required or important package.

[pylkko]

Startch = autocorrect

I do not understand what this means.

I am not convinced about your argument (do any of those even apply to a kernel package)

From the point of view of the pakage management system, a kernel package has nothing special. It is just a package like others. It is tagged "Priority : optional", so is not even a required or important package.

No, but they appear to be versioned differently (except for metapackages that do have versions that are always clearly related to theit earlier versions) and will also not conflict with new packages. AFAIK, it never happens that a new package is incompatible with a kernel.

Autocorrect is when the keyboard or other software implementation changes words that you type.

[p.H]

No, but they appear to be versioned differently

Kernel packages have a version number in their names. So a higher version kernel is a different package, not a new version of the same package. But this is not specific to kernel packages : many library packages also have a version number in their names. It allows to install several versions of kernel or such libraries (you could not install several versions of the same package name).

Autocorrect is when the keyboard or other software implementation changes words that you type.

Got it. What did you mean to write originally ?