Migration 32 bits vers 64 bits gros problème avec dpkg testing
3 réponses
MERLIN Philippe
Bonjour,
Sur ce poste est install=E9 la Debian testing =E0 jour et j'ai essay=E9 de =
migrer =20
d'une version 32 bits vers 64 bits en suivant la doc
https://wiki.debian.org/CrossGrading
Tout a tr=E8s bien march=E9, j'ai bien migr=E9 vers une version 64 bits de =
la=20
testing qui fonctionne tr=E8s bien avec un noyau AMD 64 et des librairies =
32=20
bits Merci Multi-Arch , mais il y a un mais.... Si je veux migrer tous les=
=20
paquets install=E9s de 32 bits =E0 64 bits par la commande :
dpkg --get-selections|grep :i386 |sed -e s/:i386/:amd64/ | dpkg --set-
selections
J'obtiens une liste de warning :
package not in status nor available database a line xxx : xxxx:amd64
une ligne par paquet r=E9pondant =E0 dpkg --get-selections
On dirait que les paquets amd64 sont ignor=E9s.
dpkg --print-architecture me donne bien
amd64
si je fait un apt-cache policy xxxx (xpack =E9tant un paquet i386)
le paquet est dit non install=E9 et le candidat est un paquet amd64
si je fait un apt-get download xpack c'est bien un paquet amd64 qui arrive.
J'ai fait des apt-get update
j'ai essay=E9 beaucoup de commande :
sync-available=20
qui donne "l'information sur 90355 paquets a =E9t=E9 mis =E0 jour"
toujours sans succ=E8s
un apt-get -f install se casse la figure avec des tas d'insultes
donc r=E9sumons cela marche gr=E2ce =E0 multi-arch mais je ne peux plus fai=
re de mis=20
=E0 jour.
Avez vous rencontrer ce probl=E8me, ou pourrais je m'adresser pour avoir de=
=20
l'aide ?
Philippe Merlin
P.S. les commentaires du genre c'est ta faute tu l'as bien cherch=E9 ne so=
nt=20
pas la bienvenue
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
=c3
Bonjour Philippe, Philippe Merlin, le 2017-05-04 à 14:53:16 CEST :
Sur ce poste est installé la Debian testing à jour et j'ai essayé de migrer d'une version 32 bits vers 64 bits en suivant la doc https://wiki.debian.org/CrossGrading
Intéressante manipulation, j'ai essayé dans une machine virtuelle. Le moins qu'on puisse dire, c'est que c'est délicat. Ma configuration était une machine en Testing avec uniquement les composants de base, donc je suis probablement passé à côté des problèmes de configuration. Avant toute chose, j'espère que tu as une copie de sauvegarde des donnée de ta machine et de sa configuration et que tu sais comment la restaurer. Les liens en bas de la page du wiki CrossGrading renvoient sur d'autres retours d'expérience. Il ne faut pas hésiter à les consulter également pour voir leurs approches. En particulier, j'ai trouvé de l'inspiration dans l'article suivant : http://blog.zugschlus.de/archives/972-How-to-amd64-an-i386-Debian-installation-with-multiarch.html Ce n'est pas mentionné dans ton courriel, mais je pars du principe que tu as pu installer tes commandes tar, dpkg et apt en version 64bits : $ file $(which tar) /bin/tar: ELF 64-bit LSB shared object, ... $ file $(which dpkg) /usr/bin/dpkg: ELF 64-bit LSB shared object, ... $ file $(which apt-get) /usr/bin/apt-get: ELF 64-bit LSB shared object, ... Si ce n'est pas le cas et que quelque chose a cassé, les manipulations à base de `ar' et de `busybox tar' mentionnée dans les retours d'expérience peuvent éventuellement te sauver la mise.
Tout a très bien marché, j'ai bien migré vers une version 64 bits de la testing qui fonctionne très bien avec un noyau AMD 64 et des librairies 32 bits Merci Multi-Arch , mais il y a un mais.... Si je veux migrer tous les paquets installés de 32 bits à 64 bits par la commande : dpkg --get-selections|grep :i386 |sed -e s/:i386/:amd64/ | dpkg --set-selections J'obtiens une liste de warning : package not in status nor available database a line xxx : xxxx:amd64 une ligne par paquet répondant à dpkg --get-selections On dirait que les paquets amd64 sont ignorés.
Les paquets amd64 sont effectivement ignorés. L'erreur se produit dans mon cas d'utilisation aussi. Un gourou de dpkg aura sans doute la solution pour résoudre ce problème proprement. Pour ma part, je suis passé par un fichier temporaire `packages` pour pouvoir travailler dedans avec un éditeur de texte : dpkg --get-selections | grep :i386 | sed -e s/:i386/:amd64/ | awk '{print $1}'
packages
Le fichier `packages` contient une liste des paquets, un par ligne, sans le champ d'état d'installation. Je le réutilise pour une première tentative d'installation des paquets en 64bits : apt-get install $(xargs < packages) À la première passe, `apt` sort des erreurs sur des paquets introuvable. Il faut les retirer de la liste. Typiquement les images linux 686 sont en cause, mais éventuellement certaines versions de paquets devenus obsolètes, si des mises à jour sont passées pendant la crossgrade. C'est souvent le cas des paquets qui ont leur numéro de version dans leur nom, pour faciliter l'installation de versions différentes sur un même système. En relançant la commande sans les erreurs sur les paquets indisponibles, l'installation démarre. Étant donné les composants de cœur en 32bits qui nécessiteront un désinstallation, il est vraisemblable qu'apt demande de confirmer l'opération par la saisie au clavier d'une locution: "Yes, do as I say!" sur une machine localisée en en_US. La désinstallation de perl-base:i386 dans mon cas a été la cause du message. Si l'opération plante, passer un coup `apt-get -f install` avant de recommencer avec la liste complète des paquets. Il est probable que certain services récalcitrants bloquent le gestionnaire de paquet. Dans ce cas j'ai eu la chance de pouvoir désinstaller manuellement le composant, puis le réinstaller après coup dans sa nouvelle architecture. En l'occurrence, il s'agissait du passage de acpid:i386 à acpid:amd64. Quand une tentative d'installation de l'ensemble des paquets termine en disant que tout est bien installé et qu'aucune opération n'est à effectuer, alors la partie 64bits du système est normalement complète. Les paquets en 32bits peuvent être enlevés : dpkg --get-selections | grep :i386 | awk '{print $1}'
packages.i386
apt-get remove $(xargs < packages.i386) À ce stade, le système ne doit plus comporter de binaire 32bits sur disque et être capable de tourner juste avec les paquets amd64. Reste à redémarrer la machine pour arrêter les processus 32bits encore en cours d'exécution, tel l'init. Si la machine est capable de redémarrer correctement avec ses services opérationnels après ce traitement, alors la bouteille réservée aux jours de fêtes sera amplement méritée. :-) À plus, -- Étienne Mollier
Bonjour Philippe,
Philippe Merlin, le 2017-05-04 à 14:53:16 CEST :
Sur ce poste est installé la Debian testing à jour et j'ai
essayé de migrer d'une version 32 bits vers 64 bits en suivant
la doc
https://wiki.debian.org/CrossGrading
Intéressante manipulation, j'ai essayé dans une machine
virtuelle. Le moins qu'on puisse dire, c'est que c'est délicat.
Ma configuration était une machine en Testing avec uniquement les
composants de base, donc je suis probablement passé à côté des
problèmes de configuration.
Avant toute chose, j'espère que tu as une copie de sauvegarde des
donnée de ta machine et de sa configuration et que tu sais
comment la restaurer.
Les liens en bas de la page du wiki CrossGrading renvoient sur
d'autres retours d'expérience. Il ne faut pas hésiter à les
consulter également pour voir leurs approches. En particulier,
j'ai trouvé de l'inspiration dans l'article suivant :
Si ce n'est pas le cas et que quelque chose a cassé, les
manipulations à base de `ar' et de `busybox tar' mentionnée dans
les retours d'expérience peuvent éventuellement te sauver la
mise.
Tout a très bien marché, j'ai bien migré vers une version 64
bits de la testing qui fonctionne très bien avec un noyau AMD
64 et des librairies 32 bits Merci Multi-Arch , mais il y a un
mais.... Si je veux migrer tous les paquets installés de 32
bits à 64 bits par la commande :
package not in status nor available database a line xxx : xxxx:amd64
une ligne par paquet répondant à dpkg --get-selections
On dirait que les paquets amd64 sont ignorés.
Les paquets amd64 sont effectivement ignorés. L'erreur se
produit dans mon cas d'utilisation aussi. Un gourou de dpkg aura
sans doute la solution pour résoudre ce problème proprement.
Pour ma part, je suis passé par un fichier temporaire `packages`
pour pouvoir travailler dedans avec un éditeur de texte :
Le fichier `packages` contient une liste des paquets, un par
ligne, sans le champ d'état d'installation. Je le réutilise pour
une première tentative d'installation des paquets en 64bits :
apt-get install $(xargs < packages)
À la première passe, `apt` sort des erreurs sur des paquets
introuvable. Il faut les retirer de la liste. Typiquement les
images linux 686 sont en cause, mais éventuellement certaines
versions de paquets devenus obsolètes, si des mises à jour sont
passées pendant la crossgrade. C'est souvent le cas des paquets
qui ont leur numéro de version dans leur nom, pour faciliter
l'installation de versions différentes sur un même système.
En relançant la commande sans les erreurs sur les paquets
indisponibles, l'installation démarre. Étant donné les
composants de cœur en 32bits qui nécessiteront un
désinstallation, il est vraisemblable qu'apt demande de confirmer
l'opération par la saisie au clavier d'une locution: "Yes, do as
I say!" sur une machine localisée en en_US. La désinstallation
de perl-base:i386 dans mon cas a été la cause du message. Si
l'opération plante, passer un coup `apt-get -f install` avant de
recommencer avec la liste complète des paquets.
Il est probable que certain services récalcitrants bloquent le
gestionnaire de paquet. Dans ce cas j'ai eu la chance de pouvoir
désinstaller manuellement le composant, puis le réinstaller après
coup dans sa nouvelle architecture. En l'occurrence, il
s'agissait du passage de acpid:i386 à acpid:amd64.
Quand une tentative d'installation de l'ensemble des paquets
termine en disant que tout est bien installé et qu'aucune
opération n'est à effectuer, alors la partie 64bits du système
est normalement complète. Les paquets en 32bits peuvent être
enlevés :
À ce stade, le système ne doit plus comporter de binaire 32bits
sur disque et être capable de tourner juste avec les paquets
amd64. Reste à redémarrer la machine pour arrêter les processus
32bits encore en cours d'exécution, tel l'init.
Si la machine est capable de redémarrer correctement avec ses
services opérationnels après ce traitement, alors la bouteille
réservée aux jours de fêtes sera amplement méritée. :-)
À plus,
--
Étienne Mollier <etienne.mollier@mailoo.org>
Bonjour Philippe, Philippe Merlin, le 2017-05-04 à 14:53:16 CEST :
Sur ce poste est installé la Debian testing à jour et j'ai essayé de migrer d'une version 32 bits vers 64 bits en suivant la doc https://wiki.debian.org/CrossGrading
Intéressante manipulation, j'ai essayé dans une machine virtuelle. Le moins qu'on puisse dire, c'est que c'est délicat. Ma configuration était une machine en Testing avec uniquement les composants de base, donc je suis probablement passé à côté des problèmes de configuration. Avant toute chose, j'espère que tu as une copie de sauvegarde des donnée de ta machine et de sa configuration et que tu sais comment la restaurer. Les liens en bas de la page du wiki CrossGrading renvoient sur d'autres retours d'expérience. Il ne faut pas hésiter à les consulter également pour voir leurs approches. En particulier, j'ai trouvé de l'inspiration dans l'article suivant : http://blog.zugschlus.de/archives/972-How-to-amd64-an-i386-Debian-installation-with-multiarch.html Ce n'est pas mentionné dans ton courriel, mais je pars du principe que tu as pu installer tes commandes tar, dpkg et apt en version 64bits : $ file $(which tar) /bin/tar: ELF 64-bit LSB shared object, ... $ file $(which dpkg) /usr/bin/dpkg: ELF 64-bit LSB shared object, ... $ file $(which apt-get) /usr/bin/apt-get: ELF 64-bit LSB shared object, ... Si ce n'est pas le cas et que quelque chose a cassé, les manipulations à base de `ar' et de `busybox tar' mentionnée dans les retours d'expérience peuvent éventuellement te sauver la mise.
Tout a très bien marché, j'ai bien migré vers une version 64 bits de la testing qui fonctionne très bien avec un noyau AMD 64 et des librairies 32 bits Merci Multi-Arch , mais il y a un mais.... Si je veux migrer tous les paquets installés de 32 bits à 64 bits par la commande : dpkg --get-selections|grep :i386 |sed -e s/:i386/:amd64/ | dpkg --set-selections J'obtiens une liste de warning : package not in status nor available database a line xxx : xxxx:amd64 une ligne par paquet répondant à dpkg --get-selections On dirait que les paquets amd64 sont ignorés.
Les paquets amd64 sont effectivement ignorés. L'erreur se produit dans mon cas d'utilisation aussi. Un gourou de dpkg aura sans doute la solution pour résoudre ce problème proprement. Pour ma part, je suis passé par un fichier temporaire `packages` pour pouvoir travailler dedans avec un éditeur de texte : dpkg --get-selections | grep :i386 | sed -e s/:i386/:amd64/ | awk '{print $1}'
packages
Le fichier `packages` contient une liste des paquets, un par ligne, sans le champ d'état d'installation. Je le réutilise pour une première tentative d'installation des paquets en 64bits : apt-get install $(xargs < packages) À la première passe, `apt` sort des erreurs sur des paquets introuvable. Il faut les retirer de la liste. Typiquement les images linux 686 sont en cause, mais éventuellement certaines versions de paquets devenus obsolètes, si des mises à jour sont passées pendant la crossgrade. C'est souvent le cas des paquets qui ont leur numéro de version dans leur nom, pour faciliter l'installation de versions différentes sur un même système. En relançant la commande sans les erreurs sur les paquets indisponibles, l'installation démarre. Étant donné les composants de cœur en 32bits qui nécessiteront un désinstallation, il est vraisemblable qu'apt demande de confirmer l'opération par la saisie au clavier d'une locution: "Yes, do as I say!" sur une machine localisée en en_US. La désinstallation de perl-base:i386 dans mon cas a été la cause du message. Si l'opération plante, passer un coup `apt-get -f install` avant de recommencer avec la liste complète des paquets. Il est probable que certain services récalcitrants bloquent le gestionnaire de paquet. Dans ce cas j'ai eu la chance de pouvoir désinstaller manuellement le composant, puis le réinstaller après coup dans sa nouvelle architecture. En l'occurrence, il s'agissait du passage de acpid:i386 à acpid:amd64. Quand une tentative d'installation de l'ensemble des paquets termine en disant que tout est bien installé et qu'aucune opération n'est à effectuer, alors la partie 64bits du système est normalement complète. Les paquets en 32bits peuvent être enlevés : dpkg --get-selections | grep :i386 | awk '{print $1}'
packages.i386
apt-get remove $(xargs < packages.i386) À ce stade, le système ne doit plus comporter de binaire 32bits sur disque et être capable de tourner juste avec les paquets amd64. Reste à redémarrer la machine pour arrêter les processus 32bits encore en cours d'exécution, tel l'init. Si la machine est capable de redémarrer correctement avec ses services opérationnels après ce traitement, alors la bouteille réservée aux jours de fêtes sera amplement méritée. :-) À plus, -- Étienne Mollier
Daniel Caillibaud
Le 05/05/17 à 20:05, Étienne Mollier a écrit :
Intéressante manipulation, j'ai essayé dans une machine virtuelle. Le moins qu'on puisse dire, c'est que c'est délicat.
Et intéressante contribution ! Je me suis demandé pourquoi xargs sur
apt-get install $(xargs < packages)
car en bash le $(< fichierQcq) transforme les n en espaces, et je l'utilis e depuis des années sans me poser de question, mais effectivement avec dash (par ex ) $(<fichier) ne sort rien (même pas la 1re ligne) et xargs est alors nécessaire. -- Daniel Il faut toujours viser la lune car en cas d'échec on atterrit dans les étoiles... Oscar Wilde
Le 05/05/17 à 20:05, Étienne Mollier <etienne.mollier@mailoo.org> a écrit :
Intéressante manipulation, j'ai essayé dans une machine
virtuelle. Le moins qu'on puisse dire, c'est que c'est délicat.
Et intéressante contribution !
Je me suis demandé pourquoi xargs sur
apt-get install $(xargs < packages)
car en bash le $(< fichierQcq) transforme les n en espaces, et je l'utilis e depuis des
années sans me poser de question, mais effectivement avec dash (par ex ) $(<fichier) ne sort rien
(même pas la 1re ligne) et xargs est alors nécessaire.
--
Daniel
Il faut toujours viser la lune car en cas d'échec on atterrit dans les
étoiles...
Oscar Wilde
Intéressante manipulation, j'ai essayé dans une machine virtuelle. Le moins qu'on puisse dire, c'est que c'est délicat.
Et intéressante contribution ! Je me suis demandé pourquoi xargs sur
apt-get install $(xargs < packages)
car en bash le $(< fichierQcq) transforme les n en espaces, et je l'utilis e depuis des années sans me poser de question, mais effectivement avec dash (par ex ) $(<fichier) ne sort rien (même pas la 1re ligne) et xargs est alors nécessaire. -- Daniel Il faut toujours viser la lune car en cas d'échec on atterrit dans les étoiles... Oscar Wilde
=c3
On 05/09/2017 07:27 PM, Daniel Caillibaud wrote:
Je me suis demandé pourquoi xargs sur
apt-get install $(xargs < packages)
car en bash le $(< fichierQcq) transforme les n en espaces, et je l'utilise depuis des années sans me poser de question, mais effectivement avec dash (par ex) $(<fichier) ne sort rien (même pas la 1re ligne) et xargs est alors nécessaire.
Bonjour Daniel, J'aurais aimé dire que c'était voulu, mais à la base, c'était une simple méconnaissance de cette construction de ma part. Merci beaucoup, j'ai appris un truc, très utile qui plus est. :D Effectivement, dépendant des situations, les constructions ne sont pas toujours possibles. Par exemple, si on a cassé la lib C et qu'on ne peut se ratrapper qu'avec un shell `busybox ash', alors la construction utilisable dans ce cas est celle en `xargs'. Et encore, parce que `xargs' est un builtin de busybox. Sinon dans ce cas précis, en `dash', aucune des constructions n'aurait fonctionné. Enfin, en `bash' seule la construction en `$(<file)' aurait fonctionné. À plus, -- Étienne Mollier
On 05/09/2017 07:27 PM, Daniel Caillibaud wrote:
Je me suis demandé pourquoi xargs sur
apt-get install $(xargs < packages)
car en bash le $(< fichierQcq) transforme les n en espaces, et
je l'utilise depuis des années sans me poser de question, mais
effectivement avec dash (par ex) $(<fichier) ne sort rien (même
pas la 1re ligne) et xargs est alors nécessaire.
Bonjour Daniel,
J'aurais aimé dire que c'était voulu, mais à la base, c'était une
simple méconnaissance de cette construction de ma part. Merci
beaucoup, j'ai appris un truc, très utile qui plus est. :D
Effectivement, dépendant des situations, les constructions ne
sont pas toujours possibles. Par exemple, si on a cassé la lib C
et qu'on ne peut se ratrapper qu'avec un shell `busybox ash',
alors la construction utilisable dans ce cas est celle en
`xargs'. Et encore, parce que `xargs' est un builtin de busybox.
Sinon dans ce cas précis, en `dash', aucune des constructions
n'aurait fonctionné. Enfin, en `bash' seule la construction en
`$(<file)' aurait fonctionné.
À plus,
--
Étienne Mollier <etienne.mollier@mailoo.org>
car en bash le $(< fichierQcq) transforme les n en espaces, et je l'utilise depuis des années sans me poser de question, mais effectivement avec dash (par ex) $(<fichier) ne sort rien (même pas la 1re ligne) et xargs est alors nécessaire.
Bonjour Daniel, J'aurais aimé dire que c'était voulu, mais à la base, c'était une simple méconnaissance de cette construction de ma part. Merci beaucoup, j'ai appris un truc, très utile qui plus est. :D Effectivement, dépendant des situations, les constructions ne sont pas toujours possibles. Par exemple, si on a cassé la lib C et qu'on ne peut se ratrapper qu'avec un shell `busybox ash', alors la construction utilisable dans ce cas est celle en `xargs'. Et encore, parce que `xargs' est un builtin de busybox. Sinon dans ce cas précis, en `dash', aucune des constructions n'aurait fonctionné. Enfin, en `bash' seule la construction en `$(<file)' aurait fonctionné. À plus, -- Étienne Mollier
