Binaries move to /usr/bin requiring update intervention

wolfdogg · 2013-07-15 04:59:53

Thanks for your response again,
sorry about that, i thought that was a rather odd command, hehe. i should have known.. results from cat /proc/cmdline is

root=/dev/disk/by-uuid/31bc96fe-23e2-4585-8b04-8f95d84aa78b ro init=/usr/lib/systemd/systemd

i just never removed the line at the end.. but i have ran systemctl enable/disable/restart/stop/start.... a hundred times for various services so i know its working fine.

i use grub, i think i ran into probs with grub2 but if i have to upgrade there i should be able to do that, if that's where your going with that.

You know, about boot, i have heard about EFI for a long time, but since im not exactly sure what it would entail getting it setup i don think im using it. My bios is set to boot to a certain drive, and that drive has grub installed as a bootloader as far as i know.

i just removed ZFS. the last zfs i had setup was using a linear array of drives and i think it was using LVM, but i believe that last time i set up the zfs array i found a way to skirt around having to use LVM to get working a straight linear array of drives, various sizes, similar if not identical to a JBOD. Other than that, my boot drive(a single drive) doesnt use LVM at all, i have standard 4 partitions on it, /, /boot, /home /swap.

what i was trying to say about step 5 of systemd is i dont understand how to "uninstall" initscripts, i dont know what that entails, and how to go about that, and couldnt find documentation. That wouldnt be as easy an running pacman -R initscripts would it? if so, hey, thats probably what i have been missing, cause i thought it would entail more of removing files manually, etc..

Edit: well ill be, that was all i needed to do to remove initscripts???? i think ill edit that line on the wiki sometime, cause i didnt realize it was a binary that couldn't just be straight out uninstalled using pacman.

ok iniscripts is gone, hallelujah, and i installed sysvcompat, it gave a warning and i allowed it to remove sysvinit.

Wow, i think it worked, i was able to upgrade this time around.(pacman -Su) THANKS MUCH FOR THE HELP! so filesystem-2013.05-2 was installed, just gave me a warning: directory permission differ on /srv/ftp filesystem 755: package: 555. I dont use proftpd anymore, and my apache isnt using that dir so i could care less what the permissions are on that dir if you have any suggestions.

Thanks for the excellent help, i needed a bit pushing along there. Ill be back online in the morning, or after lunch tomorrow.

So what else should i check before rebooting?

Edit: my command line seems to be working without reboot as well, i was able to re-shell into the system, and gain root access this time around, whereas before i ran the update i wasnt. I had suspected that i would need a reboot first. Also, on the console itself the ttys work again as well.

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

cfr · 2013-07-15 10:58:12

That's great! Since you turn out to be using systemd to boot after all, you should just be able to reboot fine now you've updated filesystem. (This is also what has got bash working again because the update installs the necessary symbolic links.) I think I would reboot just to make sure it is all OK and there are no surprises. Then you can update zfs by getting a new pkgbuild from AUR (probably) and return to thinking about samba... Let us know if it goes OK.

wolfdogg · 2013-07-15 15:11:01

Well, looks like i need to address grub, it took me to grub command line, was i supposed to move to grub 2 before rebooting? I notice the Grub 2 wiki is now called Grub and original grub is now called Grub Legacy, this name change may have caused a misunderstanding.

Error 8: Kernel must be loaded before booting

Unless you think its something obvious, ill look into getting grub back up and running, and hopefully updated to grub2

Edit: im just hoping the LVM doesnt have anything to do with it, even though it wasnt applied to the boot drive, as far as i know. Or could it be because i havent updated to grub2 yet, which im not completely sure of at this point.

Last edited by wolfdogg (2013-07-15 17:40:11)

cfr · 2013-07-15 20:51:07

OK. That's something else you would have caught if you'd done the earlier steps. I didn't realise you were still booting with the old grub package. What has probably happened is that you were still using legacy "grub" which has not been in the repos for quite a while. grub2 was recently renamed to grub. So pacman has "updated" the legacy package but, of course, it is not the same package.

The immediate solution is to move the legacy grub config file which pacman has turned into a .pacsave back to its original name. I've never used grub legacy but I think it is menu.lst or grub.lst or something like that - whatever you specify the menu entries in. If you move that back i.e. remove the .pacsave suffix, you should be able to boot because grub legacy is still installed to disk.

Once you have booted, you should fix this properly. There are various options. One is to install the AUR grub-legacy package which has been updated to work with the changes to the file system. Another is to switch to grub2. That's already installed as a package but you'd need to install it to disk and generate a grub.cfg for it (or write one but most people generate it). Another is to switch to something like syslinux which some people prefer. Any of those options is fine - you just don't want to stay with having the package for one boot loader installed (grub 2) while having a different one installed to disk (legacy grub).

