Salut,
Je suis sous sid en 32 bits, si je veux passer en 64, suis-je bon pour tous réinstaller? Ou suffit-t’il de mettre à jour l’/etc/apt/sources.list et un ptit dist-upgrade.
Merci, pour l’info.
Tu dois tout réinstaller.
Une bonne solution consiste avec un debootstrap qui te permet de tester si tout va bien puis quand tu as fini, tu changes de partition racine et conserves une partition du secours toujours utile.
Moi aussi j’ai répèté ça à tour de bras parceque je l’ai lu partout, mais il y a un truc que je me demandais:
la distrib 32 est pourvue d’un noyau 64 qui sert justement à accèder au chroot 64.
Une fois booté sur ce noyau 64 avec les executables 32 (qui tournent à peu prés sur le noyau 64), qu’est ce qui bloque si on fait une reinstall complète de tous les paquets avec un sources.list 64 ?
Je n’ai jamais testé, mais je ne vois pas “à priori” ce qui pourrait bloquer. J’imagine bien des plantages lors de l’install quand il y a besoin d’accèder au noyau, mais forcément lors de la config puisque le déploiment des exes 64 n’a pas de raison de planter, donc quelquechose qui a toutes les chances de se corriger avec un bête reboot suivi d’un apt-get -f install.
fran.b: non ?
.
bloodaxe70, si tu penses réinstaller tout en 64 sans laisser de trace de la 32, tu pourrais essayer ça ?
Ben j’avais la même idée que toi, c’est pour ca que j’ai poser cette question. Et j’ai bien envi d’essayer ca quand j’aurai un peu de temps.
Recompiler le noyaux avec support du 64 bits, reboot, puis modifier le sources.list et un dist-upgrade.
[quote=“mattotop”]Moi aussi j’ai répèté ça à tour de bras parceque je l’ai lu partout, mais il y a un truc que je me demandais:
la distrib 32 est pourvue d’un noyau 64 qui sert justement à accèder au chroot 64.
[/quote]exact
[quote]
Une fois booté sur ce noyau 64 avec les executables 32 (qui tournent à peu prés sur le noyau 64), qu’est ce qui bloque si on fait une reinstall complète de tous les paquets avec un sources.list 64 ?
Je n’ai jamais testé, mais je ne vois pas “à priori” ce qui pourrait bloquer. J’imagine bien des plantages lors de l’install quand il y a besoin d’accèder au noyau, mais forcément lors de la config puisque le déploiment des exes 64 n’a pas de raison de planter, donc quelque chose qui a toutes les chances de se corriger avec un bête reboot suivi d’un apt-get -f install.
[/quote]Voyons, si on installe les fondamentaux (tar, dpkg, libc6,…) cela veut dire que la libc6 /lib/libc.so sera remplacé par la 64bits et donc toutes les applications 32 bits sont privées de libc6 donc vont dans le mur. Il faut donc soigner les premiers paquets installés. En fait je verrais bien la chose suivante:
En mode console avec quasi tout arrêté.
- un dpkg -i des paquets fondamentaux par exemple ceux qui sont sur le CD de la net-install 64 bits.
- un apt-get install --reinstall de tous les paquets autres
Effectivement, là je ne vois pas pourquoi ça ne se passerait pas bien. J’essayerai bien tiens si j’avais un 64 bits sous la main…
Ben moi j’ai des machines 64, mais plus d’install 32 dessus.
Par contre, ce que je réalise, c’est qu’on a pas à changer le sources.list: c’est le même…
C’est surtout qu’il faudrait trouver dans quel paquet se trouve la définition de l’arch, pour dpkg et apt, pour installer ce paquet là en premier en --force-arch.
C’est pour ça que je suggère d’installer les paquets de la net install… mais c’est vrai que je ne sais pas ou est marqué l’architecture. Pour moi, c’est une fonction de la libc mais c’est intuitif.
quote="Fran.B"
je ne sais pas ou est marqué l’architecture. Pour moi, c’est une fonction de la libc mais c’est intuitif.[/quote]
J’essaierai de retrouver ça ce soir…Il me semble avoir lu où c’était dans “100% Debian”.Faut juste que je remette la main dessus il est dans au fond d’un carton…
Ce que je ne comprend pas c’est qu’un processeur 64bits “comprend” les instructions 32bits (on peut installer une i386 sans problèmes), donc pourquoi ne pourrait-il pas executer les binaires 32bits?
Peut etre à cause de la libc 
Dans ce cas il existe un paquet libia32 (pas sur du nom), il ne serait pas possible de faire un lien symbolique pour indiquer au programmes en 32bits d’utiliser cette lib?(via dpkg-divert??? 
Là je suis vraiment pas sur de ce que je dis)
Trouvé!
Il suffit d’éditer apt.conf.d
man apt.conf et zcat /usr/share/doc/apt/examples/configure-index.gz pour plus de renseignements 
Négatif, je n’ai pas ce champ sur mes machines. Donc ce n’est pas ça qui différencie une mad64 d’une i386:
NC-13D3923EBA:/etc/apt# grep -r amd64 * | grep -v sources.list
(sur un chroot i386)
NC-13D3923EBA:/etc/apt# cd /srv/etc/apt/
NC-13D3923EBA:/srv/etc/apt# grep -r amd64 * | grep -v sources.list
NC-13D3923EBA:/srv/etc/apt# grep -r i386 * | grep -v sources.list
NC-13D3923EBA:/srv/etc/apt# grep -r 386 * | grep -v sources.list
NC-13D3923EBA:/srv/etc/apt#
Mieux, retour à la racine amd64
[code]NC-13D3923EBA:/etc# grep -r amd64 * | grep -v sources.list
grep: alternatives/netscape-javaplugin.so: Aucun fichier ou répertoire de ce type
Fichier binaire alternatives/mozilla-javaplugin.so concorde
Fichier binaire alternatives/firefox-javaplugin.so concorde
grep: alternatives/javaws: Aucun fichier ou répertoire de ce type
motd:Linux NC-13D3923EBA 2.6.12-1-amd64-generic #1 Fri Jul 22 18:12:08 CEST 2005 x86_64 GNU/Linux
grep: xdg/menus/debian-menu.menu: Aucun fichier ou répertoire de ce type
NC-13D3923EBA:/etc# grep -r AMD64 *
grep: alternatives/netscape-javaplugin.so: Aucun fichier ou répertoire de ce type
grep: alternatives/javaws: Aucun fichier ou répertoire de ce type
grep: xdg/menus/debian-menu.menu: Aucun fichier ou répertoire de ce type
NC-13D3923EBA:/etc#
(passage à la racine I386)
NC-13D3923EBA:/etc# cd /srv/etc
NC-13D3923EBA:/srv/etc# grep -r 386 *
grep: alternatives/ipfwadm: Aucun fichier ou répertoire de ce type
grep: alternatives/ipfwadm.8.gz: Aucun fichier ou répertoire de ce type
grep: alternatives/ipfw.4.gz: Aucun fichier ou répertoire de ce type
grep: network/run: Aucun fichier ou répertoire de ce type
X11/xkb/geometry/sgi/indigo: indicator “NumLock” { left= 386; };
X11/xkb/geometry/sgi/indy: indicator “NumLock” { left= 386; };
NC-13D3923EBA:/srv/etc#
[/code]
Je pense réellement qu’il n’y a pas d’indications en clair dans /etc de l’architecture.
quote="bloodaxe70"
Recompiler le noyaux avec support du 64 bits, reboot, puis modifier le sources.list[/quote]Pas besoin, le sources.list à utiliser est le même: tu modifies juste le apt.conf.d pour y mettre le changement d’arch, comme dit yoshi, tu fais un update puis tu installes un des noyaux binaires dispos dans apt. Ensuite, tu rebootes dessus. Tu peux même aprés supprimer tes noyaux 32 parcequ’une fois installés les exes 64, ta machine ne bootera plus avec les noyaux 32. [quote=“bloodaxe70”]et un dist-upgrade.[/quote]Ca ne suffit pas, il faut forcer une reinstall de tous les paquets, genre:dpkg --get-selections | grep install | grep -v linux-source | awk '{print $1}' | sudo aptitude reinstallS’il râle parcequ’il ne trouve plus un paquet qui n’est plus disponible dans les dépots, tu le purges, et tu relances la commande.
Je viens de faire l’opération sur une machine sur laquelle j’ai eu un petit crash disque récemment et ça passe nickel.
fran.b, yoshi n’a pas parlé de sources.list, on sait que le sources.list ne contient pas de réfèrence à l’arch.
Et il a raison: même si la réfèrence explicite à l’arch n’apparait pas normalement dans apt.conf, l’executable apt, lui, sait quelle architecture choisir en fonction de pour quoi il a été compilé. Rajouter la directive apt fait bien ce qu’on cherche: le forcer à prendre les paquets amd64.
Et je réalise que si cette manip fonctionne, pas de raison qu’elle ne fonctionne pas à peu prés pareil (sauf qu’il ne faurait pas tt de suite rebooter sur le noyau 32 qui ne bootera pas avec les exe 64) dans l’autre sens (au cas ou on ait besoin de remonter le disque sur une machine 32).
C’est bien pour ça que j’ai fait un grep -v sources.list (pour ne pas lister les lignes de sources.list contenant amd64).
J’ai juste montré qu’il n’y avait aucune références à AMD64 comme à amd64 dans les fichiers de /etc. Quand on fait un ./configure, l’architecture est trouvé en faisant appel à une fonction de la libc. Je pense que la libc détermine l’architecture. La libc elle même doit faire appel au noyau. Donc à mon avis, il faut au minimum installer libc+noyau et faire un reinstall des paquets comme tu le suggère. Cependant j’ai peur que dpkg ne fonctionne pas. C’est pour ça que je suggère un dpkg -i des paquets basiques puis un apt-get install --reinstall (ce que tu dis quoi 
)
j’avais pas fait attention au -v
juste pour dire qu’il existe /usr/bin/linux32 et /usr/bin/linux64 qui sont des liens symboliques vers /usr/bin/setarch, par contre je sais pas ou ils sont executer…
Il me semble que setarch est juste un leurre pour par exemple faire de la cross compilation (compilation pour dur 64bits sur du 32 bits par exemple). Mais je peux me tromper. C’est un outil nouveau sous Sid qui n’existe pas sinon sous etch je crois bien
J’ai tenter ta méthode mattotop sans succès, il ne voulais pas m’installer le noyaux et d’autres packages, il me sortait une erreur comme quoi l’architecture amd64 ne correspondant pas à i386. 
Essaye en chargeant une netinstall carte de crédit et en installant les paquets de base AMD64