Binaries move to /usr/bin requiring update intervention

WorMzy · 2013-06-04 11:51:41

It doesn't say that you should delete them in the news article on the front page, and the symlinks themselves are the cause of the upgrade failures in the first place. Why would you go through the trouble of installing these symlinks only to delete them afterwards? :s

ZeroLinux · 2013-06-04 12:19:14

crazyg4merz wrote:

that means they shouldn't be deleted, so why some people say delete them?

If you are not sure just rename it to /sbin_delme /bin_delme and /usr/sbin_delme
It will allow you to make

sudo pacman -S filesystem

After reboot you'll delete all *_delme folders

Last edited by ZeroLinux (2013-06-04 12:19:33)

gabu · 2013-06-04 12:23:36

Sorry, but I am at a complete loss as to what my problem is.

On trying to upgrade I get this message:

error: failed to commit transaction (conflicting files)
filesystem: /bin exists in filesystem
filesystem: /sbin exists in filesystem
filesystem: /usr/sbin exists in filesystem
Errors occurred, no packages were upgraded.

Followed step 1) but nothing found:

[root(0)archlinux:test]# pacman -Qqo /bin /sbin /usr/sbin | pacman -Qm -
[root(0)archlinux:test]#

The only repos I use are core, extra, community, multilib
Yaourt says I have 32 packages from AUR

Step 2) doesn't apply as I have no ignored packages/groups in pacman.conf

Followed step 3) but nothing found:

[root(0)archlinux:test]# find /bin /sbin /usr/sbin -exec pacman -Qo -- {} + >/dev/null
[root(0)archlinux:test]#

I checked the ownership on the 3 directories:

[root(5)archlinux:test]# pacman -Qo /usr/sbin
/usr/sbin is owned by bluez 4.101-1
/usr/sbin is owned by cdrkit 1.1.11-2
/usr/sbin is owned by cryptsetup 1.6.1-1
/usr/sbin is owned by device-mapper 2.02.98-3
/usr/sbin is owned by dhclient 4.2.5-1
/usr/sbin is owned by dhcpcd 5.6.8-1
/usr/sbin is owned by e2fsprogs 1.42.7-1
/usr/sbin is owned by filesystem 2013.03-2
/usr/sbin is owned by gconf 3.2.6-1
/usr/sbin is owned by glibc 2.17-5
/usr/sbin is owned by iproute2 3.9.0-1
/usr/sbin is owned by libatasmart 0.19-1
/usr/sbin is owned by libbonobo 2.32.1-3
/usr/sbin is owned by libsasl 2.1.26-3
/usr/sbin is owned by lsof 4.87-1
/usr/sbin is owned by lvm2 2.02.98-3
/usr/sbin is owned by modemmanager 0.7.990-4
/usr/sbin is owned by networkmanager 0.9.8.0-3
/usr/sbin is owned by pm-utils 1.4.1-5
/usr/sbin is owned by ppp 2.4.5-5
/usr/sbin is owned by rtmpdump 20121203-1
/usr/sbin is owned by shadow 4.1.5.1-5
/usr/sbin is owned by udisks2 2.1.0-2
/usr/sbin is owned by usbmuxd 1.0.8-1
/usr/sbin is owned by util-linux 2.23.1-1
/usr/sbin is owned by v4l-utils 0.9.5-1
/usr/sbin is owned by wpa_supplicant 2.0-3
/usr/sbin is owned by zvbi 0.2.33-5
[root(5)archlinux:test]# pacman -Qo /sbin
/sbin is owned by dhclient 4.2.5-1
/sbin is owned by dhcpcd 5.6.8-1
/sbin is owned by e2fsprogs 1.42.7-1
/sbin is owned by fuse 2.9.2-1
/sbin is owned by glibc 2.17-5
/sbin is owned by iproute2 3.9.0-1
/sbin is owned by kmod 13-1
/sbin is owned by net-tools 1.60.20120804git-2
/sbin is owned by shadow 4.1.5.1-5
/sbin is owned by systemd 204-2
/sbin is owned by systemd-sysvcompat 204-2
/sbin is owned by sysvinit-tools 2.88-10
/sbin is owned by util-linux 2.23.1-1
[root(5)archlinux:test]# pacman -Qo /bin
/bin is owned by bash 4.2.045-1
/bin is owned by coreutils 8.21-1
/bin is owned by fuse 2.9.2-1
/bin is owned by inetutils 1.9.1-5
/bin is owned by net-tools 1.60.20120804git-2
/bin is owned by sed 4.2.2-2
/bin is owned by shadow 4.1.5.1-5
/bin is owned by sysvinit-tools 2.88-10
/bin is owned by tar 1.26-3
/bin is owned by util-linux 2.23.1-1
[root(5)archlinux:test]#

So what do I do now?

WorMzy · 2013-06-04 12:36:20

@gabu: As far as I can tell, you should be fine proceeding with the upgrade.

If you're getting any errors during step 5), post them here.

