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/