broke package management (warning long)

Joshua Judson Rosen rozzin at geekspace.com
Mon Feb 14 13:22:51 EST 2011


Jeffry Smith <jsmith at alum.mit.edu> writes:
>
> On Mon, Feb 14, 2011 at 8:48 AM, Lori Nagel <jastiv at yahoo.com> wrote:
> >
> >
> > jastiv at localhost:/var/log$ dpkg -S /lib/modules/2.6.30.7-libre-fshoppe1
> > dpkg: /lib/modules/2.6.30.7-libre-fshoppe1 not found.
> >
> > then I tried on a file I know was installed by the package manager.
> >
> > jastiv at localhost:/var/log$ dpkg -S /usr/share/gnome/help/gnect/it/figures
> > gnome-games-data: /usr/share/gnome/help/gnect/it/figures
> > jastiv at localhost:/var/log$
> >
> > basically the command does not work because the folder is no
> > longer there for some reason.
>
> Run "aptitude search linux-image" to see if you have a package with
> linux-image-2.6.30.7-libre-fshoppe1 installed.  If the kernel was
> manually installed and the /lib/modules deleted, you would have this
> problem.

Or if power was cut abruptly in the middle of an installation/upgrade
and the newly-created directory `disappeared' after reboot because
it hadn't actually been flushed to disk, maybe?

Also:

> dpkg is failing because update-initramfs is trying to build
> an initramfs for a kernel that doesn't have modules installed.
>
> You can also run update-initramfs manually (sudo update-initramfs -k
> all), and it should update all kernels you have, although will through
> an error on the 2.6.30.7 one without the modules.  If there are still
> problems, run "sudo update-initramfs -k <insert kernel name here>" to
> just update one of the kernels in your boot directory.

She'll still need to actually get the issue resolved in some way
that allows that stuck postinst script to complete successfully, though.

One way, which has been suggested, is to go find the missing modules
and install them.

Alternately, she's sure that she's not actually using that kernel,
maybe she could just *remove it the bad kernel* rather than trying
to make it good?

> Note that dpkg -S goes against the package cache/library, not the
> directories.  It's most likely failing because this was a manually
> installed kernel, not from a package.

Actually, that brings to mind another interesting possibility--basically
the exact opposite of the scenario I posited above: maybe it *was*
a packaged kernel, and it was in the process of being *removed*
when the system crashed hard--which might have some bits hanging around
because the *unlink* operations didn't get flushed to disk?

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."



More information about the gnhlug-discuss mailing list