filesystem Update Error /bin exists in filesystem

MichaelRpdx · 2013-06-24 12:31:51

Yes, it is out of scope here and I'll write no more on the matter.

Hopefully, offers of beer are always in scope and if any of you make it to Portland I'll buy a couple.

tuxs · 2013-06-24 14:56:19

I successfully update filesystem package!but,this is my result:

# ls /usr/sbin /sbin /bin -la                                                       
lrwxrwxrwx 1 root root 7 may 31 15:40 /bin -> usr/bin
lrwxrwxrwx 1 root root 7 may 31 15:40 /sbin -> usr/bin
lrwxrwxrwx 1 root root 3 may 31 15:40 /usr/sbin -> bin

what's my problem?why '/usr/sbin -> bin' ?how to fix it?

thx

Trilby · 2013-06-24 14:59:28

I'm not sure why, but that is the way it's supposed to be - it seems. ~~/usr/sbin points to bin, but bin in turn points to /usr/bin/ - so any /usr/sbin/ path will go to /usr/bin~~

EDIT: now I see why. Thats -> bin, not -> /bin. It's a relative link, which makes it correctly a direct link to usr/bin

Last edited by Trilby (2013-06-24 15:00:55)

tuxs · 2013-06-24 20:36:09

Trilby wrote:

I'm not sure why, but that is the way it's supposed to be - it seems. ~~/usr/sbin points to bin, but bin in turn points to /usr/bin/ - so any /usr/sbin/ path will go to /usr/bin~~
EDIT: now I see why. Thats -> bin, not -> /bin. It's a relative link, which makes it correctly a direct link to usr/bin

your mean it's ok?it's normal?

Trilby · 2013-06-24 20:50:30

Yes. The links are relative paths.

/bin and /sbin when are top level directories, so when linked to usr/bin, that links to 'bin' within the toplevel directory 'usr'.

/usr/sbin is not top level, it is in /usr and is a "sibling" to /usr/bin. So when linked to bin, that links to 'bin' in the same path 'usr' which is /usr/bin.

Last edited by Trilby (2013-06-24 20:53:58)

tuxs · 2013-06-24 21:47:28

@Trilby
very thx for help me

dbarthel · 2013-06-27 19:47:05

I'm a newbie (and have been for many years .

I couldn't 'pacman -Syu', something to do with "grub conflicts with grub-common" then "grub-common can't be removed" because it requires first upgrading package 'filesystem' which results in "Error /bin exists in filesystem", "Error /sbin exists in filesystem" and "Error /usr/sbin exists in filesystem". Argh! (Yes I know it doesn't make sense but I didn't note the exact sequence of road blocks as I went along.) Anyway this is how I solved it:

Show all packages that own files in these directories:

pacman -Qo /bin /sbin /usr/sbin

Upgrade those packages (which removes them from there and installs them elsewhere):

pacman -S tar gawk dash coreutils bash ...

...etc.

After upgrading all *except* 'filesystem', finally upgrade filesystem:

pacman -S filesystem

...which removes /bin, /sbin, and /usr/sbin and replaces them with symbolic links (I think).

Only then would a 'pacman -Syu' complete.

P.S. I rebooted midway through the process and my system was not bootable. To make it bootable I had to boot with this kernel parameter (press Tab on boot menu and append it): ‘break=postmount’ then once I got a command prompt I copied /bin/mount to /new_root/bin/mount - after boot /new_root/bin became /bin so I removed /bin/mount. Clear? Thought not.

HalosGhost · 2013-06-27 19:54:27

dbarthel wrote:

Anyway this is how I solved it…

No offense, but, in the future, you might want to just read the news items It would have saved you a lot of time.

All the best,

-HG

cfr · 2013-06-27 22:29:55

dbarthel wrote:

P.S. I rebooted midway through the process and my system was not bootable. To make it bootable I had to boot with this kernel parameter (press Tab on boot menu and append it): ‘break=postmount’ then once I got a command prompt I copied /bin/mount to /new_root/bin/mount - after boot /new_root/bin became /bin so I removed /bin/mount. Clear? Thought not.

