Weitergeleitete Nachricht: Sorry, wrong order of messages, because I failed to copy the address correctly, so I failed again to include the BTS in the recipients of this mail. Am Sun, 6 Sep 2009 23:31:03 +0200 schrieb maximilian attems <max@stro.at>: > [ keep bug report on cc, this is not a private conversation, thanks ] Oh, I actually wanted to answer to the bug report system, I missed this, sorry. > On Sun, 06 Sep 2009, Christoph Franzen wrote: > > > Am Sat, 5 Sep 2009 17:32:30 +0200 schrieb maximilian attems > > <max@stro.at>: > > > > Hello, your native language seems to be german like mine, > > mapping the tld to the native language of it's owner is likely faulty. I also considered the name, "Maximilian" could be austrian as well. I wasn't sure about "Attems" this seems indeed not "typical". > > On Fri, Sep 04, 2009 at 08:11:10PM +0200, Christoph Franzen wrote: [...] > > In fact, any RAM disk I created after december/january has been > > faulty, and I think to have found evidence that the problem is the > > last update of "initramfs-tools" in january or february to 0.92o. > > what did you change at that time? I updated some packages at least, I don't remember if this was the upgrade from Etch to Lenny, but it's possible. Unfortunately it's all happened a long time ago, but I know that the Initramfs-Tools were updated to the current version around this time. I remember for sure that the upgrade to Lenny failed to boot with the same problem; I did not care, because the 2.6.25 kernel continued to boot as before, I simply used that and hoped that the problem would go away with the next kernel update, but it did not. I had some filesystem damage recently, and I've chosen to regenerate the RAM disks and reinstalled importand packages to be sure that nothing important is damaged. > > ++ echo /usr/local/lib/i686/cmov/libc.so.6 > > + nonoptlib=/usr/local/lib/libc.so.6 > > you seem to have a funny place for your local libc package Thanks, I did not notice these lines. It is not there, only some files I copied there manually for a program which needed another library version. This was at "Etch times", and I've never tried to remove them: "/usr/local/lib/": drwxrwsr-x 3 root staff 4096 15. Mär 2008 i686 lrwxrwxrwx 1 root staff 38 11. Aug 2008 ld-linux.so.2 -> /usr/local/lib/i686/cmov/ld-linux.so.2 -rw-r--r-- 1 boinc boinc 282652 30. Jun 18:47 libcudart.so lrwxrwxrwx 1 boinc video 12 19. Jan 2009 libcudart.so.2 -> libcudart.so -rw-r--r-- 1 root root 49644 2. Mär 2008 libgcc_s.so.1 lrwxrwxrwx 1 root staff 19 11. Aug 2008 libstdc++.so.6 -> libstdc++.so.6.0.10 -rw-r--r-- 1 root root 946216 2. Mär 2008 libstdc++.so.6.0.10 drwxrwsr-x 3 root staff 4096 30. Aug 03:32 python2.5 drwxr-sr-x 3 root staff 4096 30. Aug 02:55 site_ruby "/usr/local/lib/i686/cmov/": -rwxr-xr-x 1 root root 121440 29. Nov 2007 ld-2.7.so lrwxrwxrwx 1 root staff 9 11. Aug 2008 ld-linux.so.2 -> ld-2.7.so -rwxr-xr-x 1 root root 1356196 29. Nov 2007 libc-2.7.so lrwxrwxrwx 1 root staff 11 11. Aug 2008 libc.so.6 -> libc-2.7.so -rw-r--r-- 1 root root 149328 29. Nov 2007 libm-2.7.so lrwxrwxrwx 1 root staff 11 11. Aug 2008 libm.so.6 -> libm-2.7.so -rwxr--r-- 1 root root 112354 29. Nov 2007 libpthread-2.7.so lrwxrwxrwx 1 root staff 17 11. Aug 2008 libpthread.so.0 -> libpthread-2.7.so > what shows belows? > dpkg -l libc6 Name Version Beschreibung ii libc6 2.7-18 GNU C Library: Shared libraries (Line drawings removed) I now think that "mkinitramfs" might be confused by finding this local version in the library path. This is not a complete libc installation, but contains only those manually copied files from a Lenny system which a failing application required. The machine is my server for automatic backups at home. At the time when I installed the files the machine was running Etch. I wanted to use its idle time for running BOINC projects, but some of the scientific applications were linked against glibc 2.7. I investigated this, and managed to run it with locally installed copies of libc files of my Lenny system. After that I reported this to the BOINC project, who provides a statically linked program now as I suggested. Before, they had simply chosen a libc version which accidentally matched most current desktop systems at that time. I've always suspected that there must be some local weirdness involved... However, I think that Lenny definitely should "survive" locally installed files without such failures, and use the libraries which the libc package provides. Only if these are not available it should look at local alternatives. At least it should not assume to find a "/usr/local/lib/libc.so.6" just because some ather files are actually there. Perhaps it's more complicated, but I will now try the following: 1) Move all of the local libc files out of the way. 2) Regenerate the cache stuff. 3) Try again to generate a RAM disk. I should have removed the files anyway, because Lenny has the required version, but I've forgotten that. Unfortunately their presence could have prevented an upgrade to Lenny leaving the system unbootable. Because the behaviour in this regard was better before the upgrade (I could generate a working initramfs despite of the local libraries being installed), I think this should be changed in future versions of the generation programs if it turns out that the test above succeeds. Regards, Christoph
Attachment:
signature.asc
Description: PGP signature