Binaries move to /usr/bin requiring update intervention

wilberfan · 2013-06-05 20:32:10

Jeez, I completely misinterpreted the instructions.

5) Update your system.
Before performing this update, you may want to ensure you have a second terminal open with root privileges in the unlikely event of an emergency, particularly if updating over ssh.
# pacman -Syu --ignore filesystem,bash
# pacman -S bash
# pacman -Su

I thought "5) Update your system" meant "run pacman -Syu, then, *only if you have problems*, run the three pacman commands below in a separate rooted terminal..."

Yikes. Duh. Obviously time to take a break...!

What they meant (of course) was "5) update your system by running the follow three commands.

When I followed the directions (correctly!!), I got a message about profile--I'm wondering if I need do anything in response to that message?

# pacman -Su
:: Starting full system upgrade...
warning: transmission-cli: ignoring package upgrade (2.42-2 => 2.77-3)
warning: transmission-gtk: ignoring package upgrade (2.42-2 => 2.77-3)
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%
(1/1) checking available disk space                [######################] 100%
(1/1) upgrading filesystem                         [######################] 100%
warning: /etc/profile installed as /etc/profile.pacnew

Should I save the /etc/profile.pacnew over the existing /etc/profile?

[edit] On examining the two files, the only difference seems to be in the PATH=

/etc/profile:

PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin"

/etc/profile.pacnew:

PATH="/usr/local/sbin:/usr/local/bin:/usr/bin"

Is there anything in the /etc/profile PATH that is counterproductive given the updates?

Last edited by wilberfan (2013-06-05 20:40:05)

ball · 2013-06-05 21:16:27

Well, as /bin, /sbin, and /usr/sbin all now point to /usr/bin there is no sense in having the same location four times in your path...

The fact that a .pacnew has been created normally means that you changed /etc/profile manually, and you might want to merge this change into the new /etc/profile.

Further reading: The fine Arch Wiki on Pacnew and Pacsave Files.

Last edited by ball (2013-06-05 21:23:51)

WorMzy · 2013-06-05 21:43:22

wilberfan wrote:

Jeez, I completely misinterpreted the instructions.
5) Update your system.
Before performing this update, you may want to ensure you have a second terminal open with root privileges in the unlikely event of an emergency, particularly if updating over ssh.
# pacman -Syu --ignore filesystem,bash
# pacman -S bash
# pacman -Su
I thought "5) Update your system" meant "run pacman -Syu, then, *only if you have problems*, run the three pacman commands below in a separate rooted terminal..."

You're not the first person to make this mistake, if that helps. But a normal 'pacman -Syu' should fail with a 'error: failed to commit transaction (conflicting files)' anyway, since it'd include the filesystem package. So unless you've done something strange, you'll be no worse off, and can follow the instructions properly with no harm done.

wilberfan · 2013-06-05 22:36:48

WorMzy wrote:

wilberfan wrote:
Jeez, I completely misinterpreted the instructions.
You're not the first person to make this mistake, if that helps. But a normal 'pacman -Syu' should fail with a 'error: failed to commit transaction (conflicting files)' anyway, since it'd include the filesystem package. So unless you've done something strange, you'll be no worse off, and can follow the instructions properly with no harm done.

That was my experience, exactly. I thought the error was my failure to move everything necessary--but all of the pacman and find commands were returning null responses...

And it DOES help that I'm not the first to make that mistake! :-)

rasteenb · 2013-06-06 13:15:15

I found this note appended to the announcement on archlinux.fr (translated with google):

(*) Editor's note : This is therefore to move the offending binaries in / usr / bin. Two possibilities:
recommended (for packets identified in steps 1 and 2) : you uninstall these packages time to update and reinstall after step 5.
manual (required if you would step 3 something) : you manually move the binaries in / bin, / sbin and / usr / sbin these packages in / usr / bin. You still have to remove the / bin, / sbin and / usr / sbin once empty before performing the update filesystem in step 5 (pacman will tell you as at the beginning).

That probably reduced some confusion and heartache.

WorMzy · 2013-06-06 13:32:16

It probably caused more tbh, at least, if the user opted for the "manual" method since it doesn't update the references to the files from pacman's database.

rasteenb · 2013-06-06 13:54:33

WorMzy wrote:

It probably caused more tbh, at least, if the user opted for the "manual" method...

True, I was fortunate in that I only had to do step 1. Step 3 concerned "...files in /bin, /sbin or /usr/sbin that are unowned by any package,"

Nico666 · 2013-06-06 15:15:32

Ok, this seemed about time to, at last, upgrade to Grub2.
Everything done, now crossing fingers and rebooting.

BTW: These sort of updates have perfect timing. They always come up just when I am extremely busy with work.

huntrm · 2013-06-07 20:16:33

Need some help. I was unable to complete the upgrade, and unfortunately lost my SSH session preventing me to complete the required steps. Am now needing a method to recover as the system will not boot.

In short, I did the following:
pacman -R localepurge
pacman -Syu --ignore filesystem,bash

All worked at this point:
pacman -S bash

All was good, then did this:
pacman -Su

It didn't complete.

I had two outstanding items in /usr/sbin - filesystem and cherokee per the command: pacman -Qo /usr/sbin/. At this point, I lost the SSH session and was unable to log back in as the root password was no longer being accepted.

Per a post that I read, I fsck'd (after unmounting) my archlinux install to perform a repair from a live CD. Now, the system won't boot.

Am in a world of hurt, trying to get this back up. Suggestions/help needed.

Last edited by huntrm (2013-06-07 20:18:31)

ewaller · 2013-06-07 21:02:32

huntrm wrote:

Now, the system won't boot.

Okay, provide a detailed description of what is happening.

Which bootloader?
How far does it get?
What are the error messages?
What is the final state? (Hung, panic, blank screen, recovery shell, other?)

jasonwryan · 2013-06-07 21:04:38

huntrm: if you are referring to a Raspberry Pi (and it seems you are), please see here:
https://bbs.archlinux.org/viewtopic.php?id=153431

huntrm · 2013-06-07 21:13:54

It is in reference to an ARM architecture. I'm looking for ideas on what to possibly do from this forum. I'll go back to the ARM forums. Thanks.

jimstringer · 2013-06-07 21:18:45

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:

[root@arch jim]# pacman -Su
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...

Packages (1): filesystem-2013.05-2

Total Download Size:    0.01 MiB
Total Installed Size:   0.01 MiB
Net Upgrade Size:       -0.30 MiB

:: Proceed with installation? [Y/n] y
:: Retrieving packages ...
warning: failed to retrieve some files
error: failed to commit transaction (error invoking external downloader)
Errors occurred, no packages were upgraded.

Does anyone have any clue how to fix it?

Scimmia · 2013-06-07 21:21:04

If you have a non-default downloader set in /etc/pacman.conf, comment it out for now. (XferCommand)

Last edited by Scimmia (2013-06-07 21:21:55)

jimstringer · 2013-06-07 21:27:42

That worked Thanks.

wolfdogg · 2013-07-14 22:40:02

Uh oh

[root@falcon sbin]# pacman -Su
:: 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]
(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: /sbin exists in filesystem
filesystem: /usr/sbin exists in filesystem
Errors occurred, no packages were upgraded.
[root@falcon sbin]# ls
rc.d  zdb  zfs  zfs-fuse  zpool  zstreamdump  ztest

thats a few things needed. i think i can find info for rc.d easily, no longer use it i think, i switched to systemd along time ago, bit im worried about blowing out my zfs backup array, any instructions on what i can do about the zfs installation? dont i need to move it out of /usr/sbin? Guessing reinstalling will get it moved, but want to know the implicaitons of this, if someone knows if the pool configs or whatever is needed for the backup array will stay intact and survive the reinstallation.
and /sbin contents;

[root@falcon sbin]# ls
fsck.hfsplus  halt  init  mkfs.hfsplus  poweroff  reboot  runlevel  shutdown  telinit

Jristz · 2013-07-14 23:09:04

wolfdogg wrote:

Uh oh

[root@falcon sbin]# pacman -Su
:: 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]
(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: /sbin exists in filesystem
filesystem: /usr/sbin exists in filesystem
Errors occurred, no packages were upgraded.
[root@falcon sbin]# ls
rc.d  zdb  zfs  zfs-fuse  zpool  zstreamdump  ztest

thats a few things needed. i think i can find info for rc.d easily, no longer use it i think, i switched to systemd along time ago, bit im worried about blowing out my zfs backup array, any instructions on what i can do about the zfs installation? dont i need to move it out of /usr/sbin? Guessing reinstalling will get it moved, but want to know the implicaitons of this, if someone knows if the pool configs or whatever is needed for the backup array will stay intact and survive the reinstallation.
and /sbin contents;

[root@falcon sbin]# ls
fsck.hfsplus  halt  init  mkfs.hfsplus  poweroff  reboot  runlevel  shutdown  telinit

for the hfs related, you need rebuild using the latest PKGBUILD
for the zfs try the same, and then test again... but that shutdown isnot supposed to be there...
you have systemd-installed (all the systemd in core)??

cfr · 2013-07-14 23:16:36

If you have switched to systemd, remove initscripts and install systemd-sysvcompat. That should remove obsolete commands and replace those you may want with systemd equivalents.

As Jristz says, for the other stuff you need to update and rebuild the AUR packages.

You should have done this before you got to this point, though. Did you follow the instructions from the beginning?

wolfdogg · 2013-07-15 00:04:03

Jristz wrote:

you have systemd-installed (all the systemd in core)??

cfr wrote:

If you have switched to systemd, remove initscripts and install systemd-sysvcompat

i had systemd installed long ago, i didnt just install it, it has been working great. should i still suspect some systemd components are missing or were you guys just responding to the fact that i commented on that. I didnt mean i had just installed it.
I havent rebooted yet since this upgrade where im stuck as as mentioned in my last post. Should i do anything before rebooting, or should i reboot first?

Im was hoping to get the samba issue i was working at resolved before rebooting as well, but looks like that will have to wait too?

[root@falcon samba]# systemctl restart smbd
Warning: Unit file of smbd.service changed on disk, 'systemctl --system daemon-reload' recommended.
Job for smbd.service failed. See 'systemctl status smbd.service' and 'journalctl -xn' for details.
[root@falcon samba]# systemctl restart smb
Failed to issue method call: Unit smb.service failed to load: No such file or directory. See system logs and 'systemctl status smb.service' for details.
[root@falcon samba]# systemctl restart smbd
Warning: Unit file of smbd.service changed on disk, 'systemctl --system daemon-reload' recommended.
Job for smbd.service failed. See 'systemctl status smbd.service' and 'journalctl -xn' for details.
[root@falcon samba]# systemctl status smbd.service
smbd.service - Samba SMB/CIFS server
   Loaded: loaded (/usr/lib/systemd/system/smbd.service; enabled)
   Active: failed (Result: exit-code) since Sun 2013-07-14 09:02:16 PDT; 11s ago
  Process: 17188 ExecStart=/usr/sbin/smbd -D (code=exited, status=203/EXEC)
 Main PID: 3999 (code=exited, status=1/FAILURE)
   CGroup: name=systemd:/system/smbd.service

Jul 14 09:02:16 falcon systemd[1]: Starting Samba SMB/CIFS server...
Jul 14 09:02:16 falcon systemd[1]: smbd.service: control process exited, code=exited status=203
Jul 14 09:02:16 falcon systemd[1]: Failed to start Samba SMB/CIFS server.
Jul 14 09:02:16 falcon systemd[1]: Unit smbd.service entered failed state.

Warning: Unit file changed on disk, 'systemctl --system daemon-reload' recommended.

Im assuming the failure is coming from the fact that i havent rebooted.

Last edited by wolfdogg (2013-07-15 00:07:56)

cfr · 2013-07-15 00:26:37

cfr wrote:

You should have done this before you got to this point, though. Did you follow the instructions from the beginning?

systemd-sysvcompat is recommended but not compulsory that I know of . What is your kernel command line? (/proc/cmdline)

Did you try the suggested solution for samba?

Last edited by cfr (2013-07-15 00:26:49)

wolfdogg · 2013-07-15 02:21:33

thanks for the response!

Im not sure what do to at this point, i am trying to do a pacman update because i havent done it in a while, this just so happened to conincide to some maintenance operations, but wasnt related. The problems i am having are now are cross tied since bash was upgraded and now needing adjustments before i can continue back on the maintenance i was trying to do(check some cron jobs for rsnapshot and work in the integrity of my zfs pool, and get samba back working). i can repair samba after i get the bash stuff figured out. i upgraded to systemd about 6months ago and dont remember what systemd-sysvcompat is, but i remember adressing it in some form or another. i got everything moved over to systemd, and thought i left behind rc.d because of it. so i thought i probably dont need it, if thats what is being questioned here.

what i am really needing some direction on is what do i do to get my system working again, i cant log in as root, luckily i am still shelled in as root, and i also have access to the console itself which i am also still rooted into, but i cant open a new shell, i cant su to root from another shell i still have open as user, it appears all my other ttys are blank and have no access to bash either, BUT, i havent restarted yet. i want to, but as mentioned in the Latest News on home page, move files out of sbin but not sure how to do this

2) Make sure any packages in IgnorePkg or IgnoreGroup do not have files in /bin, /sbin, or /usr/sbin. Fix them if necessary.
3) If you have files in /bin, /sbin or /usr/sbin that are unowned by any package, you need to move them. Find a list using:
$ find /bin /sbin /usr/sbin -exec pacman -Qo -- {} + >/dev/null
4) Ensure all partitions are mounted if using autofs. They may not automount when needed later in this update.
5) Update your system.
Before performing this update, you may want to ensure you have a second terminal open with root privileges in the unlikely event of an emergency, particularly if updating over ssh........

