14 Dec
2014
14 Dec
'14
10:24 p.m.
Mike Bird composed on 2014-12-14 19:30 (UTC-0800):
The linux-image install may be failing as a result of
a config
file left over from a removed but not purged package or an
obsolete config file resulting from a downgrade or failed upgrade.
Try the following (all on one line):
dpkg-query --show --showformat='${STATUS}
${PACKAGE} ${VERSION}
${ARCHITECTURE}\n' | grep 'deinstall ok config-files' | awk '{print
$4}'
success ( | wc -l: 147 )
That should give you a list of packages to be purged.
If it
looks OK add a "dpkg --purge $(" on the front and a ")" on the
end to purge them.
Took me a while to grok this instruction into:
dpkg --purge $(dpkg-query --show --showformat='${STATUS} ${PACKAGE}
${VERSION} ${ARCHITECTURE}\n' | grep 'deinstall ok config-files' | awk
'{print $4}')
Then try the reinstall again. If it works great. If
it fails
Fails again with what looks like the exact same messages as all the other
times, and :-( again.
please show me the result of:
grep 'obsolete$' /var/lib/dpkg/status
/etc/default/kdm.d/10_desktop-base 0c8e814e3ff9771bc023cca7fffc4fd7 obsolete
/etc/trinity/kdeglobals 03f62af2e6af270e0cb1b9e396fc5a78 obsolete
/etc/trinity/kdm/backgroundrc e5d6fd0838cafe044f1cff0224af4b12 obsolete
Thanks for your persistence Mike, and sorry for wasting your time with this
OT followup!
Looking back through those error messages again made me take a look at
/etc/kernel/postinst.d/. It looks like in my naive effort over two years ago
when I did this installation that in order to prevent updates to menu.lst
from being created at upgrades time I renamed
/etc/kernel/postinst.d/update-grub to zz-update-grub instead of removing its
execute bits and/or making menu.lst immutable. The reason for wanting that is
in multiboot, using a master bootloader, life is simpler when kernels and
initrds in boot stanzas don't have names that change. I facilitate that
relative simplicity with manually created symlinks to fixed names initrd-cur,
vmlinuz-cur, initrd-prv, vmlinuz-prv, initrd-prv2, vmlinuz-prv2, etc. The
Debian boot menu updates process mangles boot menu file creation when it
finds kernel and initrd names that do not include version numbers, which in
turn makes chainloading to the installation's own boot menu instead of
bypassing it via master boot menu difficult if not impossible at precisely
the time it's most needed to fall back to.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/