You did what? Why did you do this? /bin should be a symbolic link to /usr/bin. So removing /bin/mount means removing /usr/bin/mount as they point to the same binary.

May I recommend reinstalling util-linux which provides the /usr/bin/mount command? You will probably prefer to do this before you reboot.

hokasch · 2013-06-28 13:02:34

OK, got bitten as well. While upgrading over ssh in a byobu session, after installing bash, I got kicked out. Now I can't connect back in - getting "Permission denied (publickey)". Any ideas? Looks like game over to me. That second root shell, I did not have open (only in tmux).
The server is running fine (services are up), and I have physical access, but no USB keyboard at the moment..

techprophet · 2013-06-28 14:53:10

Yesterday I did a complete system upgrade following the instructions about the update of the filesystem package. The commands went something like:

# pacman -Sy
# pacman -Su --exclude=filesystem
# pacman -Su

Everything went okay, and I continued using my laptop until the battery was about to die, at which point I shut it down.

Now, I'm attempting to boot it and I'm stuck in the following situation:

The GRUB config is set to use UUIDs and the UUID of my partition cannot be found.
Upon entering the grub console, I am able to view and read the contents of my filesystem. (I can, for example, cat /etc/fstab and it prints the correct contents)
Running the following* works, but running boot afterward causes a kernel panic:
```
linux /boot/vmlinuz-linux root=/dev/sda5 ro
initrd /boot/initramfs-linux-fallback.img
```
* I used tab completion and don't exactly remember the name of the initramfs fallback image, but it is the one that actually exists according to the grub console.
Booting using the menu entries drops me into an emergency console. The partition in question is not mounted on / or /new_root and /dev does not have a disk directory nor does it have any sd*, hd* or md* files.
The /dev directory at the grub console contains only null.
I do not have access to a livecd, grub recovery cd nor to a cd burner. Neither do I have a USB drive with me.

My partition layout is as follows (iirc):

/dev/sda1 - manufacturer recovery partition
/dev/sda2 - windows
/dev/sda3 - media
/dev/sda4 - swap
/dev/sda5 - /

I am 100% certain that /dev/sda5 is my / partition, as search -f /etc/fstab and search -f /boot/vmlinuz-linux both return (hd0,msdos5).

Based on what I've read, it seems like the initramfs got screwed up during the update. Probably it spouted some error messages and I wasn't paying attention and missed them. Currently I'm booted into the windows partition (which still works). The hard drive is fine, the partition in question seems fine since grub can read from it. Is there anything I can do to get arch booting in this scenario or will I have to wait til I have access to a livecd/liveusb?

EDIT: Fixed with a LiveCD borrowed from somebody; regenerated grub config and initramfs and it worked.

Last edited by techprophet (2013-06-28 20:00:24)

Arctus · 2013-06-28 14:57:16

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

were the commands you should have used. You probably need to reinstall Bash.

Last edited by Arctus (2013-06-28 14:57:37)

techprophet · 2013-06-28 15:03:15

Arctus wrote:

pacman -Syu --ignore filesystem,bash
pacman -S bash
pacman -Su
were the commands you should have used. You probably need to reinstall Bash.

bash was still working (though I do remember breaking it temporarily). I was able to launch new sessions of it post-upgrade without any extra shenanigans to make it work.

jasonwryan · 2013-06-28 20:06:08

Merging with the stickied thread...

WorMzy · 2013-06-28 20:51:06

Reinstalling bash won't help. You were supposed to upgrade bash after everything else (except filesystem) because a lot of post-install scripts explicitly call /bin/bash or /bin/sh in their shebangs. By upgrading bash at the same time as everything else (except filesystem), bash would've been upgraded towards the start of the upgrade process, meaning those two files don't exist when the install scripts try to call them, making them fail.

In particular, if you updated the linux package at in the same transaction, it would fail to generate a new initrd with the updated modules. This is why you should pay attention to a) the front page news, and b) pacman's output (stored in /var/log/pacman.log, if you need to catch up)

