Pindah / isi bin ke / usr / bin, mungkin dibatalkan?

18

Menjalankan Ubuntu 17.04, saya menginstal perangkat lunak dari distribusi non-repositori, saya seharusnya memindahkan isi perangkat lunak - isi folder ke / usr / bin (yang sudah saran yang rapuh)

Ini salah satu dari hari-hari itu, jadi apa yang saya lakukan sebagai gantinya:

mv /bin/* /usr/bin

Jadi saya mengacaukan dan saya tidak sengaja memindahkan semua file di bin ke / usr / bin dan / bin kosong. Karena saya menganggap bahwa / bin adalah sistem yang kritis, untuk perbaikan cepat, saya menyalin / usr / bin ke / bin.

Sekarang isi / bin dan / usr / bin saya identik dan keduanya berisi file yang semula di / bin dan / usr / bin dipisahkan.

Apakah Ubuntu saya dalam keadaan rusak sekarang? (Belum mencoba untuk me-reboot komputer, sekarang semuanya tampaknya masih berfungsi)
Apakah ada cara untuk mengetahui file mana yang telah dipindahkan / disalin ke / usr / bin baru-baru ini, jadi saya bisa secara manual menangani situasinya? 2.1 Apakah biasanya ada file yang tumpang tindih di / bin dan / usr / bin
Apakah ada cara lain untuk membatalkan apa yang saya lakukan?

Saya tidak menginstal Timeshift sehingga memulihkan cadangan bukanlah suatu pilihan, tetapi saat ini tidak ada yang penting pada komputer, jadi saya bisa mengakui untuk menginstal ulang seluruh partisi linux.

— oneOfThoseDays
sumber

2

dpkg-query -l | awk '{system ("dpkg-query -L" $ 2 "| grep -E \" ^ / usr / bin /.*$ \ "")}' Ini akan memberi Anda semua file awalnya di / usr / bin berdasarkan paket diinstal

— Raman Sailopal

7

@ SatōKatsura /binadalah sistem yang kritis. Kontennya harus ada pada tahap boot paling awal. Anda tidak ingin membuat tautan simbolis ke partisi (di /usrsini) yang mungkin tidak dipasang saat boot.

— xhienne

1

@xhienne Saya tidak pernah mengatakan itu akan selamat dari reboot. Ini perbaikan sementara, untuk mendapatkan fungsionalitas yang cukup untuk dapat memperbaiki sistem.

— Satō Katsura

1

@xhienne itu tergantung pada bagaimana Anda mengatur distro. Arch, misalnya, tidak mempertahankan terpisah /binsecara default. Partisi default Ubuntu tidak membuat /usrpartisi terpisah . Saya ingin tahu berapa banyak orang yang benar-benar membuat terpisah /usrdengan distro modern.

— muru

1

@muru Ambil komentar saya sebagai komentar umum. Anda dapat mengasumsikan apa pun yang Anda inginkan pada jumlah partisi, saya lebih suka tidak melakukannya dan saya memperingatkan agar tidak menghubungkan / usr / bin / * ke / bin, yang paling tidak berguna dan paling buruk dapat membuat sistem tidak dapat digunakan pada boot berikutnya. . Tidak ada sistem yang mengikuti FHS yang harus mengandung symlink ke / usr / bin. OP disarankan untuk menyalin file sebagai gantinya.

— xhienne

19

Apakah Ubuntu saya dalam keadaan rusak sekarang?

Ya, Ubuntu Anda rusak

Anda mengacaukan sesuatu yang penting untuk manajemen paket .

Jadi dalam praktiknya, buat cadangan data penting Anda (setidaknya /etcdan /home), mungkin juga daftar paket yang diinstal misalnya output dari dpkg -l, dan instal ulang Ubuntu.

^{(non-pemula bisa mencoba untuk mengelola - seperti dalam jawaban lain -, tetapi kemudian dia tidak akan melakukan kesalahan besar dan mendasar seperti itu)}

Saya hanya bisa mengakui menginstal ulang seluruh partisi linux.

Mungkin itulah yang akan menghabiskan sedikit waktu Anda. Menjaga sistem Anda saat ini dengan bantuan jawaban lain adalah menjaganya dalam keadaan sangat berantakan (yang akan membuat Anda sakit kepala di masa depan).

Karena Anda memformat ulang disk Anda, pertimbangkan untuk meletakkan /homedi partisi yang terpisah (sehingga kesalahan di masa depan tidak akan kehilangan data Anda). Sebelum melakukan itu cetak di atas kertas keluaran df -hdan df -hidan fdisk -l(mereka memberikan informasi tentang ruang disk -keduanya digunakan dan tersedia- ...). Bijaksana memiliki partisi sistem yang cukup besar (sistem file root); jika Anda mampu membelinya 100 Gbytes lebih dari cukup.

Saya seharusnya memindahkan nampan perangkat lunak - isi folder ke / usr / bin

(terminologi: Unix memiliki direktori, bukan "folder").

Itu ( pindah ke /usr/bin/) sangat salah. Tingkatkan $ PATH Anda (lebih disukai) atau paling banyak tambahkan symlink di /usr/bin/dan lebih baik pindahkan (atau tambahkan symlink) executable ke /usr/local/bin/.

Pendekatan yang bijaksana adalah untuk tidak pernah berubah /usr/bin/, /bin, /sbin, /usr/sbin/ di luar alat-alat manajemen paket (misalnya dpkg, apt-get, aptitude, dll ...). Baca FHS .

— Basile Starynkevitch
sumber

4

Akan menerima jawaban ini: tampaknya setelah mencoba memulihkannya berfungsi hingga reboot, yang tidak dapat lagi meluncurkan sesi lingkungan desktop apa pun. Daripada mencoba untuk memperbaikinya, saya akan mengakui total saya kacau dan hanya akan menginstal ulang partisi linux. Karena semuanya ada di kontrol versi dan saya telah menggunakan sistem hanya selama seminggu, semua saya benar-benar kehilangan adalah martabat saya dan memiliki serangan panik kecil, tetapi itu tampak normal ketika hidup memberi saya pelajaran.

— oneOfThoseDays

1

Seperti /bindan /usr/binsekarang identik, saya tidak yakin mengapa manajemen paket akan kacau. Apakah benar ada kasus di mana /bin/foodan /usr/bin/fookeduanya disediakan oleh paket (s). Jika tidak, hanya ada beberapa file tambahan yang beredar.

— StrongBad

3

@Basile tidak, itu tidak akan (tidak bahagia); manajemen paket hanya peduli tentang file yang diketahuinya, tidak akan mengeluh tentang file yang tidak diketahuinya. Bahkan untuk file itu tidak tahu tentang, itu tidak akan sangat terganggu jika mereka sudah berubah ...

— Stephen Kitt

2

@Basile juga saya tidak akan mengandalkan bagian terakhir "(seorang non-pemula bisa mencoba untuk mengelola - seperti dalam jawaban lain -, tapi kemudian dia tidak akan melakukan kesalahan besar dan mendasar)" benar ;-). Bahkan para ahli kadang-kadang muncul!

— Stephen Kitt

1

FWIW /partisi sistem utama saya adalah 12GB dan saya tidak pernah mengalami masalah ruang walaupun menggunakannya untuk pengembangan (baca file header dan banyak alat) kantor dan desain (baca alat berat), di KDE (baca bukan yang paling ramping). Lemparkan dalam 4GB lebih banyak jika Anda tidak membagi /var, mengembang sebesar 25% jika Anda ingin margin yang lebih besar dari yang saya miliki, dan pada 20GB Anda lebih dari baik.

— spektra

36

Di Linux (dan pada sebagian besar sistem lain, meskipun POSIX tidak memberi Anda jaminan itu kecuali perpindahannya melintasi sistem file), itu akan memperbarui waktu mereka, jadi dengan asumsi tidak ada yang lain yang /usr/bintelah disentuh dalam 24 jam terakhir , Anda harus dapat memindahkannya kembali dengan:

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

Hapus echojika itu terlihat benar. Perhatikan bahwa Anda tidak akan dapat memulihkan file yang ada dengan nama yang sama di /bindan /usr/bin(yang asli di /usr/binakan hilang)

Peringatan potensial: jika beberapa file sulit ditautkan di keduanya /bindan /usr/bin, semua tautan keras /usr/binakan dipindahkan ke /bin.

Sekarang, Anda mungkin berpikir bahwa karena /bindan /usr/binberada di default $PATH, dan /bintersedia /bootsetidaknya sebelum di /usr-mount, seharusnya tidak masalah apakah executable berada /binsebagai gantinya /usr/bin.

Tapi itu akan mengabaikan banyak perintah yang mengkode jalur executable dan mengharapkannya dalam beberapa kasus tertentu. Kasus yang umum adalah dia-poni. Semua skrip yang memiliki:

#! /usr/bin/env bash

akan gagal bekerja setelah Anda melakukannya mv /usr/bin/env /bin/env. Dalam hal itu, memiliki perintah di kedua lokasi lebih aman karena tidak akan merusak skrip tersebut.

— Stéphane Chazelas
sumber

3

Seperti disinggung di atas (saya menghapus komentar saya karena memiliki kesalahan serius yang akan mencoba untuk memindahkan semuanya ke direktori yang disebut - imaaf tentang itu!) Pada sistem GNU / Linux seperti Ubuntu yang dapat digunakan find /usr/bin/. ! -name . -prune -ctime -1 -exec echo mv -it /bin {} +sejak GNU Coreutilsmv mendukung -t. OS lain umumnya tidak mendukungnya , juga tidak bekerja di alternatif yang mvdisediakan oleh BusyBox .

— Eliah Kagan

17

Instalasi Anda sebagian besar harus OK; seharusnya tidak ada file yang berbeda dengan nama yang sama /usrdan /usr/bin(yang menjawab 2.1 Anda), sehingga memiliki semua file di keduanya /bindan /usr/bintidak akan merusak apa pun (sampai Anda meningkatkan paket). Satu-satunya masalah yang mungkin Anda miliki sekarang adalah symlink yang rusak, jika Anda menimpa biner dengan symlink padanya. Untuk memperbaiki ini, cari symlink yang rusak:
```
find -L /bin /usr/bin -type l -ls
```
dan instal ulang paket apa pun yang terkait dengan file yang terdaftar (misalnya, jika /usr/bin/zshterlihat rusak, dpkg -S /bin/zsh /usr/bin/zshakan memberi tahu Anda paket mana file itu berasal; pasang kembali dengan apt --reinstall install zsh).
Anda dapat menampilkan dan mengurutkan berdasarkan waktu untuk melihat file yang baru saja diubah (yang akan menyertakan file yang Anda pindahkan):
```
ls -ltc /bin
```
Pendekatan terbaik untuk membatalkan apa yang Anda lakukan adalah menggunakan cruftpaket dan menghapus file yang ditemukannya /binatau /usr/binyang tidak berasal dari paket:
```
sudo apt install cruft
sudo cruft -d "/ /usr"
```
kecuali file-file tersebut adalah symlink ke file dalam /etc/alternatives(dalam hal ini Anda harus membiarkannya sendiri).

— Stephen Kitt
sumber

Kecuali untuk skrip yang dimulai dengan #! /bin/shatau serupa.

— Satō Katsura

@ SatōKatsura mereka masih akan berfungsi dengan baik jika shada di keduanya /bindan /usr/bin(semua file digandakan sekarang).

— Stephen Kitt

1

Toolk khusus seperti cruftini tidak diperlukan untuk pekerjaan ini karena manajer paket juga melacak file yang diinstal. Lihat unix.stackexchange.com/questions/153260/… .

— Ned64

1

comm -12 <(ls /bin) <(ls /usr/bin)menunjukkan beberapa entri pada sistem Ubuntu tempat saya mengujinya. Beberapa dengan /bin/foo -> /usr/bin/fooyang berarti fooakan hilang.

— Stéphane Chazelas

@ Stéphane ah ya, memindahkan tautan akan mengeluarkan yang asli ...

— Stephen Kitt

6

Mungkin mendidik untuk menguraikan mengapa sistem Anda, pada tingkat yang lebih besar atau lebih kecil, 'rusak'.

Seperti yang ditunjukkan oleh @ basile-starynkevitch, sistem manajemen paket memiliki potensi yang sangat membingungkan jika menemukan binari /binketika mereka seharusnya berada /usr/bin, dan sebaliknya.
Beberapa skrip (mungkin penting) mungkin terprogram untuk menemukan biner tertentu dalam satu direktori atau lainnya (dalam beberapa keadaan itu praktik yang baik, misalnya dari sudut pandang keamanan, tidak bergantung pada konten dari $PATH).
Alasan mengapa ada perbedaan antara /bindan /usr/binadalah bahwa yang pertama berpotensi berada pada partisi yang dipasang pada tahap awal boot. Dalam konteks ini (yaitu, ketika mem-boot sistem), tidak hanya /bin/xxxbinari mungkin akan dirujuk oleh path lengkap, tetapi direktori /usr/binmungkin tidak tersedia pada sistem pada saat itu. (Jika Anda df /bindan df /usr/bin, Anda mungkin melihat sistem file yang sama terdaftar, atau yang berbeda; mungkin sebagian besar instalasi default, hari ini, biarkan kedua direktori di partisi yang sama).

Dengan demikian Anda dapat berlipat ganda melihat bahwa, jika Anda memiliki binari yang sama di keduanya /bindan /usr/bin, maka masalah 2 dan 3 tidak akan terjadi, dan kerusakan dari 1 mungkin kecil. Re 1, misalnya, paket mungkin tidak dihapus dengan benar jika Anda mencoba menghapusnya; dan pemutakhiran mungkin menjadi kacau, jika pemutakhiran mencoba untuk meningkatkan salinan di tempat yang 'benar', tetapi mengabaikan salinan di tempat yang 'salah'. Jadi, jika solusi di atas tampak terlalu drastis atau rumit, Anda mungkin lolos dengan meninggalkan sistem dalam keadaan ini.

Tetapi jika ini adalah sistem yang penting, saya benar - benar tidak akan mengandalkan itu.

Aturan umum (lagi-lagi menggemakan @ basile-starynkevitch) tidak pernah untuk diajak /usr/bin, /bindan teman - mereka 'termasuk' dalam distribusi - dan paket yang menyarankan melakukan hal itu sebagai bagian dari instalasi normal adalah ... bukan paket yang baik.

Sunting: Relevan ke poin 3, ada diskusi dalam konteks systemd / Fedora dan teman - teman mengapa masuk akal untuk memindahkan semua konten /binke /usr/bin, dan symlink yang pertama ke yang kedua. Ini bukan rekomendasi agar Anda melakukan ini, sendiri - halaman itu ditujukan kepada orang-orang yang melakukan distribusi - tetapi itu mencakup beberapa sejarah mengapa perbedaan ini ada (dan dengan implikasi mengapa sekarang hanya tradisi yang berdebu).

— Norman Gray
sumber