Avec cette achitecture, impossible installer paquet en 64 bits ?

Tu prends le sujet dans le mauvais sens. Un paquet doit être explicitement construit pour pouvoir être installé simultanément en plusieurs architectures. Il a un champ “Multi-Arch” qui permet de le reconnaître. Par défaut, et notamment pour les anciens paquets, ce n’est pas le cas.

Exemple du contenu du paquet libuuid prévu pour le multi-arch :

paquet amd64

/lib/x86_64-linux-gnu/libuuid.so.1
/lib/x86_64-linux-gnu/libuuid.so.1.3.0
/usr/share/doc/libuuid1/changelog.Debian.gz
/usr/share/doc/libuuid1/changelog.gz
/usr/share/doc/libuuid1/copyright

paquet i386

/lib/i386-linux-gnu/libuuid.so.1
/lib/i386-linux-gnu/libuuid.so.1.3.0
/usr/share/doc/libuuid1/changelog.Debian.gz
/usr/share/doc/libuuid1/changelog.gz
/usr/share/doc/libuuid1/copyright

Les fichiers binaires exécutables ont des chemins différents selon leur architecture. Les autres fichiers doivent être identiques entre les architectures et peuvent alors être fusionnés.

Exemple du contenu du paquet libvlc5 non prévu pour le multi-arch :

/usr/lib/libvlc.so.5
/usr/lib/libvlc.so.5.5.0
/usr/share/bug/libvlc5
/usr/share/doc/libvlc5

Les chemins des fichiers binaires exécutables sont identiques pour toutes les architectures, empêchant l’installation simultanée des paquets i386 et amd64.

Je crois que je vais laisser tomber cette possibilité de réparation qui sera toujours bancale.
Je vais faire comme expliqué plus haut (msg 69)
Des 3 possibilités que j’y envisage, laquelle vous semble la plus pertinente ?

Je ne saurai trop te conseiller dans le sens où tu connais le mieux ta machine et ce que tu veux en faire.

Néanmoins si tu pars finalement sur la solution de tout réinstaller pas à pas en amd64, ce que je peux te conseiller alors c’est de laisser tourner ton serveur tel quel pour l’instant pour ne pas avoir d’interruption de service, et de connecter ce fameux DD externe dont tu parles en USB soit à ce serveur soit à la machine depuis laquelle tu écris (si ce n’est pas la même et seule machine), et de faire une installation toute neuve de Debian à l’aide d’un iso sur clé usb.

Ensuite pour éviter de reprendre toutes tes configs depuis le début, il te suffira d’en faire un transfert de fichiers depuis le DD actuellement en service vers celui où tu auras fait ta nouvelle installation.

Et une fois tout celà fait, il te suffira de débrocher l’ancien DD du serveur et mettre celui-là à la place… Profites en étant donné que tu fais une nouvelle installation, pour revoir si besoin est ton schéma de partitionnement, système de fichiers (ext4, btrfs,…), chiffrement ou pas…

C’était ce que j’envisageais de faire en prenant mon temps.
Une question toutefois :
L’idéal serait de ne pas toucher à mon serveur et d’installer cette nouvelle Jessie sur un DD en boitier externe.
Je dispose de deux machines fonctionnelles en plus de celle qui sert de serveur. Mon ordibureau, auquel je préfère ne pas toucher et une seconde que j’appellerai “test”.
J’aimerais bien installer ce DD externe sur cette “test” mais elle n’a pas du tout les mêmes composants et c’est une amd64 au niveau du processeur.
Est-ce que ce DD une fois installé et configuré sur cette “test” acceptera d’être transféré sur une machine différente ?
Bien sûr l’architecture sera cette fois en amd64 nativement, mais ???
Si vous me répondez que c’est possible, je commence demain.

Pas de problème pour cette machine “test” au niveau de l’architecture puisqu’on a vu au tout début que le processeur du serveur supporte l’architecture 64-bit et c’est justement ce que l’on cherche à faire au niveau de l’installation de Debian Jessie.

En revanche, et là j’attendrai confirmation quand même de Pascal ou quelqu’un d’autre, c’est au niveau des périphériques qu’il faudra faire attention. Il est fort probable que les périphériques ne soient pas les même entre le serveur et la machine “test”.
Mais ça non plus ce n’est pas très grave dans le sens où pendant l’installation, il y a une étape ou l’installateur te propose d’installer le noyau, et te demande également s’il doit faire une installation générique où bien spécifique au matériel auquel est connecté ton DD. Tu dois évidemment sélectionner générique et en principe comme ça tu pourras transférer ton DD sur n’importe quelle machine après.