Regenerate your initrd. And reinstall any packages that have failed to run their install scripts.

PaulBx1 · 2013-06-28 21:49:16

I wrote a post about https://www.archlinux.org/news/binaries … ervention/. By the time I got done the forum software logged me out and I lost my post. Pretty short trigger there...

Anyway I can't figure it out for multiple reasons. Can somebody explain it in more detail for people who aren't seasoned system admins? Am I supposed to be moving files around and making links to them from the old directories?

cfr · 2013-06-28 21:53:37

I don't think that partition layout is possible unless you some of those partitions are logical partitions since MBR is limited to 4 primary partitions and does not support 5.

Trilby · 2013-06-28 21:54:38

There are five steps - follow them starting at 1, and moving towards 5. What part is confusing? I mean that as a real question, not as sarcasm, as one might need a little more detail here or there - but you have not given any indication of what you have done or what results you have seen - so all we could say is follow those five steps.

If you can elaborate ("I ran step 2 and got the following output .... does this mean I am ready to go to step 3"), then we could help. But even this, I am quite sure would be covered ad nauseum in the ridiculously long stickied thread on this very topic. I can't imagine a possible permutation that hasn't been covered in detail.

bananagranola · 2013-06-28 21:55:57

You are supposed to be moving some files, specifically the outputs listed by the command in #3 to /usr/bin, but you're not supposed to be making links to them. What specifically is unclear? There are quite a few other posts on that change, so you may find the answers you're looking for in those posts as well.

Last edited by bananagranola (2013-06-29 03:11:22)

cfr · 2013-06-28 21:57:25

You are NOT supposed to be moving files. Nowhere do the instructions tell you to do that and the stickied thread explains many times why this is a Very Bad Idea.

jasonwryan · 2013-06-28 22:07:40

cfr wrote:

You are NOT supposed to be moving files. Nowhere do the instructions tell you to do that and the stickied thread explains many times why this is a Very Bad Idea.

This. Merging with said thread.

PaulBx1 · 2013-06-28 22:15:53

As I pointed out, I had more detailed questions but the forum software trashed those.

So far I have learned I am supposed to be moving files, and not supposed to be moving them.

Number 1 looked like it was aimed at maintainers, not users.

For number 1 I got this:

[root@myhost ~]# pacman -Qqo /bin /sbin /usr/sbin | pacman -Qm -
grub 0.97-21
grub 0.97-21
[root@myhost ~]# ls -la /sbin|grep grub
-rwxr-xr-x  1 root root 918148 Nov  3  2011 grub
-rwxr-xr-x  1 root root  12920 Nov  3  2011 grub-install
-rwxr-xr-x  1 root root   2298 Nov  3  2011 grub-md5-crypt
-rwxr-xr-x  1 root root   2533 Nov  3  2011 grub-set-default
-rwxr-xr-x  1 root root   2473 Nov  3  2011 grub-terminfo
-rwxr-xr-x  1 root root   6179 Nov  3  2011 install-grub

Am I supposed to move these over, copy them, link them or what?

Ah now I notice my thread got merged. Some reading to do...

Last edited by PaulBx1 (2013-06-28 22:17:38)

PaulBx1 · 2013-06-28 22:35:11

Wow, 29 pages. This ought to be fun.

I got a result from #1. The instruction says to fix packages, but fixing packages is not in my job description. So I'm guessing #1 is directed at package maintainers not users, but I still am left wondering what to do with grub.

The instructions are far too terse and it is not clear who the instructions are directed at.

HalosGhost · 2013-06-28 22:35:43

No, you are supposed to not use outdated packages. If you're really attached to legacy grub, then use the legacy-grub package in the AUR. Do not manually copy files here; that is a terrible idea.

Paul, wrong, if you have packages that are causing conflicts, they are unsupported packages since all official packages were updated correctly. If you use unsupported packages, you are expected to maintain them yourself. All the instructions are aimed at the user doing the manual intervention; like pretty much always.

