[arch-general] SOLVED Re: Cannot chroot '/bin/bash': No such file or directory
On 03/06/2013 08:24 PM, Ross Hamblin wrote:
All, The problem with the update (11/20/12 -> 2/5/13) appears to be that the update of filesystem (or something) removed the /lib -> /usr/lib link from the / directory causing much of the update to fail. This apparently is a problem for boxes that haven't been updated in a few months. The last system update before the one on 2/5/13 was on 11/20/12. The pacman.log contains hints of where the problem began. Specifically, from the pacman.log file I have: [2013-02-05 23:45] synchronizing package lists [2013-02-05 23:45] starting full system upgrade [2013-02-05 23:53] removed eject (2.1.5-7) [2013-02-05 23:53] userdel: user dbus is currently used by process 452 [2013-02-05 23:53] groupdel: cannot remove the primary group of user 'dbus' [2013-02-05 23:53] removed dbus-core (1.6.4-1) <snip> (don't know if this is important -- repeated twice in log) [2013-02-05 23:53] /usr/bin/gconftool-2: error while loading shared libraries: libdbus-1.so.3: cannot open shared object file: No such file or directory [2013-02-05 23:53] /usr/bin/gconftool-2: error while loading shared libraries: libdbus-1.so.3: cannot open shared object file: No such file or directory <snip> [2013-02-05 23:53] upgraded linux-api-headers (3.5.1-1 -> 3.7.4-1) [2013-02-05 23:53] upgraded tzdata (2012e-1 -> 2012j-1) [2013-02-05 23:53] warning: /etc/gshadow installed as /etc/gshadow.pacnew [2013-02-05 23:53] warning: /etc/passwd installed as /etc/passwd.pacnew [2013-02-05 23:53] warning: /etc/group installed as /etc/group.pacnew [2013-02-05 23:53] warning: /etc/fstab installed as /etc/fstab.pacnew [2013-02-05 23:53] warning: /etc/shadow installed as /etc/shadow.pacnew [2013-02-05 23:53] upgraded filesystem (2012.8-1 -> 2013.01-3) [2013-02-05 23:53] warning: /etc/locale.gen installed as /etc/locale.gen.pacnew [2013-02-05 23:53] call to execv failed (No such file or directory) [2013-02-05 23:53] upgraded glibc (2.16.0-4 -> 2.17-3) [2013-02-05 23:54] call to execv failed (No such file or directory) [2013-02-05 23:54] upgraded bash (4.2.037-1 -> 4.2.042-3) [2013-02-05 23:54] call to execv failed (No such file or directory) I don't know if it was the filesystem package or not, but after the filesystem install, there are many of the "call to execv failed (No such file or directory)" errors noted. After working with the chroot error a bit I stumbled across the fact that link for /lib was missing. After manually creating the link again, chroot worked like a champ. I don't know how much of the system got borked as a result, but a fresh pacman -Syu complete normally. I have not finished examining the system yet, so I have not attempted to boot to the new kernel. I will have to go through and verify the grub legacy config before I reboot. I'll report back after I have had an opportunity to test the box. Thank you to those that responded. -- David C. Rankin, J.D.,P.E.
On Tue, Mar 12, 2013 at 10:13 PM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote: <snip>
this is definitely related to the above "removed dbus-core (1.6.4-1)" entry. All I can say that here on my work setup with KDB (the 'B' is for bloat) I have only a dbus 1.6.8-6 package and no dbus-core.
as sysadmin of your archlinux system you should take care of pacnew files in your filesystem. I myself run # find / -xdev -regextype posix-egrep -regex '.*\.pac(new|old|save)' | less in a terminal/tmux window from time to time to find these files. In another window I then diff and add the local modifications to the pacnew files or the new additions to the old files, depending on what looks like more work. That way you also have a very good idea of what is actually going on on your system, and, of course, in archlinux on another end. That reminds me, I still have the initscripts pacsave files of which I don't know if they will ever come in handy at some point, but I'll have them lying around anyway. chers! mar77i
On 13 March 2013 04:07, Martti Kühne <mysatyre@gmail.com> wrote:
Regarding .pacnew files, there is an utility called pacdiff in the pacman-contrib package. You run it in a directory and it looks for .pacnew, .pacorig and .pacsave files. For .pacnew files, it opens up a vim window in diff mode, letting you sync files when appropriate (e.g. httpd.conf has new comments or new defaults). Upon saving, the script asks you whether you want to keep or remove the .pacnew file. It's really a time saver. -- Sébastien Leblanc
On 03/12/2013 04:13 PM, David C. Rankin wrote:
After verifying the rest of the setup and rebooting, I can verify that the entire reason for the failure was the removal of the /lib link that occurred somewhere between the update dates of 11/20/12 -> 2/5/13. The system is operating normally with the latest updates (via initscripts). There needs to be a check in the current update that checks to see whether the /lib link can safely be removed -- before it is removed by whatever package update does it. Otherwise, anyone who has not updated in several months will be hit by the same issue. At least this effects all grub legacy users when stage 1.5 control passes to the OS. Without the /lib link, everything craters. I have not attempted boot without the /lib link, but I suspect the grub legacy package cannot handle booting without it. I have moved some boxes to grub2, but on those with grub legacy, it looks like the link is still needed. And since that package is no longer maintained, it looks like the grub-legacy AUR package is the place the fix will have to be implemented. (may already be done) I don't know if there is a way to have pacman test the grub-legacy version and provide a warning and (yes/no) choice to continue update in the event an older version is found, but this seems like a reasonable way to protect all concerned.
With the latest updates installed and removal of the old dbus-core package, Trinity 3.5.13-SRU continues to work flawlessly. That is 'KDE', no 'B', there is no bloat in 3.5.13-SRU... -- David C. Rankin, J.D.,P.E.
On Fri, Mar 15, 2013 at 5:32 PM, David C. Rankin < drankinatty@suddenlinkmail.com> wrote:
On 03/12/2013 04:13 PM, David C. Rankin wrote:
There needs to be a check in the current update that checks to see whether
I don't think this link can be removed at all! It is still in `filesystem`, at least in my filesystem-2013.03-2. And it is needed by practically every program, as the default dynamic linker is set to `/lib/ld-linux.so.2`, at least in i686. Then, there is the question of how did you happen to lose this link... I don't have an answer for that. Rodrigo
Also, this move was publicized in the forums, IRC topic, mailing list and front-page news. Seriously, if you're updating a months-old system, you'd better go over the front-page news, at the very least. Gesh On Fri, Mar 15, 2013 at 11:38 PM, Rodrigo Rivas <rodrigorivascosta@gmail.com
wrote:
[2013-03-17 15:42:55 +0200] Gesh hseG:
Top-posting again?!? Feel free to spend five more seconds formatting your emails to arch-general; they get read by about two thousand people. Their combined time is definitely worth five seconds of yours. -- Gaetan
participants (6)
-
David C. Rankin
-
Gaetan Bisson
-
Gesh hseG
-
Martti Kühne
-
Rodrigo Rivas
-
Sébastien Leblanc