Binaries move to /usr/bin requiring update intervention

robin67 · 2013-06-03 13:22:29

I just updated succesfully as was indicated on the Latest news with the intervention

But I do wonder.....

If I now look at my filesystem I now have the following links:

lrwxrwxrwx 1 root root 7 31 mei 20:40 /bin -> usr/bin
lrwxrwxrwx 1 root root 7 31 mei 20:40 /sbin -> usr/bin
lrwxrwxrwx 1 root root 3 31 mei 20:40 /usr/sbin -> bin
lrwxrwxrwx 1 root root 7 31 mei 20:40 /bin -> usr/bin

I wonder why /usr/sbin is not pointing directly to /usr/bin but instead first to /bin (which is directed to usr/bin)

Is that intended ?

Last edited by robin67 (2013-06-03 13:28:04)

65kid · 2013-06-03 13:28:43

It's not directed to /bin, it's directed to bin (without a slash), meaning relative to the location of the symlink itself. From the point of /usr, bin is therefore /usr/bin, not /bin.

You may have to read this twice.

arojas · 2013-06-03 13:29:25

It's pointing to bin, not /bin (notice the slash). So it is correct

CaptainKirk · 2013-06-03 13:32:36

I copied and pasted the second command from the blog post but I get an error:

$ paclist <repo> | awk ' { print $1 } ' | pacman -Ql - | grep ' /s\?bin/\| /usr/sbin/'
bash: syntax error near unexpected token `|'

Am I doing something wrong?

robin67 · 2013-06-03 13:33:08

OOPS, You are both absolutely right......

robin67 · 2013-06-03 13:33:55

CaptainKirk wrote:

I copied and pasted the second command from the blog post but I get an error:
$ paclist <repo> | awk ' { print $1 } ' | pacman -Ql - | grep ' /s\?bin/\| /usr/sbin/'
bash: syntax error near unexpected token `|'
Am I doing something wrong?

replace <repo> with the name of an actual repository and you'll be fine

CaptainKirk · 2013-06-03 13:43:55

robin67 wrote:

replace <repo> with the name of an actual repository and you'll be fine

Ah, righto--I failed to notice that. I fixed that and it ran and the rest of the procedure worked like a charm.

Thank you.

bjcubsfan · 2013-06-03 13:44:45

I have a few things come up in the first query (grub 0.97 and consolekit 0.4) as packages not in a repo that need to be fixed. How should I 'fix' them? Does this mean fix something in the package or simply move the binaries to /usr/bin. How do I know what the binaries that belong to those packages are?

Scimmia · 2013-06-03 13:48:22

You fix them by getting rid of them and installing an up-to-date bootloader. Neither one has existed in the repos for months now, consolekit was replaced by logind (part of systemd) and grub 0.97 was replaced by either grub2 or syslinux.

sl1pkn07 · 2013-06-03 13:48:48

bjcubsfan wrote:

I have a few things come up in the first query (grub 0.97 and consolekit 0.4) as packages not in a repo that need to be fixed. How should I 'fix' them? Does this mean fix something in the package or simply move the binaries to /usr/bin. How do I know what the binaries that belong to those packages are?

grub2 and systemd (consolekit is replace by loginid, provided by systemd)

earlz · 2013-06-03 13:51:00

bjcubsfan wrote:

I have a few things come up in the first query (grub 0.97 and consolekit 0.4) as packages not in a repo that need to be fixed. How should I 'fix' them? Does this mean fix something in the package or simply move the binaries to /usr/bin. How do I know what the binaries that belong to those packages are?

I also am unsure on how to "fix" things. My problem is I have vmware installed, which doesn't have a package. The only things I have in /sbin is vmware related things and symlinks which I had to put there for vmware to work, as indicated by the wiki. It says I must use this command:

ln -s /usr/bin/insmod /usr/bin/lsmod /usr/bin/modinfo /usr/bin/rmmod /sbin/

Scimmia · 2013-06-03 13:58:01

Just remove those symlinks, /sbin will just be a symlink to /usr/bin after the move so they shouldn't be needed anymore.

Last edited by Scimmia (2013-06-03 14:00:04)

Sr. Ssruno · 2013-06-03 14:03:35

I have a problem updating the "filesystem" package.

# pacman -Syu --ignore filesystem,bash
# pacman -S bash

Until here, everything was Ok, but doing:

# pacman -Su

I get:

:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...
Packages (1): filesystem-2013.05-2
Total Installed Size: 0.01 MiB
Net Upgrade Size: -0.30 MiB
:: Proceed with installation? [Y/n] Y
(1/1) checking keys in keyring 100%
(1/1) checking package integrity 100%
(1/1) loading package files 100%
(1/1) checking for file conflicts 100%
error: failed to commit transaction (conflicting files)
filesystem: /usr/sbin exists in filesystem
Errors occurred, no packages were upgraded.

Looking into "/", the directories "/bin" and "/sbin" were removed. Although the directory "/usr/sbin" exists and is empty. Some clues?

Scimmia · 2013-06-03 14:05:24

If it's truly empty, just remove it.

Or, to be safe, see who it belongs to first, pacman -Qo /usr/sbin. If it belongs to more than the filesystem package, fix that package.

Last edited by Scimmia (2013-06-03 14:07:41)

Sr. Ssruno · 2013-06-03 14:12:37

Scimmia wrote:

If it's truly empty, just remove it.
Or, to be safe, see who it belongs to first, pacman -Qo /usr/sbin. If it belongs to more than the filesystem package, fix that package.