All the best,

-HG

Last edited by HalosGhost (2013-06-28 22:37:21)

PaulBx1 · 2013-06-28 23:02:17

I am attached to legacy grub, not because it is so wonderful, but because grub 2 is so awful. I don't know how I resolved the grub situation; that was maybe a year ago and my memory isn't that good. Not sure why copying files is such a bad idea anyway; this is legacy grub after all. I think I got maybe one thing out of AUR, some other package, and the whole procedure was a big pain in the ass. So telling me to go to AUR for legacy grub (which I thought was not being maintained - that is, being changed) does not fill me with joy.

I don't know if I "have packages that are causing conflicts" because I haven't done the upgrade yet. I'm still in the stage where I am trying to understand the instructions. I have the drive imaged so I'm not too worried but I still want to be able to move forward. Maybe I should wait for another couple of months for this thing to get sorted out.

If you use unsupported packages, you are expected to maintain them yourself. All the instructions are aimed at the user doing the manual intervention; like pretty much always.

You guys act like everyone is on top of exactly what the system is doing. Sorry to break this to you but lots of users like me don't recall a lot of crap we did to get things going. This upgrade is NOT "like pretty much always"; that's why you have a 29-page thread full of users bricking their systems. At some point it may dawn on you that the instructions need some work, for example like breaking it into two parts, one for package maintainers and another for users, and trying to explain what the user needs to do and what the upgrade handles automatically (e.g. links). Oh, and whether files need to be moved - there is still confusion on this point on page 29 of this thread.

Last edited by PaulBx1 (2013-06-28 23:04:18)

Arch Linux

#701 2013-06-24 12:31:51

Re: filesystem Update Error /bin exists in filesystem

#702 2013-06-24 14:56:19

Re: filesystem Update Error /bin exists in filesystem

#703 2013-06-24 14:59:28

Re: filesystem Update Error /bin exists in filesystem

#704 2013-06-24 20:36:09

Re: filesystem Update Error /bin exists in filesystem

#705 2013-06-24 20:50:30

Re: filesystem Update Error /bin exists in filesystem

#706 2013-06-24 21:47:28

Re: filesystem Update Error /bin exists in filesystem

#707 2013-06-27 19:47:05

Re: filesystem Update Error /bin exists in filesystem

#708 2013-06-27 19:54:27

Re: filesystem Update Error /bin exists in filesystem

#709 2013-06-27 22:29:55

Re: filesystem Update Error /bin exists in filesystem

#710 2013-06-28 13:02:34

Re: filesystem Update Error /bin exists in filesystem

#711 2013-06-28 14:53:10

Re: filesystem Update Error /bin exists in filesystem

#712 2013-06-28 14:57:16

Re: filesystem Update Error /bin exists in filesystem

#713 2013-06-28 15:03:15

Re: filesystem Update Error /bin exists in filesystem

#714 2013-06-28 20:06:08

Re: filesystem Update Error /bin exists in filesystem

#715 2013-06-28 20:51:06

Re: filesystem Update Error /bin exists in filesystem

#716 2013-06-28 21:49:16

Re: filesystem Update Error /bin exists in filesystem

#717 2013-06-28 21:53:37

Re: filesystem Update Error /bin exists in filesystem

#718 2013-06-28 21:54:38

Re: filesystem Update Error /bin exists in filesystem

#719 2013-06-28 21:55:57

Re: filesystem Update Error /bin exists in filesystem

#720 2013-06-28 21:57:25

Re: filesystem Update Error /bin exists in filesystem

#721 2013-06-28 22:07:40

Re: filesystem Update Error /bin exists in filesystem

#722 2013-06-28 22:15:53

Re: filesystem Update Error /bin exists in filesystem

#723 2013-06-28 22:35:11

Re: filesystem Update Error /bin exists in filesystem

#724 2013-06-28 22:35:43

Re: filesystem Update Error /bin exists in filesystem

#725 2013-06-28 23:02:17

Re: filesystem Update Error /bin exists in filesystem

Board footer