I doubt it has anything to do with LVM. grub isn't getting that far. Also, if I'd known you were using the old repo legacy grub package, I would have predicted grub would do exactly this on boot. I'm pretty sure something different would happen if it had anything to do with LVM.

Last edited by cfr (2013-07-15 20:53:27)

wolfdogg · 2013-07-15 21:56:11

i agree with you completely, and although i mentioned grub i can see its easily confused because they renamed the package. I thought this might happen without adressing grub, its no prob. I have syslinux on another system, i prefer to use grub2 (renamed Grub from what i gather), and i like the generate option, sounds good. I have worked with grub many times so it shouldnt be a problem, the file is called menu.lst. Ill get that file back in place and see if it boots up, then ill get it switched out.

Then i can get samba working properly again, then i can zfs installed again, then i can proceed to backup my other systems over here which is all i was trying to do in the first place, lol. Well anyway, its fun, or i wouldn't love Arch!

wolfdogg · 2013-07-20 04:51:19

Well it went good. i renamed the pacsave back to menu.lst as you mentioned and got the system running no prob. I had a network error that i cant explain but that seems to out of the way. I appreciate the help much!

I would like to get my zfs array back up and running so i can get my several TB of data from another system backed again. I installed archzfs, but its not seeing my pool when i try to import, so im getting kind of pained not knowing what path to take before i lose the data. its not utterly important since its just an incremental backup that can get overwritten, but i have a bit of other data on there that i was hoping to offload.

cfr · 2013-07-20 21:37:20

