Newsgroup: it.comp.os.linux.sys
Titolo: Non riesco a fare chroot

Ciao a tutti,
al fine di rendere avviabile un disco clonato, cerco di fare chroot, per poi 
installare grub, ma non ci riesco.
 
Dettagli:
- ho una Debian Squeeze (amd64) su sda (sda1 sda2 sda3)
- ho clonato tutto, tranne /proc e /sys, da sda a sdb (sdb1 sdb2 sdb3) 
utilizzando rsync
- dalla Squeeze funzionante, monto la root del secondo disco su /mnt,
# mount /dev/sdb2 /mnt
- monto le altre due partizioni:
# mount /dev/sdb1 /mnt/boot
# mount /dev/sdb3 /mnt/home
- faccio il mount (-o bind) di /dev /proc /sys
 
eseguo: # chroot /mnt /bin/bash
 
e mi compare l'errore:
 
chroot: impossibile eseguire il comando /bin/bash: No such file or directory
 
Ovviamente bash c'ï¿œ, sia su /bin/bash che su /mnt/bin/bash, sono eseguibili, 
hanno i permessi giusti, le librerie necessarie a bash ci sono sia sul primo, 
che sul secondo disco.
 
Ho provato ad utilizzare finnix: fermo la macchina, stacco sda, faccio partire 
finnix, eseguo i mount fatti sopra, al chroot stesso errore.
 
Ho cercato in rete ed ho trovato che altri hanno avuto lo stesso problema:
- alcuni avevano problemi di "architettura" 32bit vs. 64bit
- alcuni non avevano copiato, o copiato male, le librerie necessarie a bash
- altri hanno risolto specificando parametri di mount con users,exec
- altri avevamo problemi con la variabile d'ambiente $SHELL
 
Io ho verificato tutte queste cose (cosï¿œ mi sembra), ma l'errore persiste.
 
Dove posso guardare ?
 
Grazie in anticipo
fulvio

 eseguo: # chroot /mnt /bin/bash
 
Non conosco Debian ma dovrebbe andare anche li
 
cd /mnt
mkdir -p proc etc dev var /var/cache /var/log /var/lock/ sys
 
MAKEDEV -d /mnt/dev -x console
MAKEDEV -d /mnt/dev -x null
MAKEDEV -d /mnt/dev -x zero
MAKEDEV -d /mnt/dev -x urandom
 
mount -o bind /dev /mnt/dev
mount -o bind /dev/pts /mnt/dev/pts
mount -o bind /dev/shm /mnt/dev/shm
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
 
 
 

 mount -o bind /sys /mnt/sys
 
Grazie per la risposta,
niente da fare anche con questi suggerimenti non funziona, l'errore permane.
Nota: in Debian la sintassi per MAKEDEV ï¿œ diversa, comunque /mnt/dev ï¿œ giï¿œ
popolata con tutti i device base.
Alle operazioni che avevo fatto io ho aggiunto solo queste due, da te suggerite:
 
mount -o bind /dev/pts /mnt/dev/pts
mount -o bind /dev/shm /mnt/dev/shm
 
ma non ï¿œ cambiato niente.
 

> ma non è cambiato niente.
 
un strace della disperazione ?
 
Giulia
 
 
 

 un strace della disperazione ?
 
Eccolo:
http://videosoft.biz/files/chroot.strace
 
 


wrote:

E' abbastanza strano. Secondo lui la bash non c'e':
 
chroot("/mnt")                          = 0
chdir("/")                              = 0
execve("/bin/bash", ["/bin/bash"], [/* 19 vars */]) = -1 ENOENT (No such file
or directory)
 
Leonardo
 
-- 
What would'st thou do, my squire so gay, that rides beside my reine
Were ye Glenallan's Earl this tide, and I were Roland Cheyne?
To turn the rein were sin and shame, to fight were wondrous peril:
What would ye do now, Roland Cheyne, were ye Glenallan's Earl?

 Io ho verificato tutte queste cose (cosï¿œ mi sembra), ma l'errore persiste.
 
Verificato come?
 
Hai provato "ldd /bin/bash" o "ldd /mnt/bin/bash"?
 
Se manca qualche libreria, dovrebbe informati.
 
bye,
 
-- 
 
piergiorgio

 Hai provato "ldd /bin/bash" o "ldd /mnt/bin/bash"?
 
