On Monday 10 January 2011 12:25:00 Julien Cristau wrote:
> > The dist-upgrade failed:
> > update-initramfs: Generating /boot/initrd.img-2.6.32-5-686-bigmem
> >
> > Errors were encountered while processing:
> > vde2
> >
> > E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> You snipped the relevant earlier error message. Please attach the full
> log from the upgrade.
I don't have the full log. That's all I grabbed. I may have overlooked the
instruction to log the upgrade session. But I did back up the original root
and home, so I should be able to re-create the upgrade. I might have to re-
create /boot first; it seemed small and inconsequential at the time.
I have some new drives arriving in a few days; I can use them to re-test the
upgrade on the actual hardware. I'll try a Xen VM, in the chance the problem
is not hardware-dependent.
>
> > 1) If my IDE ZIP drive is plugged in, it is detected as /dev/sda; my
> > first SATA drive is then detected as /dev/sdb. The system panics because
> > it cannot find its partitions. For the time being, I've unplugged the
> > ZIP drive. I've not tried booting with USB drives plugged in. either
> > udev did not upgrade properly, or the rules need stweaking.
>
> Please attach /etc/fstab, and log from the error.
Fstab is attached. I cannot find a single log detailing the panic. I'll
recreate it and try to save one.
I solved this by adding the following to /etc/modprobe.d/aliases.conf
softdep ata_piix pre: ahci
softdep ata_generic pre: ahci
softdep pata_jmicron pre: ahci
softdep usb_storage pre: ahci
thereby forcing AHCI to be loaded before ATA and USB storage. With the upgrade
interrupted, I was not given the opportunity to update fstab to use the new
scheme. Which is OK, because I prefer the old way. And with ahci being loaded
first, drives are detected in a more 'correct' order.
Granted, using partition names should obviate the need for the *machine* to
detect drives in any particular order. But humans have, what, 25 years history
expecting busses and drives to be found in some mostly-consistent order. It
might be worth having an upgrade maintain the existing order. Or was my
problem a result of the upgrade not completing properly?
>
> > 2) Using X and KDE, 'transient' windows will randomly leave their images
> > behind, as though X's backing store isn't working right. Forcing a redraw
> > usually cures the problem. I've no clue where this problem might be
> > (fbdev?).
>
> Please attach the X log (/var/log/Xorg.0.log).
Attached. Seems backing store is disbaled at one time or another.
>
> > 3) I've been using my KDE user environment since Etch. It's definitely
> > time to dump it and start anew; I'll do that once I figure out how to
>
> Please file a separate bug against konqueror.
I 'cured' most of the konqueror problem by deleting
.kde/share/config/konquerorrc, .kde/share/apps/konqueror/konqueror.rc and
(most effective) .kde/share/apps/konqueror/profiles/webbrowsing. It's even
behaving itself on sites it couldn't render before. I'll file a bug about the
mis-rendering problem (once I can reduce the problem to a reasonable minimum).
>
> > 4) Evolution text drag-n-drop using the mouse doesn't work at all, and
> > drag-selection using the keyboard has very limited functionality.
>
> Please file a separate bug against evolution.
Sorry. I meant epiphany. And I'll file a bug against it.
Attachment:
Xorg.0.log.gz
Description: GNU Zip compressed data
Attachment:
fstab.gz
Description: GNU Zip compressed data