[arch-general] SOLVED Re: Cannot chroot '/bin/bash': No such file or directory
On 03/06/2013 08:24 PM, Ross Hamblin wrote:
On 07/03/13 14:32, David C. Rankin wrote:
Guys,
Attempting to fix the test box that updating left unable to boot, I cannot chroot to fix the system. I've booted from the install medium and done the normal mount of the existing system under /mnt:
mount /dev/sda6 /mnt mount /dev/sda5 /mnt/home mount /dev/sda8 /mnt/boot mount -o bind /dev /mnt/dev mount -t proc none /mnt/proc mount -t sysfs none /mnt/sys
All files appear in their proper place under /mnt. However, attempting to create the chroot fails:
cd /mnt chroot /mnt /bin/bash
chroot: failed to run command '/bin/bash': No such file or directory
/bin/bash is in the new location /usr/bin/bash (moved from /bin/bash by the update) with with a proper symlink in /mnt/bin/bash pointing to ../usr/bin/bash
This if the first time I've ever had difficulty chrooting a system. I suspect that this is caused by the last update that pulled in systemd which left the system unbootable. Anyone know what could be causing the chroot failure? I've tried explicitly pointing the chroot to ./usr/bin/bash, etc... and tried it without any executable specified. Regardless, I get the same "No such file or directory".
Thanks in advance for any help or link you can provide.
It's been a while now but ISTR this message when chroot from 32 bit host and 64 bit target, or maybe it was vice versa.
HTH Ross.
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
[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>
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.
[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)
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
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
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 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.
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.
<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.
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
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.
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 wrote: 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: the
/lib link can safely be removed -- before it is removed by whatever There needs to be a check in the current update that checks to see whether
package update does it. Otherwise, anyone who has not updated in several months
will be
hit by the same issue. 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
[2013-03-17 15:42:55 +0200] Gesh hseG:
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.
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