# ldd /bin/bash
linux-vdso.so.1 =>  (0x00007fff3b4c7000)
libncurses.so.5 => /lib/libncurses.so.5 (0x00007eff56940000)
libdl.so.2 => /lib/libdl.so.2 (0x00007eff5673c000)
libc.so.6 => /lib/libc.so.6 (0x00007eff563d9000)
/lib64/ld-linux-x86-64.so.2 (0x00007eff56b8e000)
 
# ldd /mnt/bin/bash
linux-vdso.so.1 =>  (0x00007fff02b8d000)
libncurses.so.5 => /lib/libncurses.so.5 (0x00007f3e0d72f000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f3e0d52b000)
libc.so.6 => /lib/libc.so.6 (0x00007f3e0d1c8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3e0d97d000)
 
Quei numeri tra parantesi sono diversi, ï¿œ importante ?
 
 
 

 Quei numeri tra parantesi sono diversi, ï¿œ importante ?
No, indicano l'indirizzo di load della libreria. Potrebbero cambiare da 
un'esecuzione e l'altra.
 
-- 
************** (.)_(.) *******************
Un amico ï¿œ uno che sa tutto di te e,
nonostante questo, gli piaci
(E. Hobbard)
http://www.youtube.com/user/Nameci65
 
 
 

 Leonardo
 
Vero ï¿œ effettivamente strano. Prova a fare 'chroot /mnt' e di seguito 
'/bin/bash' quindi separando i due comandi e vedi cosa ti risponde.


 poi installare grub, ma non ci riesco.
<cut>
 
Io ho appena cambiato disco al portatile con debian sid. Per installare 
grub sul nuovo disco ho fatto così: avviato da un cd di installazione di 
debian squeeze 6.x , ho scelto "rescue system", ho risposto alle varie 
domande sulla localizzazione, ho scelto la mia partizione di root ed 
infine gli ho detto "apri una shell nella partizione di root /dev/sdxx". 
A quel punto ho montato /boot (il mio sistema ha solo / e /boot 
separati), ho eseguito "grub-install /dev/sda", riavviato e tutto ha 
funzionato a meraviglia.
 
Prima di usare il cd di installazione di debian ho provato con sysrescuecd 
invano: non ho indagato l'errore perchè ho risolto in 30 secondi. :)
 
Ciao


i due bash sono entrambi a 64 bit ?
fai un md5 e confrontali
 
se provi con un altro comando ad esempio ls ?
 
comunque execve in strace nasconde le ricerce delle librerie da quanto ho letto , quindi non puoi sapere realmente
a cosa si riferisce file not found.
 
 
Giulia
 

a cosa si riferisce file not found.
 
Boh, non so; a me non lo fa. Se manca una libreria, vedo una roba tipo
 
# execve ritorna 0...
execve("/bin/tcsh2", ["/bin/tcsh2"], [/* 62 vars */]) = 0
...
open("/lib64/tls/x86_64/libcruft.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
such file or directory)
# ...e la libreria fallisce.
 
Inoltre, ldd mi avverte di cosa manca e dove.
 
La cosa dei 64 bit mi pare strana ma potresti aver ragione; quello pero' non
ho i mezzi per testarlo.


 '/bin/bash' quindi separando i due comandi e vedi cosa ti risponde.
 
Ti risponde picche: se esegui chroot /mnt e basta, viene comunque chiamata una 
shell e viene chiamata /bin/sh (cosï¿œ dice il man della Debian):
 
...If no command is given, run ``${SHELL} -i'' (default: /bin/sh).
 
e l'errore mi si ripresenta tale e quale.
 

 se provi con un altro comando ad esempio ls ?
 
In che senso ? Tutta la squeeze funziona, compreso ls, o forse mi chiedi di
fare /mnt/bin/ls, certo funziona anche quello, ma anche /bin/mnt/cp ecc. ecc.
 
fulvio
 
 

 debian squeeze 6.x , ho scelto "rescue system"........
<zac>
 
Appena mi è possibile, ci provo.
fulvio
 
 
 

 chroot /mnt, ma qui mi compare l'errore.
 
Provato a fare:
 
mount -o bind /bin /mnt/bin
mount -o bind /lib /mnt/lib
 
e vedi se funziona.
 
 
 
 
 

 e vedi se funziona.
 
Provato, ma l'errore persiste.
 
 

Il 02/11/12 13.06, fulvio ha scritto:

Pu� postare /etc/fstab l'output di
blkid
lsblk
 

