Puyb Inside

lundi 16 avril 2007

J'ai tout cassé


La machine en question...
Elle m'aura causé bien des soucis !
Il y a des jours comme ça, où, à la fin de la journée, on se dit que finalement, on aurrais mieux fait de ne pas se lever...

La semaine dernière, j'ai décidé de remplacer la gentoo qui tournait plutot bien sur mon serveur perso, par une ubuntu... Je n'avais de gros griefs envers gentoo, à part le temps perdu à chaque fois que l'on souhaite ajouter un paquet...

Je me lance donc, un petit "sudo halt", je branche un lecteur de CD, grave une ubuntu 7.04 Beta AMD64 Alternate, et me lance dans l'installation...

Tout se passe bien, sauf lors du partitionnement des disques, il ne detecte pas mon array de disque RAID5... Pas grave, je me dit que je l'installerai après (cette array n'est pas le disque système).

Une fois le système installé (au passage, elle est très bien cette nouvelle Ubuntu), je tente de monter mon array RAID5...

Un petit tour dans /proc/mdstat me dit que l'array est bien detecté, mais qu'un des 4 disques (sdb1) est offline...
Je stop l'array avec "mdadm -S /dev/md0", puis la relance avec :
# mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: cannot open device /dev/sdb1: No such file or directory
mdadm: /dev/sdb1 has no superblock - assembly aborted

Le fichier /dev/sdb1 n'existe effectivement pas...

Pourtant dans mon dmesg, j'ai :
[   40.931097] scsi 6:0:0:0: Direct-Access     ATA      SAMSUNG HD501LJ  CR10 PQ: 0 ANSI: 5
[   40.931165] SCSI device sdb: 976773168 512-byte hdwr sectors (500108 MB)
[   40.931176] sdb: Write Protect is off
[   40.931178] sdb: Mode Sense: 00 3a 00 00
[   40.931191] SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   40.931235] SCSI device sdb: 976773168 512-byte hdwr sectors (500108 MB)
[   40.931243] sdb: Write Protect is off
[   40.931245] sdb: Mode Sense: 00 3a 00 00
[   40.931258] SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   40.931263]  sdb: sdb1
[   40.969599] sd 6:0:0:0: Attached scsi disk sdb
[   40.969637] sd 6:0:0:0: Attached scsi generic sg2 type 0

Qui me montre qu'il a bien trouvé une partition sdb1

et :
# fdisk -l /dev/sdb

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

  Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       60801   488384001   fd  Linux raid autodetect

La, je ne comprend pas... Je ne vois pas pourquoi le device /dev/sdb1 n'est pas créé par le daemon udev. J'ai essayé de le créer à la main avec mknod, mais ça ne fait rien...

En tout cas, je me sent vraiment con d'avoir voulu changé l'os de cette machine ! Me voilà bien embeté...
J'ai donc tenté ma chance avec la toute fraîche Debian 4.0, même peines, même motifs... Par contre, depuis les CDs d'installation, via la console, j'ai parfaitement réussi à assembler et monter mon array RAID... Plutôt étrange, n'est-il pas ?

Après de nombreuses heures d'investigation (je suis resté bloqué là dessus 2 jours entiers !!!), j'ai fini par comprendre de quoi il en retourne. Les tors sont partagés entre udevd, le démon chargé de créer les périphériques dans /dev (depuis que devfs est devenu obsolète), et mdadm, qui lui est chargé de gérer les périphériques RAIDs...
En fait, mdadm installe une série de scripts dans le initramfs, chargés d'assembler les array RAID détectées une fois que les disques durs sont détectés. C'est bien... Sauf que ça ne marche pas avec des disques SATA. De nombreuses personnes l'on constatés comme en témoigne le Bug suivant sur LaunchPad...

Ma solution :
Oui, je vous saoul avec mon histoire, il faut bien que je vous expose comment j'ai réussi à contourner le problème à défaut de le résoudre...
En fait, le principe est de réussir à démarrer un système sans lancer les scripts udevd relatifs au RAID. Une fois le système démarré, on assemble l'array RAID à la main, et on peut la monter...
# apt-get install mdadm
# cp /sbin/mdadm /sbin/mdadm.bak
# apt-get remove mdadm
# mv /sbin/mdadm.bak /sbin/mdadm
# reboot
Permet d'obtenir l'utilitaire mdadm sans les scripts de démarrage. On reboot, et on obtient un système avec toutes les partitions visibles, mais aucun disque RAID... Pour y remédier, il suffit de taper :
# mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1
Et hourra, une array RAID fonctionnel...

Il ne reste plus qu'a créer un petit script de démarrage (basé sur /etc/init.d/skeleton) pour y glisser notre commande magique, l'installer dans rcS.d en position S34 (juste avant le mountall) et l'ont dispose alors d'un OS qui démarre tout seul avec sont array RAID... C'est pas trop tôt !

Bon cette manip ne résout pas le problème, mais permet de le contourner ;-) Attention, cependant, si votre disque RAID est votre partition système (/), ce système ne marchera pas !

Merci Maman !

Ma mère vient de me faire un merveilleux cadeau !



Merci Maman !

mardi 3 avril 2007

Les geeks sont de sortie !

Et c'est vrai : je viens de voir Topher... Après 2 ans sans sortir de chez lui, il est venu me dire bonjour... A mon avis, le serveur de WoW était en panne ;-)

Sinon, une petite illustration en rapport :


Via Le journal du Geek

dimanche 1 avril 2007

Google Fait de l'acces internet

Google TiSP

Connexion en fibre optique via les égouts à installer soit même... Free peut aller se rhabiller !

En tout cas, la dernière étape :
Congratulations, you're online! (Please wash your hands before surfing.)

A quoi ça sert ?

Le moteur de postgres sur mysql ?

Je ne suis pas sûr de comprendre : est ce que les fonctionnalités de Postgres sont dans Mysql ? Ou est ce que c'est un plugin pour lire une base postgres dans mysql ?

Et dans tout les cas, quel est l'interret de transformer un serveur mysql en postgres plutot que d'installer directement un serveur postgres ?

Update 19:12 : Il semble que ce soit un canular du premier avril. Personnellement, je ne vois pas en quoi c'est drôle...