gabu · 2013-06-04 12:46:10

This is the problem, if I try to run pacman -Su I still get the error message about conflicting files and the 3 directories listed.

WorMzy · 2013-06-04 12:52:15

So everything except the filesystem package is currently up to date? If that's the case, then your mirror is out-of-date, try switching to a different one and run 'pacman -Syy'. Then try again, from the start of step 5).

gabu · 2013-06-04 13:04:13

There are 47 packages that it is trying to update.

I switched servers from United Kingdom to Germany, ran pacman -Syy then pacman -Su and still got the error message.

Last edited by gabu (2013-06-04 13:05:52)

WorMzy · 2013-06-04 13:08:18

gabu wrote:

There are 47 packages that it is trying to update.

You haven't followed the instructions then. Re-read the news post: https://www.archlinux.org/news/binaries … ervention/

The 'pacman -Su' command is the last thing you do, after everything except the filesystem package is up-to-date.

Last edited by WorMzy (2013-06-04 13:08:33)

gabu · 2013-06-04 13:18:36

I thought I was following the instructions but your comment made me reread them and when I followed those last 3 steps (which I thought were only linked to having another optional terminal open, which I didn't have) everything worked!

Sorry to be so thick. Thanks for the help.

crazyg4merz · 2013-06-04 15:20:56

WorMzy wrote:

It doesn't say that you should delete them in the news article on the front page, and the symlinks themselves are the cause of the upgrade failures in the first place. Why would you go through the trouble of installing these symlinks only to delete them afterwards? :s

because I thought the purpose of this upgrade is to make the filesystem cleaner. but it won't be clean if we have so many symlinks which are like "dirtying" the root folder. I'm fine with it though if we don't have to delete them, but if I can get rid of them without having any problem I'll definitely gonna delete them :-)

Last edited by crazyg4merz (2013-06-04 15:21:46)

Scimmia · 2013-06-04 15:22:31

You can't. You delete them, your system won't boot.

WorMzy · 2013-06-04 15:34:02

It makes it cleaner for packagers, e.g. binaries simply go into /usr/bin instead of four different directories. From a user perspective, the filesystem will remain as cluttered as it always has been.

joetotale · 2013-06-04 15:58:37

Before reading this thread, I foolishly and manually:
i - moved the contents of /bin, /sbin and /usr/sbin into /bin.
ii - deleted the three folders, leavin /bin
iii - tried to create symlink to /bin

(I know... what was I thinking?)

Attempting pacman -Syu --ignore filesystem,bash returns:

error: failed to commit transaction (conflicting files)
autofs: /usr/bin/automount exists in filesystem
glibc: /usr/bin/iconvconfig exists in filesystem
...

Can anyone advise how I should proceed?

Red-faced,
Joe

ZeroLinux · 2013-06-04 16:20:33

joetotale wrote:

Before reading this thread, I foolishly and manually:
i - moved the contents of /bin, /sbin and /usr/sbin into /bin.
ii - deleted the three folders, leavin /bin
iii - tried to create symlink to /bin
(I know... what was I thinking?)
Attempting pacman -Syu --ignore filesystem,bash returns:
error: failed to commit transaction (conflicting files)
autofs: /usr/bin/automount exists in filesystem
glibc: /usr/bin/iconvconfig exists in filesystem
... 
Can anyone advise how I should proceed?
Red-faced,
Joe

Try pacman with --force option

joetotale · 2013-06-04 16:26:23

Thank you, Zerolinux!

Scimmia · 2013-06-04 16:45:04

DO NOT USE -Syu --force!!!!

andrej.podzimek · 2013-06-04 17:37:29

Scimmia wrote:

DO NOT USE -Syu --force!!!!

Do not use the entire howto at all! You can easily end up with a completely broken system: https://bugs.archlinux.org/task/35645

At least there should have been a big red warning never ever do this over SSH, becakuse you'll need to reinstall the machine afterwards.

Scimmia · 2013-06-04 17:40:28

Nope, almost certainly user error. See my comment in the bug and this thread: https://bbs.archlinux.org/viewtopic.php?id=164458

Last edited by Scimmia (2013-06-04 17:41:20)

hazard · 2013-06-04 18:00:32

ZeroLinux wrote:

Where I can find all of them to put them into /usr/bin manually?

In your case following the instructions to upgrade except bash and filesystem should work.

As for me, I have a lot of packages from the Mate repo and AUR to deal with. This is convoluted but works:

