Figuring out after the fact what went wrong in the kernel hook is kinda
hart, also as the bugreports are usually very lacking on the details
front. Collecting the internal variables in the debug output we attach
to the generated file might help shine some light on the matter.
It's at least not going to hurt…
APT::NeverAutoRemove
{
EOF
APT::NeverAutoRemove
{
EOF
- apt-config dump --no-empty --format '%v%n' 'APT::VersionedKernelPackages' | while read package; do
+ for package in $(apt-config dump --no-empty --format '%v%n' 'APT::VersionedKernelPackages'); do
for kernel in $kernels; do
echo " \"^${package}-${kernel}$\";"
done
done
echo '};'
for kernel in $kernels; do
echo " \"^${package}-${kernel}$\";"
done
done
echo '};'
+ if [ "${APT_AUTO_REMOVAL_KERNELS_DEBUG:-true}" = 'true' ]; then
+ cat <<EOF
+/* Debug information:
+# dpkg list:
+$(dpkg -l | grep '\(linux\|kfreebsd\|gnumach\)-image-')
+# list of installed kernel packages:
+$list
+# list of different kernel versions:
+$debverlist
+# Installing kernel: $installed_version ($1)
+# Running kernel: $running_version ($unamer)
+# Last kernel: $latest_version
+# Previous kernel: $previous_version
+# Kernel versions list to keep:
+$debkernels
+# Kernel packages (version part) to protect:
+$kernels
+*/
+EOF
+ fi
-generateconfig > "${config_file}.dpkg-new"
-mv "${config_file}.dpkg-new" "$config_file"
+generateconfig "$@" > "${config_file}.dpkg-new"
+mv -f "${config_file}.dpkg-new" "$config_file"