Néanmoins je préfère attendre confirmation de mes propos pour ne pas t’envoyer dans le mur en ayant peut être dit une bêtise… :wink:

EDIT : bien sûr quand on parle de transfert ultérieur du DD sur une autre machine, il est sous-entendu que cette machine soit d’architecture “amd64”.

[quote=“GOGI, post:85, topic:69587”]
EDIT : bien sûr quand on parle de transfert ultérieur du DD sur une autre machine, il est sous-entendu que cette machine soit d’architecture “amd64”.
[/quote]Elle le sera puisqu’il s’agit du serveur qui est censé gérer les deux architectures.

Oui bien sûr, mais j’ai ajouté cette edition dans le cas d’une autre machine, quelle qu’elle soit.

Une installation standard amd64 est globalement portable d’une machine à une autre.

Les modes d’amorçage BIOS/UEFI doivent être compatibles. Un système installé en mode UEFI ne sera pas amorçable sur une machine qui ne boote qu’en mode BIOS et vice versa. Néanmoins on peut installer manuellement grub-pc sur un système initialement installé en UEFI. L’inverse est un peu plus délicat, car GRUB EFI a besoin d’une partition système EFI et d’un firmware UEFI actif (donc d’avoir démarré en mode UEFI) pour installer le chargeur de façon classique. plus de détails si nécessaire.

Par défaut l’initramfs est construit pour inclure tous les modules (MODULES=most dans /etc/initramfs-tools/initramfs.conf) donc s’adapte à tous les matériels.

Si X.org est installé, par défaut tous les pilotes libres sont installés et la sélection est automatique (pas de fichier xorg.conf). Les problèmes ne devraient se produire qu’avec les pilotes propriétaires ATI/AMD ou Nvidia. Eventuellement installer les firmwares non libres pour les GPU ATI/AMD pour activer le kernel mode-setting (applicable aussi au framebuffer en console) et l’accélération graphique.

Attention : les interfaces réseau peuvent avoir des nom différents, il faudra éventuellement ajuster le fichier /etc/network/interfaces.

Je vais prendre les choses l’une après l’autre, en partant des appellations suivantes :
machine serveur actuel, destinée à recevoir le futur disque = "serveur"
machine destinée à “fabriquer” le futur disque = “test”.
premier problème :
Type d’étiquette de disque “serveur” = dos
Type d’étiquette de disque “test” = gpt.
Étant donné que “serveur” est en fonction …

Je pense à l’instant que j’ai aussi un portable Dell Studio 1737, où il n’y a plus de disque car je ne m’en sers qu’en voyage avec une ClefAgreg.
Il date de 2009.

???

Le format de table de partition MSDOS ou GPT est indifferent pour Debian. Si tu y tiens, tu peux recréer une table de partition MSDOS sur le futur disque mais c’est dommage car GPT, c’est bien.

EDIT : j’avais lu de travers le message précédent et interverti MSDOS et GPT.

[quote=“PascalHambourg, post:88, topic:69587”]
Les modes d’amorçage BIOS/UEFI doivent être compatibles. Un système installé en mode UEFI ne sera pas amorçable sur une machine qui ne boote qu’en mode BIOS et vice versa. Néanmoins on peut installer manuellement grub-pc sur un système initialement installé en UEFI. L’inverse est un peu plus délicat, car GRUB EFI a besoin d’une partition système EFI et d’un firmware UEFI actif (donc d’avoir démarré en mode UEFI) pour installer le chargeur de façon classique. plus de détails si nécessaire.
[/quote]J’ai donc mal interprété.
Que dois-je vérifier et/ou comparer sur les deux machines pour que cette “fabrication” d’une jessie amd64 sur “test” soit transportable sur “serveur” ?

Je dois m’absenter et je serai de retour vers 18 h.

Tu as peut-être mal interprété en confondant le format de table de partition GPT/MSDOS avec le mode d’amorçage UEFI/BIOS. Les deux sont liés pour Windows mais pas pour GNU/Linux.