fulvio ha spiegato il 02/11/2012 :

E' corretto (anche sulle altre distro che ho visto), quindi escludendo 
che non siano presenti sia /bin/bash sia /bin/sh il problema deve 
risiedere nelle 5 lib che richiamano entrambi.
Verifica l'esistenza delle lib anche sotto /mnt e che siano 
correttamente indirizzate.


 lsblk
 
Per i primi due nessun problema (vedi sotto), mentre per lsblk sulla squeeze 
non c'�, e non so se c'� un equivalente.
 
# cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>    <dump>  <pass>
proc            /proc           proc    defaults        0       0
UUID=fa1ae2de-2407-464a-a020-5e29a6b01a03 / ext3 defaults,errors=remount-ro 0 1
UUID=4afc8613-ac27-4a33-bdbb-b8d1408ab9d9 /boot ext3 defaults 0 2
UUID=1d39657e-b339-4d75-bbdf-faa2cb34a3e5 none swap sw 0 0
/dev/cdrom /media/cdrom0 udf,iso9660 user,noauto 0 0
 
# blkid
/dev/sda1: LABEL="boot" UUID="4afc8613-ac27-4a33-bdbb-b8d1408ab9d9" 
SEC_TYPE="ext2" TYPE="ext3"
/dev/sda2: LABEL="root" UUID="fa1ae2de-2407-464a-a020-5e29a6b01a03" 
TYPE="ext3" SEC_TYPE="ext2"
/dev/sda3: LABEL="swap" UUID="1d39657e-b339-4d75-bbdf-faa2cb34a3e5" TYPE="swap"
/dev/sdb1: LABEL="boot" UUID="86ecf554-47b2-4e9e-8deb-96eeb7c9b691" 
SEC_TYPE="ext2" TYPE="ext3"
/dev/sdb2: LABEL="root" UUID="a926d211-5481-4f0f-a3ff-6ef99ca014b6" 
SEC_TYPE="ext2" TYPE="ext3"
/dev/sdb3: LABEL="swap" UUID="05750056-3e5e-4b5a-89a2-a4e8acf14fab" TYPE="swap"
 
 
 

 TYPE="swap"
 
Ok, ha modificato /mnt/etc/fstab inserendo i corretti UUID dei 
rispettivi /dev/sdb.. ?
 
Il dubbio è che il processo di chroot (per qualche future implementata 
recentemente) vada a leggere il suddetto file e si crei un conflitto 
quando cerca di montare la / e conseguentemente /etc e tutto il resto.
 
Non sono del tutto certo che chroot legga fstab ma dato che ha già 
provato a montare in bind /bin e /lib per esclusione non può essere un 
problema di binari ne di librerie
 
 
 
 
 

 /lib64/ld-linux-x86-64.so.2 (0x00007f3e0d97d000)
 
  Tra i bind che ho letto non ho visto questo:
 
mount -o bind /lib64 /mnt/lib64
 
  Vedi un po' se ï¿œ quello che manca.
 
 
  Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

Un doveroso grazie a tutti i contributi ricevuti.
Il problema era a monte: per qualche motivo, a me sconosciuto, su quella
macchina c'erano nientemeno che le libc6 "non allineate"; apt-get update e il
seguente apt-get upgrade dicevano: "zero pacchetti da aggiornare"; ma,
evidentemente, qualcosa in passato è andato storto.
Facendo delle verifiche (md5sum) tra tutte le librerie presenti in /usr/lib di
questa macchina, ed altre 5 squeeze 64, che ho in giro, ho riscontrato
differenze nei valori (gli md5 delle lib delle altre 5 macchine erano tutti
coincidenti).
Eseguendo un apt-get install --reinstall libc6, il tanto agognato chroot è
andato a posto al primo colpo, senza il bisogno di strani bind o montature
particolari.
Nonostante il disallineamento, i servizi che girano su questa macchina,
postfix, dovecot, openldap, fetchmail funzionano no-stop e perfettamente da 2
anni e mezzo, e allo stesso modo i più comuni comandi utilizzati nella shell,
c'è voluto il chroot per generare l'errore, e la ricerca del difetto.
 
Ancora grazie a tutti
fulvio

 fulvio
 
Grazie a te dell'aggiornamento. Ultimamente mi pare che in pochi lo 
facciano ed io lo ritengo importante come feedback per crescere.
 
-- 
************** (.)_(.) *******************
Un amico è uno che sa tutto di te e,