i dont understand step 2), i dont really understand step3) as far as "you need to move them out", regarding step 4) i think i did have a partition mounted using autofs, its in /mnt/<share-name> i think, not sure how to find out, not sure if it matters cause its always mounted, no reason to think it wouldnt be.

So i copied and pasted a list of files in sbin dirs a few posts ago in hopes that somebody would spot something so i can move forward.

Where should i start? Reboot, or uninstall ZFS and makepkg? or? any help is appreciated.

EDIT;

[root@falcon samba]# pacman -Q systemd-sysvcompat
error: package 'systemd-sysvcompat' was not found

did i not finish systemd on this system? would that have anything do to with this? Im checking into this right now, and seeing if initscripts has been completely removed, and ill get sysvcompat right now, as mentioned, any suggestion are appreciated, it appears im out of my league on this one.

Last edited by wolfdogg (2013-07-15 02:43:47)

cfr · 2013-07-15 02:50:00

Do NOT reboot. If possible, you need to complete the update first. If not, you will definitely need a live media (e.g. Arch install media) to recover.

The problem right now is that those instructions needed to be completed in order. Unfortunately, you have completed parts of (5) without understanding or completing the earlier instructions. This makes the update more difficult. The files that you have left in those directories belong to packages which should have been dealt with before you began (5).

