Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#11757 - mkinitcpio produces faulty initcpio files

Attached to Project: Arch Linux
Opened by Andrej Podzimek (andrej) - Wednesday, 15 October 2008, 20:45 GMT
Last edited by Thomas Bächler (brain0) - Sunday, 07 December 2008, 18:39 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture i686
Severity Critical
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:

mkinitcpio produces faulty initramdisk.
I thought it could be a strange klibc version mismatch: http://bbs.archlinux.org/viewtopic.php?id=57039
However, after updating all the klibc stuff, it produced an unusable ramdisk that is not readable by the kernel and causes a panic.
This happened on a distant server, so I don't have the exact messages handy.

Additional info:

* package version(s)
* config and/or log files etc.

see the bb thread, please (http://bbs.archlinux.org/viewtopic.php?id=57039)

Steps to reproduce:

2.6.26.5 vanilla kernel (and just about any kernel version in the past two years) worked fine with mkinitcpio. 2.6.26.6 fails. Just try to make a ramdisk with mkinitcpio and use it with a vanilla kernel.
This task depends upon

Closed by  Thomas Bächler (brain0)
Sunday, 07 December 2008, 18:39 GMT
Reason for closing:  None
Comment by Aristóteles Soares Benício (asbenicio) - Thursday, 16 October 2008, 01:04 GMT
I observe this in i686 distribution (GigaByte MOBO GA...945) but not in x86_64 distribution in my notebook ASUS T12UG.

I get the same error when the kernel 2.6.27 was in community. Today it was moved to core and the error was repeated. Between one and other "googling" I try many things. My workaround for this:

1- Before I upgrade the system I copy the kernel26 and vmlinuz files in /boot with other name;
2- Run <pacman -Syu>;
3- If you get error em klibc, then remove it with Pacman. Reinstall it and do <pacman -Syu>;
4- Reboot and, in GRUB screen, edit the boot lines changing the names of kernel and vmlinuz to the old (copied in step 1);
5- If the boot can finalize (with minor errors probably) then run <pacman -Sy kernel26>;
6- Reboot

Hope that it can help someone.

Comment by Andrej Podzimek (andrej) - Thursday, 16 October 2008, 02:08 GMT
It is surprising that the same error occurs despite all the differences:

1) I do not use the ArchLinux kernel.
2) I do not use GRUB.
3) The kernel that failed was 2.6.26.6, not 2.6.27.

This is a weird problem. When a program cannot be found, although it is obviously available, there must be something wrong with the loader.
Comment by Roman Kyrylych (Romashka) - Sunday, 19 October 2008, 14:46 GMT
see  FS#8832  starting from this message: http://bugs.archlinux.org/task/8832#comment28765 for more comments,
I'm trying to move that discussion here
Comment by Thomas Bächler (brain0) - Sunday, 19 October 2008, 18:18 GMT
Pleae upload a broken initramfs image as an attachment.
Comment by Aaron Griffin (phrakture) - Monday, 20 October 2008, 19:57 GMT
Also, could you post the file generated by the -s argument (mkinitcpio ... -s filelist.txt ...)?

I've seen this before, and somehow klibc-extras doesn't get put into the image....
Comment by Brett Williams (vor_lord) - Thursday, 23 October 2008, 08:56 GMT
Not an expert so I do not fully understand all this, but I'm having this problem. I have attached my kernel26.img that I currently have. This file was created using my older 2.6.24 installation, chrooted to the newer install (which died going from 2.6.26.5 to 2.6.27.1). Hopefully that is what has been asked for.
Comment by Andrej Podzimek (andrej) - Thursday, 23 October 2008, 09:37 GMT
This is the image where replace was „missing“. As for the image that failed completely, I don't have the file any more.
Comment by Thomas Bächler (brain0) - Thursday, 23 October 2008, 19:43 GMT
There is the same error for both of you: By the time the image was generated, the klibc-extras version did not match the klibc package. Make sure all your klibc stuff is fully upgraded to the latest version. This error should not be possible any more once you upgraded to recent versions of all packages due to a stricter dependency checking. Here is the list of the current versions:

klibc 1.5.14-1 (base)
klibc-extras 2.5-1
klibc-kbd 1.15.20080312-7
klibc-module-init-tools 3.4-2
klibc-udev 130-1
Comment by Brett Williams (vor_lord) - Friday, 24 October 2008, 04:14 GMT
Those are the versions that I thought I installed. But now I see that what is installed for klibc is indeed older (even though I had downloaded the new package). The new package will not install due to file conflicts (dependencies must be messed up which is what started all this), but do with -f.

I've attached the output of mkinitcpio -s in case this doesn't work (I haven't attempted to reboot yet), but it appears to contain the missing files.
Comment by Brett Williams (vor_lord) - Friday, 24 October 2008, 04:35 GMT
Thanks for your help, this fixed the problem for me!
Comment by Andrej Podzimek (andrej) - Friday, 24 October 2008, 08:11 GMT
When I reinstalled all the klibc packages, it produced a mkinitcpio that caused a different kernel panic, complaining about wrong archive format. Tried both reinstalling klibc-* from binary repositories or recompiling it from ABS, but nothing helped.

Unfortunately, I do not have the failed image any more and cannot reboot that server too often. Will try again with a 2.6.27.x kernel on next regular downtime. What I know for sure: it is impossible to make an image that would work with a 2.6.26.6 vanilla kernel.

Perhaps klibc has been updated to work with 2.6.27.x only. (Which could shed more light on why the loader fails, producing a hardly understandable message about the missing replace command. (It does explain the second kind of panic, however...))
Comment by Thomas Bächler (brain0) - Friday, 24 October 2008, 09:14 GMT
1) The wrong archive format must be an error during the cpio or gzip, as it is not about the contents of the archive, but the archive itself. Or, maybe, lilo failed after all.
2) Do not build klibc-* from ABS. You have to be very careful about what you are doing and you are more likely to screw up than actually fix something.
3) Current klibc is built against the 2.6.26 headers, thus should be compatible with 2.6.26. I think it should even be backwards-compatible to older kernels, unless you try to use new features that are in .26 and newer only.
4) The message about replace means the following: When the replace ELF header is read, it is looking for its interpreter. The interpreter is /lib/klibc-verylongstring.so, but this file does not exist, instead, only /lib/klibc-differentverylongstring.so exists, thus the "File not found". This interpreter is /lib/ld-linux.so.2 in the case of glibc, but klibc has no dynamic linker and no stable ABI, thus it needs the exact version.
Comment by Glenn Matthys (RedShift) - Saturday, 06 December 2008, 12:42 GMT
What's the status of this issue?
Comment by Andrej Podzimek (andrej) - Saturday, 06 December 2008, 14:49 GMT
> What's the status of this issue?

Passé. Works fine for me since 2.6.27.x. Vanilla kernels can use the image too.

Loading...