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
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
|
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
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.
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.
FS#8832starting from this message: http://bugs.archlinux.org/task/8832#comment28765 for more comments,I'm trying to move that discussion here
I've seen this before, and somehow klibc-extras doesn't get put into the image....
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
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.
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...))
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.
Passé. Works fine for me since 2.6.27.x. Vanilla kernels can use the image too.