[Pkg-libvirt-maintainers] Bug#825423: [buildd-tools-devel] Bug#825423: supermin + sbuild + linux-image = broken chroot

[Johannes Schauer]

Hi,

Quoting Santiago Vila (2016-05-26 21:48:49)
> When the package has been built and the build-dependencies are removed
> afterwards, this is what happens:
> 
> ------------------------------------------------------------------------
> [...]
> Removing linux-image-amd64 (4.5+73) ...
> Removing linux-image-4.5.0-2-amd64 (4.5.4-1) ...
> Aborting removal of running kernel image.
> dpkg: error processing package linux-image-4.5.0-2-amd64 (--purge):
>  subprocess installed pre-removal script returned error exit status 1
> 
> [...]
> 
> Errors were encountered while processing:
>  linux-image-4.5.0-2-amd64
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> apt-get failed.
> Failed to remove installed packages!
> ------------------------------------------------------------------------

this seems to suggest that you are not using a throw-away chroot but a
persistent one. Could you provide details about your chroot setup? Are you not
using schroot?

> When I build any other package with sbuild after this one, this is what
> happens:
> 
> +------------------------------------------------------------------------------+
> | Update chroot                                                                |
> +------------------------------------------------------------------------------+
> 
> Hit:1 http://httpredir.debian.org/debian stretch InRelease
> Reading package lists...
> Reading package lists...
> Building dependency tree...
> Reading state information...
> You might want to run 'apt-get -f install' to correct these.
> The following packages have unmet dependencies:
>  linux-image-4.5.0-2-amd64 : Depends: kmod but it is not installed
>                              Depends: linux-base but it is not installed
>                              Depends: initramfs-tools (>= 0.110~) but it is not installed or
>                                       linux-initramfs-tool
> E: Unmet dependencies. Try using -f.
> --------------------------------------------------------------------------------
> 
> i.e. every other package fails from this point.
> 
> The chroot is broken and it requires manual intervention to be fixed.

That linux-image-4.5.0-2-amd64 cannot be uninstalled is not a bug in sbuild but
a bug elsewhere. That a package cannot be uninstalled is nothing sbuild can do
something about. If anything, it is the responsibility of the chroot management
system to provide workarounds for situations like this if that's the last
ressort.

> The reason for this, I think, is that linux-image refuses to be uninstalled
> if it detects that it's the same version which is running in the system.
> 
> 
> This check, however, fails to account this case, where the linux-image
> being removed is the same version but not actually the same which is running,

if that is the case, then this sounds like a bug in the source package linux.

> I think it should not be too much difficult to check that we are not in a
> chroot.
> 
> If we are in a chroot, removing the package should succeed, even if the version
> matches the linux-image running in the ssystem.
> 
> 
> Alternatively (and this is where the bug would not be only a bug in linux),
> linux-image could provide some kind of escape mechanism allowing sbuild
> to uninstall it successfully.

I do not think it's a good idea for anybody to mingle with the dpkg database or
maintainer scripts except for dpkg or the package itself.

> Alternatively, supermin should not build-depend on linux-image.  (But I am
> nobody to tell people what they should build-depend on).
> 
> 
> [ Note about the severity: It is my understanding that sbuild is
>   basically the same software which is running in the buildds, so the
>   main reason this bug has not happened there is that they are still
>   running jessie.
> 
>   But once that they are upgraded to stretch (and we can assume that
>   they will, sooner or later), this could happen in the official autobuilders
>   as well, and that's why I think this should be fixed before the release of
>   stretch ].

sbuild is indeed used on the buildds but those are using trow-away chroots
where it will not matter whether packages fail to uninstall. Since your setup
is different, I don't think buildds will be affected by this problem.

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-libvirt-maintainers/attachments/20160526/8c6d88f2/attachment.sig>