Sur “serveur”, tu dois vérifier si le mode d’amorçage du système installé est BIOS/legacy ou UEFI. Si c’est un BIOS, pas de doute. Si c’est un firmware UEFI, vérifier le(s) mode(s) d’amorçage activé(s), la variante de grub installée (grub-pc ou grub-efi-*), la présence d’une partition de type “système EFI”, présence de /sys/firmware/efi…

Sur “test”, tu dois vérifier si le firmware supporte le meme mode d’amorçage.

Je ne sais pas si cette indication est suffisante (dmidecode), mais il semblerait que Bios soit présent.
Sinon, pour donner une réponse exacte, je dois regarder dans le bios au chargement ?

dmidecode 2.12
SMBIOS 2.4 present.
37 structures occupying 1156 bytes.
Table at 0x000F0100.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: Award Software International, Inc.
Version: F2
Release Date: 08/03/2010
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 512 kB
Characteristics:
PCI is supported
PNP is supported
APM is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
5.25"/360 kB floppy services are supported (int 13h)
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
LS-120 boot is supported
ATAPI Zip drive boot is supported
BIOS boot specification is supported
Targeted content distribution is supported

Pour “test”, je regarde.

Voici le même ‘dmidecode’ pour “test”.
Ça semble être proche pour les dates du Bios…

dmidecode 2.12
SMBIOS 2.6 present.
67 structures occupying 2346 bytes.
Table at 0x000FD280.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: V1.2
Release Date: 02/05/2010
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 2048 kB
Characteristics:
ISA is supported
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
ESCD support is available
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
LS-120 boot is supported
ATAPI Zip drive boot is supported
BIOS boot specification is supported
Targeted content distribution is supported
BIOS Revision: 8.15

Tiens tant qu’on est dans le sujet du Bios, j’aimerai savoir si on peut démarrer un disque système partitionné en GPT sur un Bios legacy?

Sur mon ordibureau, je suis sous partition GPT et il semblerait que oui :

USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 4.6

Je confirme après avoir vérifié mon bios que je suis bien en ‘legacy’ sur mon ordibureau

CETTE RÉPONSE N’A RIEN À VOIR AVEC MON SUJET

J’ignore dans quelle mesure les informations rapportées par dmidecode sont fiables. Sur mon système Jessie pourtant amorcé en UEFI, il ne mentionne pas UEFI.

J’ai déjà mentionné un tas d’autres points à vérifier pour savoir si l’amorçage est possible et se fait en BIOS/legacy/CSM ou en EFI/UEFI dans ma réponse précédente.

Pour GOGI, je confirme qu’on peut démarrer en mode BIOS/legacy depuis un disque au format GPT. Ce format conserve la structure du MBR.

Dans mon ordibureau, plus récent que les deux machines en question, uefi est mentionné à la fin de dmidecode, bien que non employé :
> ACPI is supported

            USB legacy is supported
            BIOS boot specification is supported
            Targeted content distribution is supported
            **UEFI is supported**
    BIOS Revision: 4.6

Alors qu’il n’y en a aucune référence faite pour les autres machines.

UEFI existait déjà en 2010, date des versions “bios” des deux machines ?
Dans /sys/firmware, et ça pour les deux machines, aucune mention ‘efi’, dans aucun des dossiers présents : acpi ; dmi ; memmap, ni dans aucuns de leurs sous-dossiers.
Dans les deux “bios”, aucune référence ni à efi, ni à UEFI.

S’il me faut chercher ailleurs, sois gentil de me dire où.

Oui, j’ai une carte mère Intel de 2007 avec un firmware UEFI. Pas franchement au point et fonctionne mieux en mode de compatibilité BIOS, mais UEFI quand même.

Ça veut dire que les deux machines sont capables de booter en BIOS et c’est dans ce mode qu’il faut installer le nouveau système. La page d’accueil de l’installateur Debian ne doit pas afficher “GRUB EFI” mais le bon vieil écran traditionnel d’ISOLinux. Si tu veux conserver le format GPT sur le nouveau disque, pense à créer une partition de type “BIOS boot”/bios_grub non formatée de 1 Mo pour l’installation de GRUB.

J’ai téléchargé debian-8.4.0-amd64-netinst.iso , que je vais mettre sur une clef USB demain.
Je ferai attention à ce que ce soit la bonne page d’accueil
Il n’y aurait pas de problème à faire cette installation en format GPT ? une fois transféré sur “serveur” ?