/ bin 내용을 / usr / bin으로 옮겼습니다. 실행 취소 할 수 있습니까?

18

우분투 17.04를 실행하면서 비 리포지토리 배포에서 소프트웨어를 설치하고 있었고 소프트웨어 bin 폴더 내용을 / usr / bin으로 옮기기로되어있었습니다 (이미 조언이있었습니다)

그 시절 중 하나이므로 대신 내가 한 일 :

mv /bin/* /usr/bin

그래서 나는 망 쳤고 우연히 bin의 모든 파일을 / usr / bin으로 옮겼으며 / bin은 비어있었습니다. / bin은 시스템에 중요하므로 빠른 해결을 위해 / usr / bin 내용을 / bin에 복사했습니다.

이제 내 / bin 및 / usr / bin 내용은 동일하며 둘 다 원래 / bin 및 / usr / bin에있는 파일이 분리되어 있습니다.

우분투가 고장난 상태입니까? (아직 컴퓨터를 재부팅하지 않았지만 지금은 모든 것이 여전히 작동하는 것 같습니다)
최근에 어떤 파일이 / usr / bin으로 이동 / 복사되었는지 알 수있는 방법이 있습니까? 그래서 수동으로 상황을 처리 할 수 있습니까? 2.1 / bin 및 / usr / bin에 일반적으로 겹치는 파일이 있습니까?
내가 한 일을 취소하는 다른 방법이 있습니까?

Timeshift가 설치되어 있지 않으므로 백업 복원이 옵션이 아니지만 현재 컴퓨터에 중요한 것은 없으므로 전체 Linux 파티션을 다시 설치하는 것을 인정할 수 있습니다.

— oneOfThoseDays
소스

2

dpkg-query -l | awk '{system ( "dpkg-query -L"$ 2 "| grep -E \"^ / usr / bin /.*$ \ "")}'이렇게하면 처음에 / usr / bin에있는 모든 파일이 제공됩니다 설치된 패키지

— Raman Sailopal

7

@ SatōKatsura /bin는 시스템에 매우 중요합니다. 내용은 가장 빠른 부팅 단계에 있어야합니다. /usr부팅시 마운트되지 않은 파티션 ( 여기)에 대한 심볼릭 링크를 생성하지 않으려 고합니다 .

— xhienne

1

@xhienne 나는 재부팅 후에도 살아남을 것이라고 결코 말하지 않았다. 시스템을 복구 할 수있는 충분한 기능을 얻기위한 임시 수정입니다.

— Satō Katsura

1

@xhienne는 배포판 설정 방법에 따라 다릅니다. 예를 들어, 아치 /bin는 기본적으로 별도 를 유지하지 않습니다 . 우분투의 기본 파티션은 별도의 /usr파티션을 만들지 않습니다 . 실제로 /usr현대의 배포판 으로 얼마나 많은 사람들이 별거 하고 있는지 궁금 합니다.

— muru

1

@muru 일반적인 의견으로 의견을 남겨주세요. 파티션 수에 상관없이 원하는 것을 가정 할 수 있습니다 ./usr/bin/*을 / bin에 연결하는 것에 대해 경고합니다. . FHS를 따르는 시스템에는 / usr / bin에 대한 심볼릭 링크가 없어야합니다. 대신 파일을 복사하는 것이 좋습니다.

— xhienne

19

우분투가 고장난 상태입니까?

예, 우분투가 고장났습니다

패키지 관리에 중요한 것을 엉망으로 만들었습니다 .

실제로 중요한 데이터 (적어도 /etc및 /home), 설치된 패키지 목록 (예 : 출력)을 백업 dpkg -l하고 Ubuntu를 다시 설치하십시오.

^{(비 초보자는 다른 답변과 마찬가지로 관리하려고 시도 할 수는 있지만 그렇게 큰 기본 실수를하지 않았을 것입니다)}

나는 전체 리눅스 파티션을 다시 설치하는 것을 인정할 수 있었다.

아마도 시간을 덜 소비 할 것입니다. 다른 답변의 도움으로 현재 시스템을 유지하는 것은 매우 지저분한 상태로 유지하는 것입니다 (미래의 두통을 유발할 수 있음).

디스크를 재 포맷 /home하고 있으므로 별도의 파티션에 넣는 것을 고려하십시오 (따라서 이러한 실수는 데이터를 잃지 않을 것입니다). 종이에 인쇄하기 전에 df -h및 의 출력 df -hi및 fdisk -l(사용 된 디스크 공간과 사용 가능한 디스크 공간에 대한 정보를 제공합니다.) 충분히 큰 시스템 파티션 (루트 파일 시스템)을 갖는 것이 좋습니다. 여유가 있다면 100GB 이상이면 충분합니다.

소프트웨어 bin 폴더 내용을 / usr / bin으로 옮기기로되어있었습니다.

(용어 : Unix에는 "폴더"가 아닌 디렉토리가 있습니다).

(로 이동하는 것은 /usr/bin/) 매우 잘못되었습니다. $ PATH를 향상 시키 거나 (바람직하게는) 심볼릭 링크 를 추가 /usr/bin/하고 실행 파일을로 이동 (또는 심볼릭 링크 추가)하는 것이 /usr/local/bin/좋습니다.

현명한 접근 방법은 결코 변경하는 것입니다 /usr/bin/, /bin, /sbin, /usr/sbin/ 패키지 관리 도구의 외부 (예 dpkg, apt-get, aptitude, 등 ...). FHS를 읽으십시오 .

— 바 실레 스타 인케 비치
소스

4

이 답변을 수락하려고합니다. 복구하려고 시도한 후 재부팅 할 때까지 작동하여 데스크탑 환경 세션을 더 이상 시작할 수 없었습니다. 이 문제를 해결하는 대신 전체 나사를 인정하고 리눅스 파티션을 다시 설치합니다. 모든 것이 버전 관리에 있었고 시스템을 일주일 동안 만 사용했기 때문에, 실제로 잃어버린 것은 저의 존엄성과 작은 공황 발작 만 있었지만, 인생이 저에게 교훈을 줄 때 정상적인 것 같습니다.

— oneOfThoseDays

1

현재 /bin와 /usr/bin동일하지만 패키지 관리가 왜 망쳐 질지 잘 모르겠습니다. 패키지에 의해 /bin/foo그리고 /usr/bin/foo둘 다 제공되는 경우가 실제로 있습니까? 그렇지 않은 경우 추가 파일이 떠 있습니다.

— StrongBad

3

@Basile 아니, 불행하지 않을 것이다; 패키지 관리는 자신이 알고있는 파일에 대해서만 신경 쓰고 모르는 파일에 대해서는 불평하지 않습니다. 심지어는 파일 않는 그들이 변경 한 경우에 대해 알고, 그것은 특히 귀찮게하지 않습니다 ...

— 스티븐 키트

2

@Basile은 또한 후자에 의지하지 않을 것입니다.“(비 초보자도 다른 답변과 마찬가지로 관리하려고 시도 할 수는 있지만 그렇게 큰 기본 실수를하지 않았을 것입니다.”) 사실 ;-). 전문가조차 가끔 미끄러 져갑니다!

— Stephen Kitt

1

FWIW 내 주요 시스템 /파티션은 12GB이며 KDE (최신이 아닌 읽기)에서 개발 (헤더 파일 및 많은 도구 읽기) 사무실 및 디자인 (무거운 도구 읽기)을 위해 사용하더라도 공간 문제가 발생하지 않았습니다. 분할하지 않으면 4GB를 더 많이 /var던지고, 내가 가진 것보다 더 큰 마진을 원하면 25 % 팽창하고, 20GB는 더 좋습니다.

— 스펙트럼

36

Linux (및 대부분의 다른 시스템에서 POSIX는 파일 시스템을 통한 이동이 아니라면 보증을 제공하지는 않지만), /usr/bin지난 24 시간 동안 다른 시스템 중 어느 것도 건드리지 않았다고 가정하여 ctime을 업데이트했습니다. 다음을 사용하여 다시 이동할 수 있어야합니다.

find /usr/bin/. ! -name . -prune -ctime -1 -exec sh -c '
   echo mv -i "$@" /bin' sh {} +

echo제대로 보이는 경우를 제거하십시오 . 주 당신이 동일한 이름으로 존재하는 파일을 복구 할 수 없다는 점 /bin과 /usr/bin(원래 사람 /usr/bin유실되었을 것이다)

잠재적 인 경고 : 일부 파일이 /bin및로 /usr/bin하드 링크 된 경우 모든 하드 링크 /usr/bin가로 이동됩니다 /bin.

이제, 당신이 있기 때문에 그렇게 생각 /bin하고 /usr/bin기본에 $PATH, 그리고 /bin볼 수 있습니다 /boot전에 적어도 /usr장착, 그것은 실행 파일에 안 문제 여부를 /bin대신 /usr/bin.

그러나 많은 명령이 실행 파일의 경로를 하드 코딩하고 특정 경우에 예상되는 것을 간과하고 있습니다. 일반적인 경우는 그녀의 앞머리입니다. 다음을 가진 모든 스크립트 :

#! /usr/bin/env bash

당신이 후에 작동하지 않을 것 mv /usr/bin/env /bin/env입니다. 이와 관련하여 두 위치 모두에서 명령을 갖는 것이 스크립트를 손상시키지 않기 때문에 더 안전합니다.

— 스테판 샤 첼라
소스

3

위에서 언급 한 바와 같이 (나는 GNU Coreutils가 지원 i하기 find /usr/bin/. ! -name . -prune -ctime -1 -exec echo mv -it /bin {} +때문에 우분투와 같은 GNU / Linux 시스템에서 사용할 수 있는 심각한 오류가있어서 죄송 합니다 . 다른 OS 는 일반적 으로이 기능을 지원하지 않으며 BusyBox에서 제공 하는 대체 기능 에서도 작동하지 않습니다 . mv-tmv

— Eliah Kagan

17

설치는 대부분 정상이어야합니다. 같은 이름을 가진 다른 파일이 없어야 /usr하며 /usr/bin(2.1에 대답) 모든 파일을 모두 가지고 /bin있고 /usr/bin아무것도 깨지 않을 것입니다 (패키지를 업그레이드 할 때까지). 바이너리로 심볼릭 링크를 덮어 쓴 경우, 현재 유일하게 발생할 수있는 문제는 심볼릭 링크가 깨진 것입니다. 이 문제를 해결하려면 깨진 심볼릭 링크를 찾으십시오.
```
find -L /bin /usr/bin -type l -ls
```
나열된 파일에 해당하는 모든 패키지를 다시 설치하십시오 (예를 들어, /usr/bin/zsh깨진 것으로 표시 dpkg -S /bin/zsh /usr/bin/zsh되면 파일을 제공 한 패키지를 알려주고로 다시 설치하십시오 apt --reinstall install zsh).
ctime을 기준으로 표시하고 정렬하여 최근에 변경된 파일 (이동 한 파일 포함)을 볼 수 있습니다.
```
ls -ltc /bin
```
수행 한 작업을 실행 취소하는 가장 좋은 방법은 cruft패키지를 사용하고 패키지에서 찾 /bin거나 /usr/bin패키지에서 제공되지 않은 파일을 삭제 하는 것입니다.
```
sudo apt install cruft
sudo cruft -d "/ /usr"
```
파일이 파일의 심볼릭 링크가 아닌 /etc/alternatives경우 (이 경우 파일을 그대로 두어야 함)

— 스티븐 키트
소스

시작 #! /bin/sh하거나 유사한 스크립트는 제외합니다 .

— Satō Katsura

@ SatōKatsura sh는 모두 /bin및 /usr/bin(모든 파일이 지금 복제 됨)에 있으면 여전히 잘 작동합니다 .

— Stephen Kitt

1

cruft패키지 관리자는 설치된 파일을 추적하기 때문에이 작업 에는 특별한 툴크 가 필요하지 않습니다. unix.stackexchange.com/questions/153260/…을 참조하십시오 .

— Ned64

1

comm -12 <(ls /bin) <(ls /usr/bin)내가 테스트 한 우분투 시스템의 몇 가지 항목을 보여줍니다. /bin/foo -> /usr/bin/foo의미 있는 일부는 foo손실되었을 것입니다.

— Stéphane Chazelas

@ Stéphane 아 예, 링크를 이동하면 원본을 nu 것입니다 ...

— Stephen Kitt

6

시스템이 '깨진' 이유 를 설명하는 것이 교육적 일 수 있습니다 .

@ basile-starynkevitch가 지적했듯이, 패키지 관리 시스템은 바이너리가 /bin있어야 할 때 바이너리를 찾으면 혼란 스러울 수 있습니다 /usr/bin.
일부 (아마도 중요한) 스크립트는 한 디렉토리 또는 다른 디렉토리에서 특정 바이너리를 찾기 위해 연결되어 있지 않을 수 있습니다 (일부 상황에서는 보안 관점 에서의 내용에 의존 하지 않는 것이 $PATH좋습니다).
이 구별되는 이유 /bin와 /usr/bin이전의 잠재적 부팅의 초기 단계에 설치되어있는 파티션에있을 수 있다는 것이다. 이러한 맥락에서 (즉, 시스템을 부팅 할 때) /bin/xxx바이너리는 전체 경로로 참조 될뿐만 아니라 /usr/bin해당 시점에 시스템에서 디렉토리를 사용하지 못할 수도 있습니다. ( df /bin및의 경우 df /usr/bin동일한 파일 시스템이 표시되거나 다른 파일 시스템이 표시 될 수 있습니다. 요즘 대부분의 기본 설치는 두 디렉토리를 모두 같은 파티션에 그대로 둡니다).

따라서 당신은 당신이있는 경우, 그 볼 doubless 수 있습니다 동일한 모두 바이너리 /bin및 /usr/bin발생하지 다음, 문제 2, 3, 1의 손상은 사소한 수 있습니다. 예를 들어 Re 1을 제거하려고하면 패키지가 제대로 제거되지 않을 수 있습니다. 업그레이드가 '올바른'위치에서 사본을 업그레이드하려고하지만 '잘못된'위치의 사본은 무시하면 업그레이드가 깨질 수 있습니다. 위의 구제가 너무 급격하게 또는 복잡하게 보이는 경우 따라서, 당신은 수있는 이 상태에서 시스템을 떠나 멀리 얻을.

그러나 이것이 중요한 시스템 이라면 , 나는 그것에 대해 실제로 돈을 쓰지 않을 것입니다.

(다시 실레 - starynkevitch @ 반향) 일반적인 규칙과 원숭이에 결코 /usr/bin, /bin친구 - 그리고는 ... 안 좋은 패키지 설치 정상의 일환으로 그렇게 제안 패키지 - 그들은 분포에 '속해'.

편집 : 관련 3을 가리 키도록은, 거기이다 systemd / 페도라와 친구의 맥락에서 논의 가의 모든 내용 이동하는 것이 합리적 이유 /bin에를 /usr/bin두 번째로 첫 번째와 심볼릭 링크. 이것은 페이지를 배포하는 사람들에게 다룰 수있는 권장 사항 은 아니지만 이 차이가 존재하는 이유에 대한 역사를 포함합니다 (이제 왜 먼지가 많은 전통인지에 대한 암시).

— 노먼 그레이
소스