You are not logged in.
Hello folks.
To start off, here's a photo of the problem in question:
http://i.imgur.com/DReuT7Q.jpg
Now to the point: A few days, I upgraded to 3.14.0-4 the usual way (pacman -Syyu).
After rebooting, I was presented with the error in that image, As the message suggests, there was a problem, locating the kernel image. So I tried a few alternative through the grub menu. No luck there. I loaded up the Arch CD to check things out. Went on the forums/google to find out if there is a solution.
I came across a couple of very old threads relating mkinitcpio not doing its job properly. However, after trying some suggestions out, I didn't get anywhere. Eventually I decided to wipe my drives and do a fresh install. This was done 2 days ago.
All was well and good, the install went fine. Even a few reboots since then went without a hitch.
Today I upgraded to 3.14.0-5, figuring it would no longer pose any issues. But alas, here we are again.
I am out of ideas folks. Hence why I figured it was time to come to you for some much needed insight.
Edit: for the record: Grub loads up without a problem, so I figure my /boot partition is fine as far as the hardware is concerned.
-- mod edit: read the Forum Etiquette and only post thumbnails http://wiki.archlinux.org/index.php/For … s_and_Code [jwr] --
Last edited by exch2 (2014-04-19 12:01:42)
Offline
Would be nice if you told us what you have tried and what findings your research brought up. Otherwise it is hard to help you!
Some time ago I read about an issue where a missing symlink fom /lib64 -> /usr/lib caused mkinitcpio to generate not booting initramfs. Maybe thats the problem?
And I don't see where the message on your picture suggests that the kernel image could not be found...
I put at button on it. Yes. I wish to press it, but I'm not sure what will happen if I do. (Gune | Titan A.E.)
Offline
The suggestions from older (+2 years) where about various init= lines added to grub. And ensuring that /sbin/init was being invoked. None of them really have any relevance though. Arch has moved to systemd in the meantime. Currently /sbin/init seems to be a symlink to /lib/systemd/systemd. Which is present and accounted for on my system.
I am thinking I am barking up the wrong tree here, to be honest. A rundown of the activities that led to these problems lead me to believe it has nothing to do with mkinitcpio or the kernel itself.
* Upgrade to 3.14.0-4 through: pacman -Syyu
Upgrade reported no errors, but I will confess I was not exactly paying attention. Upgrades have gone without a hitch for years.
* Reboot machine -- error from picture ensues. With the sole difference being the kernel version number (xxx-4 as opposed to xxx-5).
* Wipe partitions and recreate them (/ and /boot)..
* Reinstall arch from scratch. This gave me the latest kernel (3.14.0-4) and it worked without any problems this time around. Installed X, nvidia-304xxx drivers openbox and a few of my usual tools. All went smoothy. Reboots needed after driver installs gave no problems at all. System booted without issues.
All was well until, I got a new kernel today (3.14.0-5). If the previous run is any indication, I can simply reinstall Arch and it'll be fine, but that is obviously not a reasonable solution for the long term.
I cant really give any more information than that, as I am way out of my depths here. However, if anyone has any specific requests for data. I'll be happy to supply it if I can.
Offline
Have you tried setting
init=/usr/lib/systemd/systemdparameter for the kernel in your grub config?
Offline
I have tried both "init=/sbin/init" and "init=/usr/lib/systemd/systemd". Both are present on my system, but the same error occurs on boot.
Offline
Have you seen this thread? They are talking about kernel bug there: https://groups.google.com/forum/#!msg/l … BB0BtvakwJ
(it seems 3.14 turns out to be pretty buggy...)
Offline
That looks like it may be related. Thanks!
Offline
This is an incredibly weird problem. I too encountered it this morning. Get an arch ISO on something boot up into and `arch-chroot` into your broken system.
Once you've done that, can you post the output the following code snippets for me (`wgetpaste` is quite helpful for this)
`pacman -Qkk coreutils`
`pacman -Qkk linux`
`cat /etc/mkinitcpio.conf`
`cat /etc/mkinitcpio.d/linux.preset`
Now I want you to extract the initramfs (this is what contains /init which is what is not being found/executed)
$ mkdir initramfs_extract
$ cd initramfs_extract
$ lsinitcpio -x /boot/initramfs-linux.img
$ cd ..
$ chroot initramfs_extract /bin/shIf that last command gives you an error about not finding `/bin/sh` then it's almost certain you have the same problem as me. You can then install `tree` and post the output of `tree initramfs_extract`.
You should also install `strace` and post the output of `strace chroot initramfs_extract /bin/sh`
For some reason my initramfs' weren't being produced with the proper files in /lib64 therefore you ended up not having `ld-linux-x86-64.so.2` included which is required to load `/bin/sh`
Offline
Thanks for the input. I had to reinstall my system again, because it needs to do work. However, I expect that with the next kernel upgrade, I will be having the same problem again. I'll be sure to do what you suggested and report back here.
Offline
I had a similar problem as yours recently, except that my system freezed completely just before initializing desktop environment, given only blinking cursor without any output at the top left corner. The keyboard then becomes unresponsive as well. I managed to downgrade my kernel back to 3.13 and switch from nvidia proprietary to nouveau driver using a live media and now it works fine (kernel vs VGA driver issue?). I don't want to stuck with 3.13 kernel forever so I'll probably wait for next kernel version and try to upgrade again.
Offline
@whitekoffee, that sounds like a different problem to the one outlined here, there are several thread related to what you're experiencing though:
https://bbs.archlinux.org/viewtopic.php?id=180041
https://bbs.archlinux.org/viewtopic.php?id=179903
https://bbs.archlinux.org/viewtopic.php?id=179849
https://bbs.archlinux.org/viewtopic.php?id=179829
Offline
I upgraded again today. Have not rebooted yet, so I am unsure what's going to happen.
However, I did try out your suggestions in my current installation (3.14.0-5) and the error abot /bin/sh not being found does occur when running `chroot initramfs_extract /bin/sh`.
I will be rebooting shortly. If things go wrong, I'll get back here with the appropriate logs.
Offline
@will.price94: As expected, things went wrong again.
Here are the log files: http://bpaste.net/show/215530/
The chroot command failed with the error:
$ chroot initramfs_extract/ /bin/sh
chroot: failed to run command '/bin/sh': No such file or directory
$ file /bin/sh
/bin/sh: symbolic link to 'bash'The tree log: http://bpaste.net/show/215572/
The strace log: http://bpaste.net/show/215578/
Last edited by exch2 (2014-04-19 10:24:39)
Offline
OK, that's what happened to me too. `bash` shouldn't be present in your initramfs, it should be using busybox so `sh` should be symlinked to `/bin/ash` or `/bin/busybox` (I forget which it points to).
If you run
$ readelf -l extracted_initramfs/bin/shit will let us know which interpreter the the `sh` executable is requesting, it is likely this that isn't present in your initramfs which stops it from booting.
Could you also post the output of...
$ pacman -Qkk glibc
$ pacman -Qkk mkinitcpio{,-busybox}
$ pacman -Qkk filesystemOffline
The readelf output: http://bpaste.net/show/215615/
The pacman output: http://bpaste.net/show/215617/
Offline
warning: filesystem: /usr/lib64 (File type mismatch)I'm betting this is the cause of the problem. What's the output of
$ file /usr/lib64If it's a symlink, delete it and reinstall filesystem and regenerate the initramfs, if you can chroot into the extracted image then you'll almost certainly be able to reboot.
Offline
$ file /usr/lib64
/usr/lib64: directoryIt's not a symlink it seems.
Offline
That's interesting, it's a symlink on my system. mv the contents over to /usr/lib, delete the folder and then add add a symlink pointing toward lib:
# ln -s lib lib64 Offline
Holy hannah. That seemed to work.
As suggested, I turned /usr/lib64 into a symlink to /usr/lib
Then rebuilt the initramfs
mkinitcpio -p linuxThis seemed to do the trick. The system boots again.
Offline
I have no idea why lib64 would be a folder instead of a symlink o.O. Perhaps a dev can shed light on what might have caused this. Anyway... we have a fix for it!
Offline
I'm trying to think of when and how this might have happened, but I'm coming up empty. Specially considering it happened with multiple kernels, each after a completely fresh install.
Anyway, thanks for the help! Much appreciated.
Offline
No problem. Paying forward the help I got off #ArchLinux guys!
Offline
Actually... I guess mkinicpio wasn't looking inside of /usr/lib64 as it would expect all the contents to be in /usr/lib if /usr/lib64 was indeed a symlink. It'd then not find the files it needed to successfully generate a working initramfs. I don't know if this is the case, I could look at the source code, but don't have time to at the moment.
Offline
I think I found the culprit in my case. The installation script for FirebirdSQL consistently changes /usr/lib64 from a symlink into a directory.
I recently started experimenting with this package for some work. I wasn't entirely sure if I started doing this after the first time my system died, or before. Otherwise I would have considered this for a possible culprit much sooner. Frankly, my system breaking again and again should have been a hint.
To test it out, I just re-installed it and behold; the directory magically returned!
$ file /usr/lib64
/usr/lib64: symbolic link to `/usr/lib'
$ sudo ./install.sh
....
....
$ file /usr/lib64
/usr/lib64: directory
$ ls -lah /usr/lib64/
total 8.0K
drwxr-xr-x 2 root root 4.0K Apr 20 01:54 .
drwxr-xr-x 9 root root 4.0K Mar 19 2013 ..
lrwxrwxrwx 1 root root 32 Mar 19 2013 libfbclient.so -> /opt/firebird/lib/libfbclient.so
lrwxrwxrwx 1 root root 34 Mar 19 2013 libfbclient.so.2 -> /opt/firebird/lib/libfbclient.so.2
lrwxrwxrwx 1 root root 38 Mar 19 2013 libfbclient.so.2.5.2 -> /opt/firebird/lib/libfbclient.so.2.5.2
lrwxrwxrwx 1 root root 31 Mar 19 2013 libfbembed.so -> /opt/firebird/lib/libfbembed.so
lrwxrwxrwx 1 root root 35 Mar 19 2013 libfbembed.so.2.5 -> /opt/firebird/lib/libfbembed.so.2.5
lrwxrwxrwx 1 root root 37 Mar 19 2013 libfbembed.so.2.5.2 -> /opt/firebird/lib/libfbembed.so.2.5.2
lrwxrwxrwx 1 root root 31 Apr 20 01:54 libgds.so -> /opt/firebird/lib/libfbembed.so
lrwxrwxrwx 1 root root 31 Apr 20 01:54 libgds.so.0 -> /opt/firebird/lib/libfbembed.so
lrwxrwxrwx 1 root root 31 Mar 19 2013 libib_util.so -> /opt/firebird/lib/libib_util.soAs is evident, these are all firebird related.
I've been going through the install.sh script they supply in the package. Apart from some library symlinks being created in /usr/lib64/ I can't really find a reason for this behaviour. But some more thorough examination of what the script does is in order. I will likely be filing some bug reports in the appropriate place.
Offline
Nice bug finding exch2! I've never heard of that package, so I doubt that caused it in my case. I do believe I was building some stuff from source around that time so it could have caused the problem.
Offline