Bug#622828: recovery
Contrary to my earlier conclusion, the upgrade did not delete
older images. It appears a ramdisk generation change may have
included a bad module whose loading crashed the system later.
I could not boot other images because my Grub 2 configuration file
grub.cfg missed the corresponding "initrd" lines. The latter were
missing probably because of a ramdisk generation failure. This
resulted in a cryptic error message at the boot failure about
inability to find a root filesystem in a certain (0,0) disk.
As I mentioned earlier, after loading to a shell prompt by editing
the "linux" line in grub boot screen and adding init=/bin/bash, I
could disable swapping with swapoff -a, remount the root partition
in a read-write mode and start networking. This allowed me to
update packages in aptitude.
I also had to boot off a recent Debian installer CD-R disk,
http://cdimage.debian.org/cdimage/daily-builds/unstable/current/i386/iso-cd/
because I did not understand the reason for the (0,0) root disk
mount crash. I also suspect that my manual invocation of
update-initramfs failed to include all required modules.
In the end, I dropped to shell from the rescue disk, mounted my
root filesystem with "mount -t ext3 /dev/sda1 /mnt" and changed to
it with "chroot /mnt". I then re-generated the initial ramdisk
images with
update-initramfs -k 2.6.32-5-686 -d
update-initramfs -k 2.6.32-5-686 -c
and same commands for some other kernel versions. This allowed me
to boot my system in full with 2.6.32-5-686 which turned to be the
original kernel version that worked long time for me. (The newer
2.6.38..-686 kernel on which 2.6-686 depends crashes in the Wi-Fi
module mac80211 calling a function in cfg80211 when I attempt to
associate with my Wi-Fi router. I logged that issue under bug
#622833).
Still, I do not understand how possible differences in
update-initramfs could cause a libata kernel crash.
--
Reply to: