Taşıma kutusu ve diğer klasörler! Onları nasıl geri getirebilirim?

Tüm klasörleri yanlışlıkla kökten bir alt klasöre taşıdım. ( /bin, /etc, /home, /lib, /usrKullanımda beri, taşınan değil sadece olanları ... bütün taşındı) vardır /bak, /boot, /dev, /proc, /sys.

Şimdi, yürütmeye çalıştığım herhangi bir komut gerçekleşmeyecek. Sürekli "Böyle bir dosya veya dizin yok" alıyorum.

Ssh ve ftp aracılığıyla bağlıyım, ancak doğrudan SU girişi devre dışı olduğundan dosyaları ftp üzerinden taşıyamıyorum. Doğrudan oradan bir şey yapmam gerekirse gerçek sunucuya da erişebilirim.

/binKlasörü nerede bulacağımı ve tekrar erişmeme yardımcı olacağını söylemek için bir yapılandırma dosyasını düzenlemeniz gerektiğini varsayıyorum , ancak hangi dosyanın olacağını veya nasıl yapılacağını bilmiyorum (çünkü chmodizinleri değiştirmek için bile çalışamaz ).

Yeniden kurulum dışında bundan kurtulmanın bir yolu var mı?

CentOS'un eski bir sürümü üzerinde çalışıyorum.

_{Linux dünyasında son derece yeniyim, dolayısıyla bu eylem ve soru ...}

Hala bir kök kabuğunuz varsa, sisteminizi onarma şansınız olabilir. Diyelim ki tüm ortak dizinleri taşındı diyelim ( /bin, /etc, /lib, /sbin, /usr- bunlar kurtarma zorlaştıracak olanlar) altında /oops.

mvTam yolu belirtmiş olsanız bile komutu doğrudan veremezsiniz /oops/bin/mv. Çünkü mvolduğunu dinamik bağlantılı ; çünkü /libdizini taşıdınız, mvçalışamaz çünkü kodunun bir parçasını oluşturan kütüphaneleri bulamaz. Aslında, bundan daha da kötü: dinamik yükleyiciyimv bulamıyorum (ad, mimarinize ve unix varyantınıza bağlı olarak değişebilir ve dizin veya gibi farklı bir ad olabilir ). Bu nedenle, dizini geri taşıyana kadar, bağlayıcıyı açıkça çağırmanız ve taşınan kitaplıkların yolunu belirtmeniz gerekir. İşte Debian squeeze i386 üzerinde test edilen komut. /lib/ld-linux.so.2/lib32/lib64/lib

export LD_LIBRARY_PATH=/oops/lib:/oops/lib/i386-linux-gnu
/oops/lib/ld-linux.so.2 /oops/bin/mv /oops/* /

Diğer dağıtımlar veya mimariler için bunu biraz ayarlamanız gerekebilir. Örneğin, x86_64'teki CentOS için:

export LD_LIBRARY_PATH=/oops/lib:/oops/lib64
/oops/lib64/ld-linux-x86-64.so.2 /oops/bin/mv /oops/* /

Bir şeyi batırdığınızda /lib, statik olarak bağlı bir araç kutusunun etrafta kalmasına yardımcı olur. Bazı dağıtımlar (CentOS hakkında bilmiyorum), Busybox'ın statik olarak bağlı bir kopyasını sağlar . Ayrıca birçok komut içeren yerleşik bir kabuk olan kanat var . Bunlardan birine sahipseniz, iyileşmenizi oradan yapabilirsiniz. Onları gerçeklerden önce kurmadıysanız, çok geç.

# mkdir /oops
# mv /lib /bin /oops
# sash
Stand-alone shell (version 3.7)
> -mv /oops/* /
> exit

Artık bir kök kabuğunuz yoksa, ancak hala bir SSH artalan dinlemeniz varsa ve doğrudan ssh üzerinden root olarak giriş yapabilirsiniz ve bu statik olarak bağlı araç kutularından birine sahipseniz, ssh yapabilirsiniz. taşındıysanız eğer çalışabilir /libve /binancak /etc.

ssh root@broken.example.com /oops/bin/sash
root@broken.example.com's password:
Stand-alone shell (version 3.7)
> -mv /oops/* /

Bazı yöneticiler, statik olarak bağlı bir kabukla alternatif bir hesap oluşturur veya kök hesabın yalnızca bu tür bir sorun için statik olarak bağlı bir kabuk kullanmasını sağlar.

Bir kök kabuğunuz yoksa ve önlem almadıysanız, bir Linux canlı CD / USB'den önyükleme yapmanız gerekir (herhangi biri disklerinize ve dosya sistemlerinize erişebilecek kadar yeni olduğu sürece) ve dosyaları geri taşıyın.

Büyük olasılıkla yeniden başlatmadan kurtarabilirsiniz, bu yüzden başka şeyler denemeden yeniden başlatmayın çünkü önyükleme yapmaz. Hala SSH oturumunuz açıksa şunu deneyin:

• Programların çalıştığı yer $ PATH değişkeni kullanılarak ayarlanır. Yeni kutu konumunuzu çalıştırarak yola ekleyebilirsiniz export PATH="$PATH:/newpath/to/bin:/newpath/to/usr/bin". İlgili sbin dizinlerini de eklemeniz gerekebilir . Ayrıca programları tam yolu üzerinden manuel olarak da çalıştırabilirsiniz /path/to/mv [from] [to], örneğin mv farklı bir konumda olsa bile çalışmalıdır. Zor kısmı, çoğu komutun ortak kütüphanelere erişmek isteyeceği ve /libtaşındığını söylediğiniz için, bunun için de bir değişken ayarlamanız gerekir.export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/newpath/to/lib/:/newpath/to/usr/lib

• Bazı temel komutları yürütebildiğinizde, dosyaları geri taşıyın! mv /path/to/subfolder/* /sırayla olurdu! Her şey yerine oturduğunda, sistem normal davranmalıdır.

Bu başarısız olursa, HERHANGİ BİR LiveCD'yi başlatmak ve sürücüyü monte etmek klasörleri ait oldukları yere geri taşımanıza izin vermelidir. Dağıtım livecd'inizi yeniden yüklemenize veya hatta kullanmanıza gerek yoktur, sadece sürücüyü bağlamanız ve klasörleri diskte doğru konuma geri taşımanız yeterlidir. Linux tabanlı kurtarma diski bir sürü size bu tür onarım yapmak için sadece birkaç temel konsol araçları vermek konusunda uzmanım.

Bilgisayarı bir kurulum CD'si ile tek kullanıcı modunda yeniden başlatabilmeli, kök dosya sistemini bağlayabilmeli ve dosyaları tekrar Linux'ta taşıyabilmelisiniz. Fazla centos bilmiyorum, ama RHEL gibi, bu yüzden bu işe yaramalı.

5 yıl sonra Gilles'e çok teşekkürler ve gönderileriniz hafta olmasa bile günümü kurtardı.

Bir alt klasörün içeriğini geçerli klasöre taşımak mv sub/* .istedim, ama yerine, mv sub /* .her şeyi geçerli klasöre taşıdım. Neyse ki bu cevabı buldum ve makinemi göreceli olarak kolayca düzeltebiliyordum. Ancak Ubuntu 16.04 çalıştıran bir x86_64 makinesinde çalıştığım için komutları biraz ayarlamam gerekiyordu. Herkesin mücadele etmesi durumunda talimatları burada bırakmak istiyorum:

export LD_LIBRARY_PATH=/oops/lib:/oops/lib/x86_64-linux-gnu
/oops/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /oops/bin/mv /oops/* /

Modern sistemlere (Unix çalışan x86_64 makineleri) Ktipr'ın cevabını uyguladıktan sonra yapmak için birkaç komut daha eklemek istiyorum , hata gösterdiğinden mv ile taşınan dizinleri "vb" alamadım

Error : Directory not empty

bu yüzden kullanmak zorunda kaldım

rsync -a source_file target_location

her şeyi sırayla geri alabildiğimden emin olmak için. Zaten kurulu değilse, önce kurmanız gerekir.