Cleaning up of /lib/modules
Andy Whitcroft
apw at canonical.com
Mon Aug 16 11:33:07 UTC 2010
On Mon, Aug 16, 2010 at 12:21:28PM +0100, Andy Whitcroft wrote:
> On Mon, Aug 16, 2010 at 12:14:59PM +0200, Loïc Minier wrote:
> > Hey!
> >
> > Purging linux-image-2.6.35-13-generic, I got yet another warning from
> > dpkg that some files remained in lib/modules.
> >
> > I think the kernel packaging process should have some checks in place
> > to prevent this class of issues to appear again and again and again:
> > - LP #345623/348395: modules.alias.bin modules.dep.bin
> > modules.symbols.bin (jaunty)
> > - LP #415832: same files, reappeared in karmic!
> > - LP #516584: modules.builtin.bin
> > - LP #618591: modules.devname modules.softdep
> >
> > I don't know whether you have an easy way to test for these, perhaps
> > there should be some QA process for installing then purging a kernel
> > package, before uploading it to the archive?
>
> The issue is that these are not files generated by the kernel package
> per-se, they are generated by modutils; though they are generated by
> commands triggered in postinst from the kernel. Changes in modutils
> lead to us being blamed for files remaining. That package really needs
> to offer a 'clean up the room before leaving' option. It is not clear
> how the kernel packaging could check for this at packaging time.
>
> All of that said likely yes we should be doing periodic checks for new
> files being left behind.
By way of confirmation the same kernel installed on Lucid userspace does
purge correctly, but on Maverick fails with files remaining:
modules.devname
modules.softdep
Will get these cleared out.
-apw
More information about the kernel-team
mailing list