pacman -Qo /bin/* /sbin/* /usr/sbin/* | grep -E "$(echo $(pacman -Qqo /bin /sbin /usr/sbin | pacman -Qm - | awk '{print $1}') | sed -e 's/ /|/g' -e 's/^/(/g' -e 's/$/)/g')"

jasonwryan · 2013-06-04 18:12:27

ZeroLinux wrote:

Try pacman with --force option

This is certainly the most stupid piece of advice yet offered here. If you don't know what you are doing--and clearly you don't--then just keep out of this thread...

Scimmia · 2013-06-04 18:16:57

andrej.podzimek wrote:

I have only one 'autofs' equivalent, the x-systemd.automount on /boot, but I'm pretty sure that must have got mounted during the two initial steps, simply because also the kernel got updated...
However, now I cannot cd into /boot and it looks as if it was not mounted any more. (The only way to investigate this now is 'echo *' and 'cd', because no commands are available.)
Where can I find the files from /usr/bin? That directory is obviously filled with invalid symlinks (echo * shows them, but ./something says "file not found"). If I can find the binaries, then I can (try to) fixe this somehow. But that can't be done without ls, ps, mount and the usual commands...

Quoted from the (now closed) bug report.

Andrej, if you did "pacman -Syu --ignore filesystem,bash", everything should now be in /usr/bin except bash and sh symlinks in /bin.

It's sounding to me like you moved things manually? If so, exactly what did you do?

ewaller · 2013-06-04 18:24:49

andrej.podzimek wrote:

Do not use the entire howto at all! You can easily end up with a completely broken system: https://bugs.archlinux.org/task/35645
At least there should have been a big red warning never ever do this over SSH, becakuse you'll need to reinstall the machine afterwards.

Oh, contraire: https://bbs.archlinux.org/viewtopic.php … 7#p1282077

Last edited by ewaller (2013-06-04 18:59:21)

derhamster · 2013-06-04 18:50:10

I wonder how some people got the impression to manually move files and create symlinks and all that. Even if the news on the front page was ambiguous (which it is not imo), shouldn't it be clear, that this is pacmans job to do?
But it seems to me this update produces much less noise than the lib move, which is good I guess.

HalosGhost · 2013-06-04 18:56:40

kriz, the AUR isn't a repository in the same sense as the official repos. The first command given (which includes `pacman -Qm -`) will show AUR packages.

Sorry about that clearly outdated reply. I'm clearly failing to see the extra pages of replies.

All the best,

-HG

Last edited by HalosGhost (2013-06-04 18:58:19)

rg_arc · 2013-06-05 02:03:33

So I get this output after doing the command from the front page. I went ahead and removed the two files I could find in /sbin.. maybe not the most prudent thing to do but I don't use these packages anyways. I couldn't find anything else related to these packages and I tried to pacman -R those packages and they weren't found anywhere. How can I get rid of the error messages for these packages?

$ pacman -Qqo /bin /sbin /usr/sbin | pacman -Qm -
consolekit 0.4.6-4
privoxy-blocklist 0.2-2

Arch Linux

#101 2013-06-04 11:51:41

Re: Binaries move to /usr/bin requiring update intervention

#102 2013-06-04 12:19:14

Re: Binaries move to /usr/bin requiring update intervention

#103 2013-06-04 12:23:36

Re: Binaries move to /usr/bin requiring update intervention

#104 2013-06-04 12:36:20

Re: Binaries move to /usr/bin requiring update intervention

#105 2013-06-04 12:46:10

Re: Binaries move to /usr/bin requiring update intervention

#106 2013-06-04 12:52:15

Re: Binaries move to /usr/bin requiring update intervention

#107 2013-06-04 13:04:13

Re: Binaries move to /usr/bin requiring update intervention

#108 2013-06-04 13:08:18

Re: Binaries move to /usr/bin requiring update intervention

#109 2013-06-04 13:18:36

Re: Binaries move to /usr/bin requiring update intervention

#110 2013-06-04 15:20:56

Re: Binaries move to /usr/bin requiring update intervention

#111 2013-06-04 15:22:31

Re: Binaries move to /usr/bin requiring update intervention

#112 2013-06-04 15:34:02

Re: Binaries move to /usr/bin requiring update intervention

#113 2013-06-04 15:58:37

Re: Binaries move to /usr/bin requiring update intervention

#114 2013-06-04 16:20:33

Re: Binaries move to /usr/bin requiring update intervention

#115 2013-06-04 16:26:23

Re: Binaries move to /usr/bin requiring update intervention

#116 2013-06-04 16:45:04

Re: Binaries move to /usr/bin requiring update intervention

#117 2013-06-04 17:37:29

Re: Binaries move to /usr/bin requiring update intervention

#118 2013-06-04 17:40:28

Re: Binaries move to /usr/bin requiring update intervention

#119 2013-06-04 18:00:32

Re: Binaries move to /usr/bin requiring update intervention

#120 2013-06-04 18:12:27

Re: Binaries move to /usr/bin requiring update intervention

#121 2013-06-04 18:16:57

Re: Binaries move to /usr/bin requiring update intervention

#122 2013-06-04 18:24:49

Re: Binaries move to /usr/bin requiring update intervention

#123 2013-06-04 18:50:10

Re: Binaries move to /usr/bin requiring update intervention

#124 2013-06-04 18:56:40

Re: Binaries move to /usr/bin requiring update intervention

#125 2013-06-05 02:03:33

Re: Binaries move to /usr/bin requiring update intervention

Board footer