Hi Mike, Thanks for your answer.
Partition usage on /boot is only 25%. Enough for hosting at least 3 different initrd images. BTW, I just remember that I had briefly installed gcc-2.96-base with libstdc++5 in order to test an old software. As stated in my previous email, I've nonetheless reinstalled all the current gcc-4.1-base and related glibc and libstdc++ since then. Émeric 2007/8/23, Mike Bird <[EMAIL PROTECTED]>: > > On Wednesday 22 August 2007 15:23, Émeric Maschino wrote: > > I'm running up-to-date Debian Lenny on my hp workstation zx6000. Today, > > initramfs-tools was updated and a new initrd image was created by the > > update-initramfs script. Unfortunately, the generated initrd image > > segfaults and my system was unbootable. Using the backup copy of my > > previous initrd image, everything went fine. > > > > I initially thought that the new initramfs-tools 0.90 was broken. But > > reverting to initramfs-tools 0.89 and generating again the initrd image > > didn't solve the problem. So, something has changed on my system that > makes > > update-initramfs (being 0.89 or 0.90) produces unbootable initrd image. > The > > verbose option doesn't show any problem. > > > > Roughly one year ago, I experienced the same problem. But it was due to > > incorrect ldd binary. This doesn't seem to be the case this time, as the > > output of ldd /bin/dash is fine. By security, I've reinstalled all the > gcc, > > cpp, glibc and libstdc++ related packages. Still unbootable initrd image > > though. > > > > If it can help diagnose the problem, all the packages on my system are > .deb > > packages coming from the Debian Lenny repository, except for the Intel > > development toolchain (C compiler, debugger, math kernel library, Intel > > performance primitive library). > > How are you doing for space in /boot? I've seen several systems hosed > because they ran out of space for the initrd after something changed in > Debian to keep additional backup copies in /boot. > > --Mike Bird > >
