Script stopped working: Change in apt to blame?

[Havin_it]

Hi,

I put together this wee script to handle the business of pruning old kernels for my GF. It runs on KDE login and nags her if there are more than 2 kernels installed, and automates the removal of the oldest one if she consents.

#!/bin/sh

K_MAX=2

K_INST=`ls /boot | grep -c vmlinuz`

if [ $K_INST -gt $K_MAX ] ; then
    K_OLD=`ls /boot | grep -m1 vmlinuz | egrep -o '2\.6\.[0-9\-]+[0-9]'`
    if kdialog --yesno "You have more than 2 kernels installed.
The oldest one is kernel-$K_OLD.
Would you like to get rid of it now?
This should just take a minute or so."; then
        K_MV=`echo ${K_OLD} | egrep -o '[0-9]+-[0-9]+'`
        sudo apt-get remove '.*2\.6\.${K_MV}.*'
    fi
fi

This worked when I wrote and tested it (less than a month ago IIRC) but I just tried it yesterday and it failed like so:

Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Regex compilation error - Invalid preceding regular expression

I assume something must have changed in apt, as that's where the fail apparently took place. Can anyone advise what the problem is, and how I might fix it?

Thanks in advance!

[jankushka]

Re: Script stopped working: Change in apt to blame?

you could try to add debug, like so

#!/bin/sh -x
...

then run the script again and see what that regex looks like.

hth

ps:
i'm still on 7.10 and your script seems to run alright.

[walfred]

Re: Script stopped working: Change in apt to blame?

also working here... 8.04

[Havin_it]

Re: Script stopped working: Change in apt to blame?

WHoa, bit of a delay there! I didn't have time to sort this out until now, but I've now rewritten the script... well it's now become 2 scripts.

What I learned was that the most recent version of apt-get (at the time) no longer worked with shell variable expansion, so I had to throw out the old method altogether. I also realised that using "ls" to make my list of installed kernels didn't work correctly: for example, when the versions are

2.6.27.10
2.6.27.11
2.6.27.8

...then this is the order they stack in, so my script thinks 2.6.27.10 is the oldest

I read up on apt-get and aptitude and came up with these two scripts. The first, /usr/local/bin/kernel-count is run on KDE autostart, and the second is called by it with the oldest kernel version as a parameter.

/usr/local/bin/kernel-count

#!/bin/sh

K_MAX=2

KVERS=`aptitude search ~ilinux-image-.+-generic -F "%v" -O version | egrep -o '2\.6\.[0-9]+-[0-9]+'`

K_INST=`echo "${KVERS}"|wc -l`

if [ $K_INST -gt $K_MAX ] ; then
    K_OLD=`echo "${KVERS}"|head -1`
    if kdialog --yesno "You have more than $K_MAX kernels installed.
The oldest one is kernel-$K_OLD.
Would you like to get rid of it now?
This should just take a minute or so."; then
        konsole -e sudo /usr/local/bin/kernel-remove $K_OLD
    fi
fi

/usr/local/bin/kernel-remove

#!/bin/sh

echo "Ready to remove Kernel ${1} ... \

"

apt-get -y remove linux-image-$1-generic

echo "Cleaning up ... \

"

apt-get autoremove -y

Just thought I'd share them in case they are of any interest. Sure they could be improved by a more skilled coder: feel free to add any revisions here if you feel inclined

[kubicle]

Re: Script stopped working: Change in apt to blame?

I also realised that using "ls" to make my list of installed kernels didn't work correctly

1. For future reference, 'ls' has extensive sorting options, see 'man ls'

2. I'd be hesitant to use 'apt-get -y autoremove' in any automated scripts (IMO, autoremove without interaction to see what will actually be removed may lead to problems)

[Havin_it]

Re: Script stopped working: Change in apt to blame?

Good points both! I could use "ls -t" (sort by modification time) to get the same result, which would speed things up apart from anything else I guess.

Are there often cases of autoremove causing disasters? I see your point about caution, but I'm really aiming to get it so this machine needs as little manual maintenance from me as possible.

[kubicle]

Re: Script stopped working: Change in apt to blame?

Are there often cases of autoremove causing disasters?

It's not a recipe for doom, in fact, in general it's quite safe. The problem is that in may remove packages you don't want to remove under *special* circumstances.

The problems are usually solvable (by reinstalling the packages), but if it's run automated, it might be harder to pinpoint what the problem is (when you experience a problem, you might not immediately associate it with the automated autoremove).

Your call, really, I tend to be overcautious when it comes to automated administration. You could of course add a confirmation window (with the list of packages to be removed) like you have with your kernel removal to be on the safe side.

I'm really aiming to get it so this machine needs as little manual maintenance from me as possible.

Good for you, laziness *is* a virtue among sysadmins. If you wish to go fully automated, you could set up your kernel removal script as a cron job to be run daily/weekly without any question asked (if you're not as cautious as I am )

[Havin_it]

Re: Script stopped working: Change in apt to blame?

Well, something to think about. I see your point about diagnosing problems being harder; I'm accustomed to Gentoo's Portage which keeps copious logs of everything it's done (including when it goes wrong), but I still have a lot to learn about apt, as is probably evident by now Does it have no such logging?

As for the confirmation-dialog idea, if it was for myself I'd probably do this, but what appears onscreen is unlikely to be meaningful to my lover and will only frighten her. (Not being condescending here, she would totally agree with that statement!)

[toad]

Re: Script stopped working: Change in apt to blame?

apt does log everything, 'cos it does Check in /var/log/

You could also redirect any messages to your own log (which then I suppose you'd write a script for to clean periodically )

Glad you got it sorted!