Re: [arch-general] SOLVED Re: Cannot chroot '/bin/bash': No such file or directory

2013-03-17 Thread 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.

Gesh


On Fri, Mar 15, 2013 at 11:38 PM, Rodrigo Rivas rodrigorivasco...@gmail.com
 wrote:

 On Fri, Mar 15, 2013 at 5:32 PM, David C. Rankin 
 drankina...@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



Re: [arch-general] SOLVED Re: Cannot chroot '/bin/bash': No such file or directory

2013-03-17 Thread Gaetan Bisson
[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


Re: [arch-general] SOLVED Re: Cannot chroot '/bin/bash': No such file or directory

2013-03-15 Thread David C. Rankin
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.


Re: [arch-general] SOLVED Re: Cannot chroot '/bin/bash': No such file or directory

2013-03-15 Thread Rodrigo Rivas
On Fri, Mar 15, 2013 at 5:32 PM, David C. Rankin 
drankina...@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


Re: [arch-general] SOLVED Re: Cannot chroot '/bin/bash': No such file or directory

2013-03-13 Thread Sébastien Leblanc
On 13 March 2013 04:07, Martti Kühne mysat...@gmail.com wrote:
 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