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