Kernel updates are being marked as manually installed

On 2 May 2013 22:57, Steve J. <email address hidden> wrote:
> Public bug reported:
>
> Updates to the linux-image-* packages in Precise are being marked as
> "manually" installed, regardless of the auto/manual flag on the existing
> kernel packages. This happens when updating packages with apt, aptitude,
> or unattended-upgrades. I'm running an up-to-date 12.04.2 LTS installed
> (amd64).
>

The most recent kernel image (or was that active?) is marked manual,
and others are auto.

> I can see that my existing kernels were marked as automatically
> installed:
>
> % apt-mark showauto | grep linux-image
> linux-image-3.2.0-40-generic
> linux-image-generic
>
> And, after the update was performed by unattended-upgrades last night,
> the new kernel is marked manual:
>
> % apt-mark showmanual | grep linux-image
> linux-image-3.2.0-41-generic
>

This is exactly the behaviour expected by:

> This is a problem, because it renders the fix in this bug,
> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/923876 (Limit and
> clean-up kernel images and headers automatically in LTS) ineffective,
> since apt-get autoremove will not remove packages which are marked as
> manually installed.
>

When the kernel image is upgraded again, 3.2.0-41 will be marked auto.
 The kernel cleanup hack works by putting the active kernel image
outside of APTs autoremove system, i.e. to mark it manually installed.

On Fri, May 03, 2013 at 01:09:09AM -0000, Daniel Hartwig wrote:
> > This is a problem, because it renders the fix in this bug,
> > https://bugs.launchpad.net/ubuntu/+source/apt/+bug/923876 (Limit and
> > clean-up kernel images and headers automatically in LTS) ineffective,
> > since apt-get autoremove will not remove packages which are marked as
> > manually installed.
> >
>
> When the kernel image is upgraded again, 3.2.0-41 will be marked auto.
> The kernel cleanup hack works by putting the active kernel image
> outside of APTs autoremove system, i.e. to mark it manually installed.