What is your kernel command line? /proc/cmdline. I am asking this again because I want to be sure that I am not telling you to do something which will make your machine unbootable.

IF you are properly using systemd and IF you did not install the compatibility package, then your kernel command line should specify init. Does it? If so, what value does it have?

What do you use zfs and hfs for? That is, could you boot without these if you needed to or not?

Last edited by cfr (2013-07-15 02:51:20)

wolfdogg · 2013-07-15 02:54:31

ok, it appears on this system i HAVE NOT yet completed removing initscripts, and i DONT know how to do so. I see alot of suggestion to "remove initscripts" or "uninstall initscripts" but i havent found a place that describes this. It appears all i did was remove all daemons and network configs from rc.conf but got cold feet on the modules and LVM setting since i was using them but was extremely overworked getting them running and didnt want to foul anything up. Currently here is my rc.conf, note i would like to remove initscripts entirely, and i would like to do that first if it has ANYTHING to do with getting bash working again, otherwise it can wait.

#
# /etc/rc.conf - Main Configuration for Arch Linux
#

# -----------------------------------------------------------------------
# LOCALIZATION
# -----------------------------------------------------------------------
#
# LOCALE: available languages can be listed with the 'locale -a' command
# DAEMON_LOCALE: If set to 'yes', use $LOCALE as the locale during daemon
# startup and during the boot process. If set to 'no', the C locale is used.
# HARDWARECLOCK: set to "", "UTC" or "localtime", any other value will result
#   in the hardware clock being left untouched (useful for virtualization)
#   Note: Using "localtime" is discouraged, using "" makes hwclock fall back
#   to the value in /var/lib/hwclock/adjfile
# TIMEZONE: timezones are found in /usr/share/zoneinfo
#   Note: if unset, the value in /etc/localtime is used unchanged
# KEYMAP: keymaps are found in /usr/share/kbd/keymaps
# CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US)
# CONSOLEMAP: found in /usr/share/kbd/consoletrans
# USECOLOR: use ANSI color sequences in startup messages
#
#LOCALE="en_US.UTF-8"
DAEMON_LOCALE="no"
HARDWARECLOCK="localtime"
#TIMEZONE="America/Los_Angeles"
KEYMAP="us"
CONSOLEFONT=
CONSOLEMAP=
USECOLOR="yes"

