#26 Le 01/08/2015, à 14:51
- nany
Re : Plus de place sur le boot [resolu]
[…] ce qui m’intéresse c’est de trouver où se trouve le petit grain de sable qui enraye la machine. […]
J’ai trouvé le grain de sable dans la première réponse de ce bug.
Bon, a priori, ce n’est pas un grain de sable mais plutôt d’une rose des sables au vu de cette réponse qui dit qu’il existe plusieurs bugs affectant update-manager et le marquage en manuel. Bref, le temps qu’ils se dépatouillent de tout ça, je pense que kclean a encore de beaux jours à vivre devant lui.
À moins que vous ne préféreriez l’astuce suivante pour faire le grand nettoyage directement avec autoremove :
sudo apt-mark auto $(apt-mark showmanual | egrep 'linux-.*[0-9]') && sudo apt-get autoremove@jplemoine : ton problème est quant à lui diamétralement opposé puisque l’autoremove suggère de supprimer aussi l’avant-dernier noyau.
Le script que tu indiques génère en effet le fichier de conf que j’ai demandé à voir (cf. #10 et #12). Or ce script est censé être exécuté automatiquement lors d’une mise à jour de noyau. Il a donc dû se passer quelque chose d’anormal lors de ta dernière mise à jour mais quoi ?…
Le mystère reste entier.
Hors ligne
#27 Le 01/08/2015, à 14:58
- jplemoine
Re : Plus de place sur le boot [resolu]
(*) est le noyau en cours d'utilisation
Je pense que le script n'est pas lancé au bon moment.
- noyau n -1
- noyau n (*)
Si on installe un noyau n+1 : on a
- noyau n-1
- noyau n (*)
- noyau n+1
--> le script est lancé en fin d'installation : il faut donc garder le n et le n+1 : ce ne semble pas être le cas.
Au reboot, on a
- noyau n-1
- noyau n
- noyau n+1 (*)
Si on relance le script, on garde le n+1 et le n --> et là, c'est bon
Membre de l'ALDIL (Association Lyonnaise pour le Développement de l'Informatique Libre)
- En pro, après 20 ans de développement, administrateur Linux / Unix depuis Avril 2019.
- En privé, sous Ubuntu-Xubuntu depuis 2009.
Hors ligne
#28 Le 01/08/2015, à 15:27
- nany
Re : Plus de place sur le boot [resolu]
[…]
--> le script est lancé en fin d'installation : il faut donc garder le n et le n+1 : ce ne semble pas être le cas.
[…]
C’est le bon moment pour exécuter le script et il devrait effectivement inscrire n et n+1 dans /etc/apt/apt.conf.d/01autoremove-kernels :
nany@stupidcomputer:~$ cat /etc/kernel/postinst.d/apt-auto-removal
#!/bin/sh
set -e
# Author: Steve Langasek <steve.langasek@canonical.com>
#
# Mark as not-for-autoremoval those kernel packages that are:
# - the currently booted version
# - the kernel version we've been called for
# - the latest kernel version (determined using rules copied from the grub
# package for deciding which kernel to boot)
# - the second-latest kernel version, if the booted kernel version is
# already the latest and this script is called for that same version,
# to ensure a fallback remains available in the event the newly-installed
# kernel at this ABI fails to boot
# In the common case, this results in exactly two kernels saved, but it can
# result in three kernels being saved. It's better to err on the side of
# saving too many kernels than saving too few.
#
# We generate this list and save it to /etc/apt/apt.conf.d instead of marking
# packages in the database because this runs from a postinst script, and apt
# will overwrite the db when it exits.
eval $(apt-config shell APT_CONF_D Dir::Etc::parts/d)
test -n "${APT_CONF_D}" || APT_CONF_D="/etc/apt/apt.conf.d"
config_file=${APT_CONF_D}/01autoremove-kernels
eval $(apt-config shell DPKG Dir::bin::dpkg/f)
test -n "$DPKG" || DPKG="/usr/bin/dpkg"
installed_version="$1"
running_version="$(uname -r)"
version_test_gt ()
{
local version_test_gt_sedexp="s/[._-]\(pre\|rc\|test\|git\|old\|trunk\)/~\1/g"
local version_a="`echo "$1" | sed -e "$version_test_gt_sedexp"`"
local version_b="`echo "$2" | sed -e "$version_test_gt_sedexp"`"
$DPKG --compare-versions "$version_a" gt "$version_b"
return "$?"
}
list="$(${DPKG} -l | awk '/^ii[ ]+(linux|kfreebsd|gnumach)-image-[0-9]/ && $2 !~ /-dbg$/ { print $2 }' | sed -e 's#\(linux\|kfreebsd\|gnumach\)-image-##')"
latest_version=""
previous_version=""
for i in $list; do
if version_test_gt "$i" "$latest_version"; then
previous_version="$latest_version"
latest_version="$i"
elif version_test_gt "$i" "$previous_version"; then
previous_version="$i"
fi
done
if [ "$latest_version" != "$installed_version" ] \
|| [ "$latest_version" != "$running_version" ] \
|| [ "$installed_version" != "$running_version" ]
then
# We have at least two kernels that we have reason to think the
# user wants, so don't save the second-newest version.
previous_version=
fi
kernels="$(echo "$latest_version
$installed_version
$running_version
$previous_version" | sort -u | sed -e 's#\.#\\.#g' )"
generateconfig() {
cat <<EOF
// DO NOT EDIT! File autogenerated by $0
APT::NeverAutoRemove
{
EOF
apt-config dump --no-empty --format '%v%n' 'APT::VersionedKernelPackages' | while read package; do
for kernel in $kernels; do
echo " \"^${package}-${kernel}$\";"
done
done
echo '};'
}
generateconfig > "${config_file}.dpkg-new"
mv "${config_file}.dpkg-new" "$config_file"
nany@nanyville:~$ dpkg -v
dpkg : erreur : option -v inconnue
Type dpkg --help for help about installing and deinstalling packages [*];
Use 'apt' or 'aptitude' for user-friendly package management;
Type dpkg -Dhelp for a list of dpkg debug flag values;
Type dpkg --force-help for a list of forcing options;
Type dpkg-deb --help for help about manipulating *.deb files;
Options marked [*] produce a lot of output - pipe it through 'less' or 'more' !
nany@nanyville:~$ dpkg --version
Programme « dpkg » de gestion de paquets Debian version 1.17.5 (amd64).
Ce programme est un logiciel libre ; veuillez consulter la « GNU General
Public License » version 2 ou supérieure pour prendre connaissance des
conditions de reproduction. AUCUNE garantie n'est offerte.
nany@stupidcomputer:~$Je ne vois rien qui puisse clocher dans ce script si ce n’est un bug de dpkg mais ça m’étonnerait.
As-tu le problème à chaque màj de noyau ou bien est-ce que ça ne t’est arrivé que la dernière fois ?
En tout cas, pour moi, le mystère reste entier.
Hors ligne