Bonjour,
Après migration de debian6 vers debian7 . j’ai tapé “fdisk -l” et j’ai eu au début : " WARNING: GPT (GUID Partition Table) detected on ‘/dev/sda’! The util fdisk doesn’t support GPT. Use GNU Parted. "
et aussi le raid1 sur le serveur est en raid dégradé.
Pouvez -vous m’aider svp, c’est urgent c’est un serveur de production.
Je vous remercie par avance.
utilise plutôt l’outil parted avec des partitions en GPT.
Concernant ton raid, il est logicielle ou matériel ?
Merci pour votre réponse.
Je connais pas vraiment GPT, mais est il normal qu’un disque de 256G soit avec des partitions en GPT.
Le serveur est en RAID1 logiciel.
Après la migration vers debian 7, le serveur a demandé d’entrer F1 pour continuer le démarrage. est ce que le problème de disque peut causer ça?
Merci.
Pourquoi pas ? les tables GPT sont un bon moyen de s’affranchir du nombre de partition primaire active, de pouvoir faire booter un système depuis un disque de plus de 2To.
Mais rien nous oblige à devoir impérativement utilisé des table de partition classique si nous ne remplissons ni l’une ni l’autre des conditions citées plus haut.
J’utilise dorénavant systématiquement des tables GPT sur les serveurs et PC que j’administre chez moi et en très grande partie à mon travail.
Dans ce cas tu peux auditer ton raid à l’aide de l’utilitaire mdadm
https://wiki.debian.org/SoftwareRAID
[code]# cat /proc/mdstat
A adapter selon le nombre de volume présent .
Non un raid dégradé ne bloque pas le démarrage du système.
Autre question subsidiaire, Grub à t’il été installé sur les deux disques (je suppose car le fait d’avoir un F1 lors du redémarrage nous indique que l’initialisation du système a commencé.
Normalement oui , vu que la partition boot est sur le /dev/md0 (sda1+sdb1), n’est ce pas ? autrement comment vérifier? (désolée je suis débutante )
cat /proc/mdstat donne :
Personalities : [raid1]
md1 : active raid1 sda3[0]
242988544 blocks [2/1] [U_]
md0 : active raid1 sda1[0]
102336 blocks [2/1] [U_]
Le disque n’est même pas reconnu par le système :
parted -l
Model: ATA WDC WD2500YS-18S (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 106MB 105MB ext2 Boot Partition raid, legacy_boot
2 106MB 1180MB 1074MB linux-swap(v1) Swap Partition
3 1180MB 250GB 249GB ext3 Root Partition raid
Model: Linux Software RAID Array (md)
Disk /dev/md0: 105MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Number Start End Size File system Flags
1 0,00B 105MB 105MB ext2
Model: Linux Software RAID Array (md)
Disk /dev/md1: 249GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Number Start End Size File system Flags
1 0,00B 249GB 249GB ext3
Que voulez vous dire par : “'initialisation du système a commencé” ? vous voulez dire initialisation de bios ?
Non ce n’est pas obligatoire, cela devrais être vérifié via un système live tel que sysrecsuecd et à l’aide d’un chroot de ton système sur le disque sda.
Avec tes retour nous pouvons aussi constater que sdb ne semble plus être visible, sans doute bon à changer, il te faudra alors le réintégrer da
On vois bien qu’il y a deux array, on peux voir que sda1 et sdb1 doivent être présent dans md0 et que md1 devrais gérer la partition /root (tout le restant en fait).
Nous pouvons constater aussi l’absence de sdb, le disque est sans doute bon à changer, il te faudra ensuite réintégrer le disque une fois changer dans ton raid à l’aide de mdadm (voir le wiki debian pour cela).
Mais il faut avant tout que ton système redémarre ce qui n’est pas le cas apparemment.
Grossière erreur de ma part, ma réponse est à oublié …
Pourrais-ton avoir les éventuels messages d’erreur qui précède la demande de F1 ?
Le serveur a pu démarré sur le sda après avoir entrer F1 mais reste en RAID1 dégradé et le sdb n’est pas reconnu.
Moi je pensais que le problème vient de disque sdb. J’ai demandé à l’hébergeur de vérifier et voici sa réponse :
"" Après vérification il se trouve que la configuration SATA du BIOS posait problème.
En effet dans le BIOS le port SATA B était désactivé et le port SATA C activé.
Hors le sdb se trouve sur le port SATA B." "
la réponse m’a étonné vu qu’il n’y a eu aucune intervention sur les paramètres de bios.
Avant la demande de F1, il y a ce message : “SATA Port C device not
found” , je comprends que le port SATA C est activé mais pas de disque branché sur ce port. que pensez-vous ?
est ce que ça peut venir d’un problème des drivers mal installés après migration vers debian7 ?
J’attends votre réponse et merci pour votre aide.
C’est qui l’hébergeur ?
Tu as accès au bios vie une IPMI ?
Il y a eu des incidents technique auparavant sur ce serveur ?
J’ai accès via un KVM. Mais je ne peux pas intervenir maintenant vu qu’il est utilisé en ce moment. (je peux intervenir que le soir (hors heures de travail) .
Depuis que je j’administre ce serveur il n’y a pas eu d’incident mais je ne sais pas d’il y a eu avant.
Pour utiliser GPT, tu dois le faire avec ‘gdisk’.
# gdisk /dev/sdX
Ensuite, tu tapes ‘?’, qui te donne toutes les possibilités.
Attention, tu tapes directement la lettre choisie sans ‘-’.
Par exemple, pour voir la table des partitions, tu entres ‘p’.
Le man est très explicite.
Dans les logs je vois les erreurs suivantes :
May 15 02:46:02 localhost kernel: [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
May 15 02:46:02 localhost kernel: [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
May 15 02:46:02 localhost kernel: [ 0.000000] No AGP bridge found ************************************************
May 15 02:46:02 localhost kernel: [ 0.000000] last_pfn = 0x230000 max_arch_pfn = 0x400000000
May 15 02:46:02 localhost kernel: [ 0.000000] MTRR default type: uncachable
May 15 02:46:02 localhost kernel: [ 0.000000] MTRR fixed ranges enabled:
May 15 02:46:02 localhost kernel: [ 0.000000] 00000-9FFFF write-back
May 15 02:46:02 localhost kernel: [ 0.000000] A0000-BFFFF uncachable
May 15 02:46:02 localhost kernel: [ 0.000000] C0000-CBFFF write-protect
May 15 02:46:02 localhost kernel: [ 0.000000] ACPI: RSDP 0x00000000000F2880 00024 (v02 DELL )
May 15 02:46:02 localhost kernel: [ 0.000000] ACPI Warning: BIOS XSDT has NULL entry, using RSDT (20110623/tbutils-658)*********************************************
May 15 02:46:02 localhost kernel: [ 0.000000] ACPI: RSDT 0x00000000000F28A4 00064 (v01 DELL PE_SC3 00000001 DELL 00000001)
Avez vous une idée s’il vous plaît. Je vous remercie par avance.
Demander gentiment à monsieur l’hébergeur si à la suite de sa vérification du BIOS il a vraiment fait quelque chose, car dire il y a un problème c’est bien, mais ne pas dire s’il a modifié la configuration et comment, c’est mal 
N’oubliez pas une phrase de politesse du genre
Mes amitiés à madame (NomHergeur)
En attendant, vous pouvez toujours lancer
lsblk
aptitude search grub | grep '^i'
Et si l’amorçage est fait classiquement avec le paquet grub-pc
sudo debconf-show grub-pc
EDIT : j’oubliais, installer le paquet ntp, le 15 mai c’était il y a plus d’un mois.
F. Petitjean
Ingénieur civil du Génie Maritime.
« Comme la tartine, l’ivrogne tombe toujours du côté qui est complètement beurré. »
– Professeur Choron
Le format de table de partition GPT a été conçu pour les plates-formes UEFI ou les disques de capacité supérieure à 2 Tio (8 Tio pour les disques au format avancé natif “4Kn” avec des secteurs logiques de 4096 octets au lieu de 512). L’installateur Debian utilise ce format par défaut pour créer une table de partition dans ces deux situations.
Toutefois rien n’interdit a priori de l’utiliser avec une plate-forme BIOS sur des disques de capacité inférieure ) 2 Tio car il a d’autres avantages (nommage et UUID des partitions, disparition de la distinction entre partitions principales et logiques, copie de sauvegarde de la table à la fin du disque). Il peut néanmoins avoir quelques inconvénients pour un disque de boot sur plate-forme BIOS dont il faut avoir conscience.
Ceci étant dit, entrons dans le vif du sujet.
La migration de Debian 6/Squeeze vers 7/Wheezy ne peut en aucune façon avoir modifié le format de table de partition du disque. Il était déjà en GPT avant.
Cette plate-forme ne semble pas être UEFI car il n’y a pas de partition système EFI sur le disque (ou alors elle était sur l’autre disque, mais il aurait mieux valu qu’il y en ait une sur chaque disque).
Quel est le chargeur d’amorçage ? Si c’est GRUB, il me semble qu’il refuse de s’installer sur un disque au format GPT sans partition special “BIOS boot” quand /boot est dans un ensemble RAID logiciel.
parted arrive à lire de type de système de fichiers des partitions RAID, ce qui indique que le superbloc RAID est à la fin de la partition. Ce superbloc est donc soit au format RAID 1.0 (à ne pas confondre avec le niveau de RAID 0, 1, 5…) soit à l’ancien format obsolète 0.90, les autres formats 1.1 et 1.2 plaçant le superbloc au début de la partition. mdadm --detail /dev/md* le confirmerait. C’est peut-être pour cette raison que GRUB a pu s’installer sans partition BIOS Boot dédiée. Quoi qu’il en soit, c’est bancal.
Autre chose qui est bancale : le swap n’est pas en RAID et ne bénéficie donc d’aucune redondance. En cas de défaillance d’un disque le système peut crasher, c’est bien la peine d’avoir du RAID.
Mais avant tout, il faut corriger les réglages du BIOS pour faire réapparaître le second disque.
Il est extrêmement peu problable que ce soit dû à la migration. Dans le doute, si tu as conserve l’ancien noyau 2.6.32 de Squeeze tu peux redémarrer avec.
En fait pas forcément. Si la plate-forme est de type BIOS (non UEFI), bien qu’aucune limite théorique ne le justifie, l’expérience montre que certains BIOS sont incapable de gérer plus de 2 Tio, et le format GPT n’y changera rien. La seule solution est de placer toutes les données nécessaires à l’amorçage devant être lues via le BIOS en deça de la limite de 2 Tio.
Merci pour repense.
Malheureusement il n’a pas dit s’il a fait la modif. mais en tous les cas il n’y a pas de changement. Mon serveur est tjrs en raid1 dégradé et je suis obligé d’entrer F1 au démarrage du serveur.
Justement la date de 15 mai sur certains logs est bizarre. NTP est bien installé sur le serveur et la date du système est correcte. Mais j’ai remarqué que certains logs dans le même fichier sont en 15 mai.
exemple :
Jun 21 14:52:10 localhost kernel: [54083.686443] PM: Marking nosave pages: 00000000000a0000 - 0000000000100000
Jun 21 14:52:10 localhost kernel: [54083.686449] PM: Marking nosave pages: 00000000cfeb2000 - 0000000100000000
Jun 21 14:52:10 localhost kernel: [54083.687344] PM: Basic memory bitmaps created
Jun 21 14:52:10 localhost kernel: [54083.722292] PM: Basic memory bitmaps freed
May 15 02:26:27 localhost kernel: imklog 5.8.11, log source = /proc/kmsg started.
May 15 02:26:27 localhost kernel: [ 0.000000] Initializing cgroup subsys cpuset
May 15 02:26:27 localhost kernel: [ 0.000000] Initializing cgroup subsys cpu
May 15 02:26:27 localhost kernel: [ 0.000000] Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.81-1
May 15 02:26:27 localhost kernel: [ 0.000000] Command line: root=/dev/md1 ro
May 15 02:26:27 localhost kernel: [ 0.000000] BIOS-provided physical RAM map:
May 15 02:26:27 localhost kernel: [ 0.000000] BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
May 15 02:26:27 localhost kernel: [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cfeb2000 (usable)
May 15 02:26:27 localhost kernel: [ 0.000000] BIOS-e820: 00000000cfeb2000 - 00000000cfec8000 (reserved)
May 15 02:26:27 localhost kernel: [ 0.000000] BIOS-e820: 00000000cfec8000 - 00000000cfee7c00 (ACPI data)
...
...
May 15 02:26:40 localhost kernel: [ 28.875902] IPMI System Interface driver.
May 15 02:26:40 localhost kernel: [ 28.880413] ipmi_si: probing via SMBIOS
May 15 02:26:40 localhost kernel: [ 28.884775] ipmi_si: SMBIOS: io 0xca8 regsize 1 spacing 4 irq 0
May 15 02:26:40 localhost kernel: [ 28.889104] ipmi_si: Adding SMBIOS-specified kcs state machine
May 15 02:26:40 localhost kernel: [ 28.893360] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o address 0xca8, slave address 0x20, irq 0
May 15 02:26:40 localhost kernel: [ 29.083181] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x0002a2, prod_id: 0x0000, dev_id: 0x20)
May 15 02:26:40 localhost kernel: [ 29.087668] ipmi_si ipmi_si.0: IPMI kcs interface initialized
May 15 02:26:40 localhost kernel: [ 29.358725] ipmi device interface
May 15 02:26:42 localhost kernel: [ 30.901202] ip_tables: (C) 2000-2006 Netfilter Core Team
Jun 22 00:38:55 localhost kernel: [ 45.192260] Fusion MPT base driver 3.04.20
Jun 22 00:38:55 localhost kernel: [ 45.196713] Copyright (c) 1999-2008 LSI Corporation
Jun 22 00:38:56 localhost kernel: [ 45.228237] Fusion MPT misc device (ioctl) driver 3.04.20
Jun 22 00:38:56 localhost kernel: [ 45.232742] mptctl: Registered with Fusion MPT base driver
Jun 22 00:38:56 localhost kernel: [ 45.237129] mptctl: /dev/mptctl @ (major,minor=10,220)
Jun 22 00:38:56 localhost kernel: [ 45.908407] mpt2sas version 10.100.00.00 loaded
Jun 22 00:40:57 localhost kernel: imklog 5.8.11, log source = /proc/kmsg started.
Jun 22 00:40:57 localhost kernel: [ 0.000000] Initializing cgroup subsys cpuset
Jun 22 00:40:57 localhost kernel: [ 0.000000] Initializing cgroup subsys cpu
Jun 22 00:40:57 localhost kernel: [ 0.000000] Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.81-1
Jun 22 00:40:57 localhost kernel: [ 0.000000] Command line: root=/dev/md1 ro
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-provided physical RAM map:
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cfeb2000 (usable)
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-e820: 00000000cfeb2000 - 00000000cfec8000 (reserved)
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-e820: 00000000cfec8000 - 00000000cfee7c00 (ACPI data)
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-e820: 00000000cfee7c00 - 00000000d0000000 (reserved)
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-e820: 00000000fe000000 - 0000000100000000 (reserved)
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-e820: 0000000100000000 - 0000000230000000 (usable)
...Je pense ça c’est lié à la pile du serveur n’est ce pas. ou le serveur en fin de vie.
Le chargeur d’amorçage c’est GRUB. F1 a permet de continuer le démarrage du serveur, et le serveur il est bien sur le nouveau noyau (3.2.0-4-amd64), donc GRUB a pu s’installer n’est pas ?
avant la migration il était sur “3.2.0-0.bpo.4-amd64”
uname -a
Linux ik42009 3.2.0-4-amd64 #1 SMP Debian 3.2.81-1 x86_64 GNU/LinuxL’ancien noyau est celui de squeeze-backports qui est très proche de celui de wheezy, donc il y a peu de chances que le problème vienne de là.
La priorité est de régler cette histoire de ports SATA désactivés dans le BIOS.
La date de 15 mai sur certains logs est bizarre. NTP est bien installé sur le serveur et la date du système est correcte. Mais j’ai remarqué que les premiers logs du serveur sont au 15 mai à chaque redémarrage.
exemple :
Jun 21 14:52:10 localhost kernel: [54083.686443] PM: Marking nosave pages: 00000000000a0000 - 0000000000100000
Jun 21 14:52:10 localhost kernel: [54083.686449] PM: Marking nosave pages: 00000000cfeb2000 - 0000000100000000
Jun 21 14:52:10 localhost kernel: [54083.687344] PM: Basic memory bitmaps created
Jun 21 14:52:10 localhost kernel: [54083.722292] PM: Basic memory bitmaps freed
May 15 02:26:27 localhost kernel: imklog 5.8.11, log source = /proc/kmsg started.
May 15 02:26:27 localhost kernel: [ 0.000000] Initializing cgroup subsys cpuset
May 15 02:26:27 localhost kernel: [ 0.000000] Initializing cgroup subsys cpu
May 15 02:26:27 localhost kernel: [ 0.000000] Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.81-1
May 15 02:26:27 localhost kernel: [ 0.000000] Command line: root=/dev/md1 ro
May 15 02:26:27 localhost kernel: [ 0.000000] BIOS-provided physical RAM map:
May 15 02:26:27 localhost kernel: [ 0.000000] BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
May 15 02:26:27 localhost kernel: [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cfeb2000 (usable)
May 15 02:26:27 localhost kernel: [ 0.000000] BIOS-e820: 00000000cfeb2000 - 00000000cfec8000 (reserved)
May 15 02:26:27 localhost kernel: [ 0.000000] BIOS-e820: 00000000cfec8000 - 00000000cfee7c00 (ACPI data)
...
...
May 15 02:26:40 localhost kernel: [ 28.875902] IPMI System Interface driver.
May 15 02:26:40 localhost kernel: [ 28.880413] ipmi_si: probing via SMBIOS
May 15 02:26:40 localhost kernel: [ 28.884775] ipmi_si: SMBIOS: io 0xca8 regsize 1 spacing 4 irq 0
May 15 02:26:40 localhost kernel: [ 28.889104] ipmi_si: Adding SMBIOS-specified kcs state machine
May 15 02:26:40 localhost kernel: [ 28.893360] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o address 0xca8, slave address 0x20, irq 0
May 15 02:26:40 localhost kernel: [ 29.083181] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x0002a2, prod_id: 0x0000, dev_id: 0x20)
May 15 02:26:40 localhost kernel: [ 29.087668] ipmi_si ipmi_si.0: IPMI kcs interface initialized
May 15 02:26:40 localhost kernel: [ 29.358725] ipmi device interface
May 15 02:26:42 localhost kernel: [ 30.901202] ip_tables: (C) 2000-2006 Netfilter Core Team
Jun 22 00:38:55 localhost kernel: [ 45.192260] Fusion MPT base driver 3.04.20
Jun 22 00:38:55 localhost kernel: [ 45.196713] Copyright (c) 1999-2008 LSI Corporation
Jun 22 00:38:56 localhost kernel: [ 45.228237] Fusion MPT misc device (ioctl) driver 3.04.20
Jun 22 00:38:56 localhost kernel: [ 45.232742] mptctl: Registered with Fusion MPT base driver
Jun 22 00:38:56 localhost kernel: [ 45.237129] mptctl: /dev/mptctl @ (major,minor=10,220)
Jun 22 00:38:56 localhost kernel: [ 45.908407] mpt2sas version 10.100.00.00 loaded
Jun 22 00:40:57 localhost kernel: imklog 5.8.11, log source = /proc/kmsg started.
Jun 22 00:40:57 localhost kernel: [ 0.000000] Initializing cgroup subsys cpuset
Jun 22 00:40:57 localhost kernel: [ 0.000000] Initializing cgroup subsys cpu
Jun 22 00:40:57 localhost kernel: [ 0.000000] Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.81-1
Jun 22 00:40:57 localhost kernel: [ 0.000000] Command line: root=/dev/md1 ro
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-provided physical RAM map:
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cfeb2000 (usable)
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-e820: 00000000cfeb2000 - 00000000cfec8000 (reserved)
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-e820: 00000000cfec8000 - 00000000cfee7c00 (ACPI data)
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-e820: 00000000cfee7c00 - 00000000d0000000 (reserved)
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-e820: 00000000fe000000 - 0000000100000000 (reserved)
Jun 22 00:40:57 localhost kernel: [ 0.000000] BIOS-e820: 0000000100000000 - 0000000230000000 (usable)
...Je pense ça c’est lié à la pile qui est en fin de vie (ne tient plus) du serveur n’est ce pas? La date et l’heure sont sauvegardées dans la CMOS qui est tenu par la pile. donc si la pile est lâchée donc la CMOS ne tient pas et perd ses informations n’est ce pas ? donc au démarrage du PC tous les logs restent avec une date erronées jusqu’à le lancement de NTP.
L’hébergeur me demande si j’ai modifié les paramètres de bios, moi je n’ai pas modifié ni lui aussi . donc moi je pense le bios est revenu aux paramètres initiales sans notre intervention à cause de la CMOS qui est vidée car la pile est lachée. Pouvez-vous me dire si mon résonnement est correcte ?
Merci d’avance.
J’ai un doute car normalement la pile ne sert que lors d’une coupure d’alimentation pour prendre le relais de la tension de veille. Un simple redémarrage sans mise hors tension ne doit donc pas faire perdre la date et l’heure. Mais je ne connais pas ces serveurs dédiés.
As-tu accès aux réglages du BIOS ?