Running the command pacman -Qo /usr/sbin results:

/usr/sbin is owned by consolekit 0.4.6-4
/usr/sbin is owned by filesystem 2013.03-2
/usr/sbin is owned by hpoj 0.91-17

But I already manually moved the files located in /sbin, /bin and /usr/sbin that where referenced by this command pacman -Ql <package>. So, theoretically the "filesystem" is the only one that need attention.

Scimmia · 2013-06-03 14:16:49

See, that's one reason why just manually moving files that are owned by a package isn't a good idea. If you do it that way, you also need to fix the file list in /var/lib/pacman/local/<pkgname>. Even then, you'll have problems again when that package is updated, it's much better to just fix the offending package.

But really, why do you still have consolekit?

Last edited by Scimmia (2013-06-03 14:18:12)

Thaodan · 2013-06-03 14:24:42

For me /{sbin,bin} were empty and not owned by anyone else than filesystem. I had to remove them.

Sr. Ssruno · 2013-06-03 14:25:46

@Scimmia:
Long history... But, How I can fix the offending package? Especially the "filesystem" package that most concern.

Last edited by Sr. Ssruno (2013-06-03 14:26:25)

HalosGhost · 2013-06-03 14:27:50

Sr. Ssruno wrote:

Long history... But, How I can fix the offending package? Especially the "filesystem" package that most concern.

You don't need to fix the filesystem package. You just need to fix any non-official packages which own files in the to-be-merged directories and take care of any files not owned by any package.

All the best,

-HG

Last edited by HalosGhost (2013-06-03 14:28:33)

Scimmia · 2013-06-03 14:29:24

The filesystem package is correct, it can own that dir as it will be replaced by a symlink owned by that package so pacman is fine with it. The problem is the other two. If they use autotools, it's usually as simple as adding --sbindir=/usr/bin to the configure command.

Last edited by Scimmia (2013-06-03 14:30:24)

Sr. Ssruno · 2013-06-03 14:31:21

HalosGhost wrote:

Sr. Ssruno wrote:
Long history... But, How I can fix the offending package? Especially the "filesystem" package that most concern.
You don't need to fix the filesystem package. You just need to fix any non-official packages which own files in the to-be-merged directories and take care of any files not owned by any package.
All the best,
-HG

Thank you HalosGhost, but I'm not quite sure how to "fix it", that's why I am asking how to do it.

EDIT:
Because the "fix" that I made, was just moving the files...

Last edited by Sr. Ssruno (2013-06-03 14:32:40)

HalosGhost · 2013-06-03 14:36:00

Sr. Ssruno wrote:

Thank you HalosGhost, but I'm not quite sure how to "fix it", that's why I am asking how to do it.
EDIT:
Because the "fix" that I made, was just moving the files...

See what Scimmia wrote:

The filesystem package is correct, it can own that dir as it will be replaced by a symlink owned by that package so pacman is fine with it. The problem is the other two. If they use autotools, it's usually as simple as adding --sbindir=/usr/bin to the configure command.

He's referring here to the configure command used in the PKGBUILD for the package (assuming they use autotools). If they don't, then it may require modifying some install commands or even possibly modifying the Makefile (easiest, I find, through sed substitutions in a prepare function).

But yeah, TL;DR == You fix it by rebuilding the package.

All the best,

-HG

Last edited by HalosGhost (2013-06-03 14:36:27)

hcra · 2013-06-03 14:36:34

Step 2 of the intervention recommends

2) Make sure any packages in IgnorePkg or IgnoreGroup do not have files in /bin, /sbin, or /usr/sbin. Fix them if necessary.

It appears that I have files in these locations

[steve@arch ~]$ pacman -Ql bash
bash /bin/
bash /bin/bash
bash /bin/sh

Any recommendations how I "fix them"? Thanks!

HalosGhost · 2013-06-03 14:38:01

You have bash added to IgnorePkg or IgnoreGroup? Why‽

All the best,

-HG

Scimmia · 2013-06-03 14:38:18

Do you have bash in IgnorePkg in /etc/pacman.conf? If so, why?

Edit: Ha, HalosGhost just seems to be faster than me today.

Last edited by Scimmia (2013-06-03 14:39:40)

Arch Linux

#1 2013-06-03 13:22:29

Binaries move to /usr/bin requiring update intervention

#2 2013-06-03 13:28:43

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

#3 2013-06-03 13:29:25

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

#4 2013-06-03 13:32:36

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

#5 2013-06-03 13:33:08

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

#6 2013-06-03 13:33:55

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

#7 2013-06-03 13:43:55

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

#8 2013-06-03 13:44:45

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

#9 2013-06-03 13:48:22

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

#10 2013-06-03 13:48:48

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

#11 2013-06-03 13:51:00

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

#12 2013-06-03 13:58:01

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

#13 2013-06-03 14:03:35

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

#14 2013-06-03 14:05:24

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

#15 2013-06-03 14:12:37

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

#16 2013-06-03 14:16:49

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

#17 2013-06-03 14:24:42

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

#18 2013-06-03 14:25:46

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

#19 2013-06-03 14:27:50

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

#20 2013-06-03 14:29:24

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

#21 2013-06-03 14:31:21

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

#22 2013-06-03 14:36:00

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

#23 2013-06-03 14:36:34

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

#24 2013-06-03 14:38:01

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

#25 2013-06-03 14:38:18

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

Board footer