I see, but that's not the behavior that I'm seeing (the host I picked to
use as an example wasn't a very good one, sorry). I'm seeing all the
kernel packages remaining marked manual, and they're never being marked
as auto after new updates.

The kernel cleanup isn't solely relying on auto/manual status, as it's
adding the appropriate kernel versions (iirc, 'active', latest, and
latest - 1) to the NeverAutoRemove clause in the 01autoremove-kernels
apt config.

So, long story short, I'm seeing lots of 'manually' installed kernels
pile up and fill /boot partitions :/

Thanks for taking the time to respond so quickly!

On 3 May 2013 20:24, Steve J. <email address hidden> wrote:
> On Fri, May 03, 2013 at 01:09:09AM -0000, Daniel Hartwig wrote:
>> > This is a problem, because it renders the fix in this bug,
>> > https://bugs.launchpad.net/ubuntu/+source/apt/+bug/923876 (Limit and
>> > clean-up kernel images and headers automatically in LTS) ineffective,
>> > since apt-get autoremove will not remove packages which are marked as
>> > manually installed.
>> >
>>
>> When the kernel image is upgraded again, 3.2.0-41 will be marked auto.
>> The kernel cleanup hack works by putting the active kernel image
>> outside of APTs autoremove system, i.e. to mark it manually installed.
>
> I see, but that's not the behavior that I'm seeing (the host I picked to
> use as an example wasn't a very good one, sorry). I'm seeing all the
> kernel packages remaining marked manual, and they're never being marked
> as auto after new updates.
>

Yes that is my mistake, the cleanup does not change the marking at
all. If they are currently manual you will have to mark them
auto-installed to have the cleanup work. If upgrading
'linux-image-generic' leaves you with a linux-image that is marked
manual, that is of course a problem.

How do you upgrade the systems, in your original message you mention
aptitude and unattended-upgrades?

> This bug looks similar to
> https://bugs.launchpad.net/aptdaemon/+bug/1078544, however, I'm running
> a version of aptdaemon that supposedly has this fix applied.

That issue does not apply here as the kernel upgrades you identified
usually come as new packages. It would apply if e.g. after an upgrade
you found that 'linux-image-generic' had changed from auto-installed
to manual.

On Fri, May 03, 2013 at 01:20:06PM -0000, Daniel Hartwig wrote:
>
> Yes that is my mistake, the cleanup does not change the marking at
> all. If they are currently manual you will have to mark them
> auto-installed to have the cleanup work. If upgrading
> 'linux-image-generic' leaves you with a linux-image that is marked
> manual, that is of course a problem.
>
> How do you upgrade the systems, in your original message you mention
> aptitude and unattended-upgrades?
>

In most cases, I've got unattended-upgrades running. I thought I saw
this on another system with just a regular 'apt-get dist-upgrade', but I'll
fire up some VMs and see if I can reproduce it there.

On Fri, May 03, 2013 at 01:20:06PM -0000, Daniel Hartwig wrote:
> > This bug looks similar to
> > https://bugs.launchpad.net/aptdaemon/+bug/1078544, however, I'm running
> > a version of aptdaemon that supposedly has this fix applied.
>
> That issue does not apply here as the kernel upgrades you identified
> usually come as new packages. It would apply if e.g. after an upgrade
> you found that 'linux-image-generic' had changed from auto-installed
> to manual.

OK, I can't seem to reproduce this. On a few VMs that have, the
linux-image-generic package is remaining 'auto' after the update
(provided that I marked it that way by hand before the update). Only the
new linux-image-<version>-generic package is 'manual'.

Unattended-upgrades does perform
kernel updates, so it's likely installing/dist-upgrade-ing kernel upgrades as new
packages (which must be why I'm seeing them as being marked 'manual').

Do you have any suggestions for automatically flagging obsolete kernels as 'auto', or
might it be worth adding a feature to the kernel cleanup to do this?

-Steve

On 3 May 2013 22:11, Steve J. <email address hidden> wrote:
> Unattended-upgrades does perform
> kernel updates, so it's likely installing/dist-upgrade-ing kernel upgrades as new
> packages (which must be why I'm seeing them as being marked 'manual').
>

Looks like an issue with unattended-upgrades (or possibly python-apt).
 It does not specifically install kernel packages, so the new package
('linux-image-3.2.0-41-generic' in the original message) must have
come as a dependency of upgrading 'linux-image-generic' or similar.
In that case, it must not be marked manually installed.

 affects ubuntu/unattended-upgrades

A cursory glance at the main parts of 'unattended-upgrade' did not
reveal any obvious errors, but it performs such heavy manipulation of
the depcache that a more detailed inspection is required.

Do the systems have either apt.conf option set:

- Unattended-Upgrades::MinimalSteps
- Unattended-Upgrade::MinimalSteps

> Do you have any suggestions for automatically flagging obsolete kernels as 'auto', or
> might it be worth adding a feature to the kernel cleanup to do this?
>

Markauto every kernel image as the cleanup script protects the most
relevent ones.

# apt-mark markauto linux-image.*

Although you will have to do that after every new kernel image is
installed, until the issue with upgrade-alternatives is resolved.

On Sat, May 04, 2013 at 02:13:12AM -0000, Daniel Hartwig wrote:
> Do the systems have either apt.conf option set:
>
> - Unattended-Upgrades::MinimalSteps
> - Unattended-Upgrade::MinimalSteps

Nope, I have neither of those options set.

Status changed to 'Confirmed' because the bug affects multiple users.

I just ran an unattended-upgrade on a precise system and the new kernel was marked as manual.

bdmurray@flash:~$ apt-mark showauto | grep linux-image
bdmurray@flash:~$ apt-mark showmanual | grep linux-image
linux-image-3.2.0-29-generic
linux-image-3.2.0-37-generic
linux-image-3.2.0-38-generic
linux-image-3.2.0-41-generic
linux-image-3.2.0-44-generic
linux-image-generic
bdmurray@flash:~$ uname -a
Linux flash 3.2.0-41-generic #66-Ubuntu SMP Thu Apr 25 03:27:11 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Attached is the log file from my unattended-upgrade run.

08:33 < slangasek> bdmurray: so I think it's probably a
                   straightforward matter of
                   unattended-upgrades not calling the
                   right api to mark packages as auto
                   when pulling them in as new deps
08:33 < slangasek> not that I know what that api
                   actually is
08:35 < bdmurray> slangasek: okay
08:35 < cjwatson> mark_install(from_user=False) I think?
                  But check ...
08:36 < slangasek> ah, there's a single call to
                   mark_install() in u-a, so that would
                   be nice and convenient if so
08:36 < slangasek> bdmurray: is that enough to be going
                   on with?

unattended-upgrade does not directly handle dependencies, and its only
effective calls are to ‘mark_upgrade’.

> 08:36 < slangasek> ah, there's a single call to
> mark_install() in u-a, so that would
> be nice and convenient if so

In ‘upgrade_in_minimal_steps’, but conditional on:

            elif not pkg.is_installed:
                pkg.mark_install()

so only called if somehow a not-installed package ends up in
pkgs_to_upgrade inside main. There are many unconditional calls to
pkg.mark_upgrade that should generate a python-apt error for a
not-installed package in that list.

In any case, looking at the log Brian provided,
linux-image-3.2.0-44-generic is the package of interest, yet does not
appear in pkgs_to_upgrade (see the second to last line of the log,
starting “Packages that are upgraded:”).

> 08:35 < cjwatson> mark_install(from_user=False) I think?
> But check ...

This is a too common misconception. ‘FromUser’ is concerned with other
functions, such as whether to override a hold or not. It must never
be used strictly for the side-effect of maybe setting auto-installed.
The only proper way to explicitly mark a package auto-installed is to
call ‘MarkInstall’ followed by ‘MarkAuto’, and most programs need not
be concerned with that unless e.g. they include their own dependency
solver.

On 6 June 2013 11:14, Daniel Hartwig <email address hidden> wrote:
> In ‘upgrade_in_minimal_steps’, but conditional on:
>
> elif not pkg.is_installed:
> pkg.mark_install()

Also unrelated, though this call should be removed based on my earlier
reasoning that it is never used. Otherwise, even though it is unused,
it should have ‘from_user=False’ to indicate that these requests are
not coming directly from the user and avoid issues with e.g.
overriding holds.

However, unattended-upgrades (and indeed any program using python-apt)
will still inappropriately override holds due to
<http://bugs.debian.org/686726>.

‘MarkInstall’ has changed quite a bit since version in precise, including much in the ways of handling auto-installed. Can someone provide an apt log with Debug::pkgDepCache::Marker and Debug::pkgDepCache::AutoInstall set.

I did this in a minimal precise lxc container so there may be something missing. Nonetheless, attached you'll find /var/log/unattended-upgrades/unattended-upgrades.log.

I am experiencing this issue even on Ubuntu 15.04 Vivid. I upgraded to kernel 3.19.0-21 today using the desktop Software Updater tool and the packages are all marked as manually installed.

Even without using unattended install on Ubuntu 14.04, the kernels are marked as manually installed. This prevent apt autoremove from removing unneeded kernel.

So I needed to do this tricks:
sudo apt-mark auto $(apt-mark showmanual | grep linux-image)

Then I can run normally:
sudo apt-get autoremove

ben-r-xiao, id2ndr: I think that you are running into bug #1492709 or maybe bug #1439769, neither of which involve unattended-upgades. (These two bugs might be the same thing.)

This seems to be fixes in ubuntu 15.10. (I am using Xubuntu). apt package version is 1.0.10.2ubuntu1. Can you confirm?

I confirm it's fixed.

And as for unattended-upgrades, the bug is fixes in Ubunut 14.04.