I think you should maybe open a new thread for that issue. Since you are now updated (at least assuming you've fixed the boot loader properly, too), it seems like a separate issue. That way, you can use a subject with zfs in it and hopefully get some advice from somebody who knows something about it!

wolfdogg · 2013-07-21 02:52:42

yeah i was hoping you would say that, because i didnt wan to blow up this thread over here. ill leave it at that. Thanks much for your help,

hddnhrst · 2013-07-29 16:32:30

Hello,

I didn't do a system upgrade since February. I am aware of the following news:
https://www.archlinux.org/news/binaries … ervention/

But still I don't know how to upgrade. I think I messed some things up already. This is what I did...

--

First I checked for non-official packages as described and it seemed fine:

# pacman -Qqo /bin /sbin /usr/sbin | pacman -Qm -
error: cannot determine ownership of directory '/bin'
error: cannot determine ownership of directory '/sbin'
error: cannot determine ownership of directory '/usr/sbin'

I am not using unofficial repos, so I thought it's okay to skip the second command.
The last command didn't list anything, just the ownership thingy like above.

So then I just tried to upgrade with -Syu --ignore filesystem,bash
It suggested to first upgrade pacman itself,
but doing so it stopped due to unresolved dependencies.

Then I tried it again without upgrading pacman first:

warning: filesystem: ignoring package upgrade (2012.12-1 => 2013.05-2)
:: Replace grub-bios with core/grub? [Y/n] 
:: Replace grub-common with core/grub? [Y/n] 
:: Replace khrplatform-devel with extra/mesa? [Y/n] 
:: Replace libegl with extra/mesa? [Y/n] 
:: Replace libgbm with extra/mesa? [Y/n] 
:: Replace libglapi with extra/mesa? [Y/n]

Yes to everything, then I skipped many packages due to more unresolved dependencies, upgrading everything else.

That was a mistake I guess... When I run the first command again, it lists more packages now:

# pacman -Qqo /bin /sbin /usr/sbin | pacman -Qm -
error: cannot determine ownership of directory '/bin'
error: cannot determine ownership of directory '/sbin'
error: cannot determine ownership of directory '/usr/sbin'
catalyst-dkms 13.1-1
catalyst-utils 13.1-1
grub-bios 2.00-1
grub-common 2.00-1
khrplatform-devel 9.0.1-1
libegl 9.0.1-1
libgbm 9.0.1-1
libglapi 9.0.1-1
netcfg 3.0-1

What and how exactly should I fix these things?

When I run the second command as described:

# paclist core | awk ' { print $1 } ' | pacman -Ql - | grep ' /s\?bin/\| /usr/sbin/'
-bash: paclist: command not found

... followed by a long list of progs. I guess I should first get paclist for the right output? Ignoring for now.

What should I do from here?

I am a bit desperate, I can't upgrade my system anymore.
I would be very grateful for any help here. Thank you very much in advance.

oliver · 2013-07-29 16:39:59

start with posting the output from this command

$ ls -ld /usr/sbin /bin /sbin

If they're not owned by root:root you might have to investigate why before proceeding

Last edited by oliver (2013-07-29 16:40:36)

WonderWoofy · 2013-07-29 16:42:14

Paclist is provided by pacman these days. So youare probably running on an old version of pacman. If I'm not mistaken, this is likely going to give you some trouble, as there were changes in the most recent versions of pacman that actually make this /usr/bin merge possible.

In any case, there is a giant thread covering this. I am going to report this thread to the mods to get it merged with the rest. Maybe then you can peruse through the thread and find your answers there. Beware that it is a long thread, and many have come there complaining that they can't be expected to read through such a long thread. But in reality, it just repeats itself over and over and over again. This is because people didn't read the thread (surprise!) and then post the same issues again and again. So you don't really need to read the whole thing.

BTW, is there anything in /bin, /sbin, and /usr/sbin?

hddnhrst · 2013-07-29 16:44:27

root ~ # ls -ld /usr/sbin /bin /sbin
drwxr-xr-x 2 root root 4.0K Jul 29 17:15 /bin
drwxr-xr-x 2 root root 4.0K Jan 21  2013 /sbin
drwxr-xr-x 2 root root 4.0K Jul 29 17:17 /usr/sbin

Looks fine. No idea why it has problems determining the ownership. Maybe this can be ignored...

WonderWoofy · 2013-07-29 16:47:51

$ pacman -Qo /bin /sbin /usr/sbin

If there is nothing in there, it should report that only the filesystem package owns this.

Edit: Or rather that only the filesystem package owns these.

Last edited by WonderWoofy (2013-07-29 16:48:16)

hddnhrst · 2013-07-29 16:52:11

Yes, there is a lot in /bin /sbin and /usr/sbin
/bin: total 880K
/sbin: total 11M
/usr/sbin: total 11M

My pacman is from last year:

# pacman -Qi pacman
Name           : pacman
Version        : 4.0.3-5

As mentioned I don't know how to upgrade pacman due to unresolved dependencies...

Last edited by hddnhrst (2013-07-29 16:52:30)

hddnhrst · 2013-07-29 16:53:48

# pacman -Qo /bin /sbin /usr/sbin
error: cannot determine ownership of directory '/bin'
error: cannot determine ownership of directory '/sbin'
error: cannot determine ownership of directory '/usr/sbin'

No idea...

WonderWoofy · 2013-07-29 16:57:45

What kind of output are you given if you do (assuming that your package list is properly updated to reflect that pacman 4.1.2 is available).

# pacman -S pacman

Xyne · 2013-07-29 16:58:57

merged

hddnhrst · 2013-07-29 17:02:11

# pacman -S pacman
resolving dependencies...
looking for inter-conflicts...

Targets (5): filesystem-2013.05-2  glibc-2.17-6  libarchive-3.1.2-1  lzo2-2.06-1
             pacman-4.1.2-1

Total Installed Size:   43.09 MiB
Net Upgrade Size:       -1.39 MiB

Proceed with installation? [Y/n] 
(5/5) checking package integrity                          [##############################] 100%
(5/5) loading package files                               [##############################] 100%
(5/5) checking for file conflicts                         [##############################] 100%
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.

hddnhrst · 2013-07-29 17:39:51

How can I upgrade my pacman?

# pacman -S pacman --ignore filesystem
resolving dependencies...
warning: ignoring package filesystem-2013.05-2
warning: cannot resolve "filesystem>=2013.01", a dependency of "glibc"
:: The following package cannot be upgraded due to unresolvable dependencies:
      pacman

I guess I need to fix filesystem prior?

# pacman -S filesystem
:: The following packages should be upgraded first :
    pacman
:: Do you want to cancel the current operation
:: and upgrade these packages now? [Y/n] n

resolving dependencies...
looking for inter-conflicts...

Targets (1): filesystem-2013.05-2

Total Installed Size:   0.01 MiB
Net Upgrade Size:       -0.09 MiB

Proceed with installation? [Y/n] 
(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: /bin exists in filesystem
filesystem: /lib exists in filesystem
filesystem: /lib64 exists in filesystem
filesystem: /sbin exists in filesystem
filesystem: /usr/sbin exists in filesystem
Errors occurred, no packages were upgraded.

What should I do? How do I fix these folders? Really uninstalling all packages owning files in these folders??

lharmon · 2013-07-29 19:24:20

I have been trying to update my SMILE plug without any success.

Following the "Binaries move to /usr/bin requiring update intervention" I attempt "pacman -Qqo /bin /sbin /usr/sbin | pacman -Qm -"
root@SMILEplug:~# pacman -Qqo /bin /sbin /usr/sbin | pacman -Qm -
error: cannot determine ownership of directory '/bin'
error: cannot determine ownership of directory '/sbin'
error: cannot determine ownership of directory '/usr/sbin'

This causes my system to hang then reboot!

root@SMILEplug:~# find /bin /sbin /usr/sbin -exec pacman -Qo -- {} + >/dev/null
error: cannot determine ownership of directory '/bin'
error: cannot determine ownership of directory '/sbin'
error: cannot determine ownership of directory '/usr/sbin'

Is there any hope?

HalosGhost · 2013-07-29 19:29:34

lharmon wrote:

I have been trying to update my SMILE plug without any success.

If memory serves, that is an ARM-based CPU. Please see the forum etiquette and try asking on ALARM's BBS.

All the best,

-HG

cfr · 2013-07-29 22:39:56

@hddnhrst,
Since it is quite a long time since you updated, I think you should consider updating incrementally using the Arch Rollback Machine as I am not sure you will be able to update in one stage. Use the News items to identify major intervention points and set the size of each incremental upgrade. Alternatively, you could reinstall so I think it really depends on which option would work best for you. On the other hand, somebody more expert than me may have a better suggestion but those are the two options which spring to mind immediately.

The trouble is I don't think you can update pacman without updating filesystem but you cannot update filesystem until the last step without breaking things. And you cannot update everything else without updating pacman. So I cannot see any obvious way around the issue except incremental update or reinstall.

Arch really, really is not meant to be updated this infrequently. If you are not able and willing to update reasonably regularly, Arch is probably not a great distro for you.

Last edited by cfr (2013-07-29 22:40:50)

hddnhrst · 2013-07-30 14:28:08

I guess you are totally right. I never thought not upgrading my system would cause such problems!
Actually it's no big deal running pacman -Syu every now and then, I just didn't see the necessity... until now!
Thanks for pointing me to ARM, didn't know that it exists. Tonight I will try downgrading and then upgrading things step by step...

WonderWoofy · 2013-07-30 15:01:20

@hddnhrst,

The necessity of updating Arch Linux is more than just the potential breakage caused by these big news items. Yes those things are a good reason to stay up to date, as having to deal with multiple manual-intervention updates can be a challenge.

But there is also the continuously pushed security updates and whatnot that are pushed as new versions of software. The only supported versions of software in Arch Linux are the ones that are currently in the repos, so we don't packport security fixes like other distributions do so that they can keep a consistent version for their release. Instead, the new improved version itself is pushed.

Also, I would imagine, like most users, you install new software from time to time. If you don't update all the libraries and other dependencies, selectively installing a current package into a non-updated system can severly break your machine. This is because packages are built against certain versions of libs. So when those libs get updated, so do al the packages that link to them. So it is for this reason that we don't commonly use specific versioned dependencies in our repos. There is the expectation that users know that the only supported state of their machine is to have it current. So versioned deps is rather pointless, since everyone should be running the same version of any given package anyway. (of course the AUR is a different story, and there having versioned deps can really help).

I hope that makes sense...

hddnhrst · 2013-07-30 16:25:27

Makes a lot of sense, I just didn't use that system much.
I will re-install it as now I can't even log in no more.

This all takes too much time and effort, re-installing seems easier and faster.

Thanks for the support!

Arch Linux

#176 2013-07-15 04:59:53

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

#177 2013-07-15 10:58:12

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

#178 2013-07-15 15:11:01

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

#179 2013-07-15 20:51:07

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

#180 2013-07-15 21:56:11

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

#181 2013-07-20 04:51:19

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

#182 2013-07-20 21:37:20

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

#183 2013-07-21 02:52:42

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

#184 2013-07-29 16:32:30

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

#185 2013-07-29 16:39:59

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

#186 2013-07-29 16:42:14

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

#187 2013-07-29 16:44:27

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

#188 2013-07-29 16:47:51

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

#189 2013-07-29 16:52:11

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

#190 2013-07-29 16:53:48

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

#191 2013-07-29 16:57:45

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

#192 2013-07-29 16:58:57

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

#193 2013-07-29 17:02:11

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

#194 2013-07-29 17:39:51

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

#195 2013-07-29 19:24:20

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

#196 2013-07-29 19:29:34

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

#197 2013-07-29 22:39:56

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

#198 2013-07-30 14:28:08

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

#199 2013-07-30 15:01:20

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

#200 2013-07-30 16:25:27

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

Board footer