# -----------------------------------------------------------------------
# HARDWARE
# -----------------------------------------------------------------------
#
# MODULES: Modules to load at boot-up. Blacklisting is no longer supported.
#   Replace every !module by an entry as on the following line in a file in
#   /etc/modprobe.d:
#     blacklist module
#   See "man modprobe.conf" for details.
#
MODULES=(fuse)

# Udev settle timeout (default to 30)
UDEV_TIMEOUT=30

# Scan for FakeRAID (dmraid) Volumes at startup
USEDMRAID="no"

# Scan for BTRFS volumes at startup
USEBTRFS="no"

# Scan for LVM volume groups at startup, required if you use LVM
#USELVM="no"
USELVM="yes"

# -----------------------------------------------------------------------
# NETWORKING
# -----------------------------------------------------------------------
#
# HOSTNAME: Hostname of machine. Should also be put in /etc/hosts
#
HOSTNAME="falcon"

# Setting this to "yes" will skip network shutdown.
# This is required if your root device is on NFS.
NETWORK_PERSIST="no"

i already set my hostname in systemd, so i know that line is no longer needed, the rest i need a suggestion if i need the settings for USEDMRAID, USEBTRFS, USELVM, UDEV_TIMEOUT, and the MODULES(fuse) im pretty sure i have read the modules wiki a million times and its got info i need on there for that, but i think i recall running into probs with zfs in particular there since its not very much supported around here. If i need to start a new post ill be glad to, just let me know. Thanks in advance.

Edit; ok i just read your last post, ill stop here and read your last post and address right now, thanks for the response. hang on a sec and ill answer.

Last edited by wolfdogg (2013-07-15 02:55:36)

wolfdogg · 2013-07-15 02:58:47

sorry i had checked but forgot to mention /proc/cmdline

[root@falcon rc.d]# /proc/cmdline
bash: /proc/cmdline: Permission denied

checking permissions on it looks like its -r--r--r-- root:root
I had hfsprogs for accessing a mac drive in the past, but i uninstalled 30 mins ago. I need ZFS, but i DONT need it for booting NO.

Last edited by wolfdogg (2013-07-15 03:00:32)

cfr · 2013-07-15 03:09:18

cat /proc/cmdline - I meant your command line is in that file.

To get bash working, you need to complete the update. To do that, you need not to have files in those directories.

If you do not need ZFS to boot, uninstall it for now and worry about it when you have got bash working and rebooted etc.

How do you boot? bios? efi? Which boot loader/manager?

EDIT: The stuff you have marked as "no" in rc.conf you can definitely ignore. You aren't using those things so you don't need to replace them. What is on LVM on your system?

EDIT EDIT: See https://wiki.archlinux.org/index.php/Sy … stallation for the critical steps. You already have systemd installed and have set hostname. Do NOT do step 3. Instead, I think you should probably uninstall initscrpts and install systemd-sysvcompat straight away. That will save you from needing to tweak the command line to change the init parameter and there's no reason not to install that since you have to remove initscripts anyway. Once you have uninstalled initscripts, you should be able to do pacman -Su to complete the update. This strategy is not without risks as your machine will be unbootable if you do not get the systemd configuration close enough to right. But I cannot think of a better option at the moment. You can't leave initscripts installed because it is blocking the update and if you don't complete that, your system will definitely be unbootable. So I am thinking that the risk of its being so is preferable to the certainty of its being so.

Last edited by cfr (2013-07-15 03:24:58)

Arch Linux

#151 2013-06-05 20:32:10

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

#152 2013-06-05 21:16:27

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

#153 2013-06-05 21:43:22

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

#154 2013-06-05 22:36:48

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

#155 2013-06-06 13:15:15

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

#156 2013-06-06 13:32:16

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

#157 2013-06-06 13:54:33

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

#158 2013-06-06 15:15:32

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

#159 2013-06-07 20:16:33

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

#160 2013-06-07 21:02:32

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

#161 2013-06-07 21:04:38

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

#162 2013-06-07 21:13:54

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

#163 2013-06-07 21:18:45

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

#164 2013-06-07 21:21:04

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

#165 2013-06-07 21:27:42

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

#166 2013-07-14 22:40:02

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

#167 2013-07-14 23:09:04

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

#168 2013-07-14 23:16:36

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

#169 2013-07-15 00:04:03

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

#170 2013-07-15 00:26:37

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

#171 2013-07-15 02:21:33

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

#172 2013-07-15 02:50:00

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

#173 2013-07-15 02:54:31

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

#174 2013-07-15 02:58:47

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

#175 2013-07-15 03:09:18

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

Board footer