Pb noyau perso et raid

Salut tous,
j’ai un pb avec un noyau compilé qui boot pas en raid1 ( kernel panic )
Installation sur squeeze amd64.
voilà ma démarche je part d’une bisnesscarte en expert gui.
partiton /dev/sda1 de 7 go pour / , /dev/sda2 240 go pour /home et /dev/sda3 de 1 go pour le swap
partiton /dev/sdb1 de 7 go pour / , /dev/sdb2 240 go pour /home et /dev/sdb3 de 1 go pour le swap
je construit le raid1 en ext4 /dev/md0 pour / et /dev/md1 pour /home
déjà il m’affiche 512 bytes non utilisées pour le /dev/md0 bon pas grave.
Je boot sur le 2.6.32 de l’install construit avec l’image pour mon matériel comme choisie à l’install.
La je prend les sources je fait un make menuconfig je met en dur le raid le fs ( ext2,ext3, ext4) tous se qu’il faut mon controlleur sata.
je recomplie avec l’initram et reboot il fonctionne ok.
un lsmod m’indique que je n’ai plus de modules en rapport avec mes disque le raid etc.
ok je prend donc le config sans modifier quoique se soit, je fait un make-kpkg clean et je recompile sans initram.
au reboot kernel panic il trouve pas la partition root.
je reboot sur le noyau recompilé avec intram je décompresse l’initram pour voir se qui s’y trouve.
il y a mdadm dedans
Donc j’en conclue que sans initram mdadm fonctionne pas.
J’ai essaye aussi avec make localmodconfig puis make localyesconfig et recompil sans intram
je reboot kernel panic

j’ai essaye avec lenny idem.

J’ai déjà installer debian avec les disques dur presents.
Je ne sais plus quoi penser.
J’ai changer de c-m et cela fonctionné.
mais une installation neuve pose pb sans l’initram
j’ai aussi modifier grub avec root=/dev/md0 root=/dev/md/0 à la place des uuid idem.
donc je viens vous demander votre avis sur mon pb.
merci d’avance à plus

Pour vérifier ce qui se passe lors du démarrage, enlève l’option “quiet” des paramètres du noyau passés par grub (ou démarre en single user).

Le noyau ne connaît rien aux UUID et autres labels, donc sans initramfs il est impossible de désigner la racine de cette façon.

<https://raid.wiki.kernel.org/index.php/Autodetect>
L’assemblage automatique des volumes RAID par un noyau avec les modules md compilé en dur suppose que les partitions RAID sont de type “RAID autodetect” (0xfd, vérifier avec fdisk)) et ont un superblock au format 0.9 (vérifier avec mdadm --examine), est-ce bien le cas ? Je l’avais fait pour une machine sous etch en spécifiant root=/dev/mdX, ça marchait.

Lu et merci de repondre sur mon pb ^^

[code]Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00045b20

Device Boot Start End Blocks Id System
/dev/sda1 * 1 852 6835200 fd Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sda2 852 30285 236426240 fd Linux raid autodetect

Disk /dev/sdb: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00057c16

Device Boot Start End Blocks Id System
/dev/sdb1 * 1 852 6835200 fd Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sdb2 852 30285 236426240 fd Linux raid autodetect
/dev/sdb3 30285 30402 935936 82 Linux swap / Solaris
[/code]
pour les uuid j’ai virer essayer divers option rien ne fonctionne.

je vais reprendre à zero grub pour voir

Vérifie dans les messages du noyau sans l’option quiet si les partitions RAID sont bien détectées et assemblées.
Quelles sont les dernières lignes avant le kernel panic ?

Notes sur le swap :

  • à la fin du disque ce n’est pas idéal car loin de tout donc temps d’accès augmenté ;
  • il devrait être en RAID aussi.

lu PascalHambourg
alors j’ai pris le dernier installateur et refait une install se que je peut te dire dans l’immédiat :

[code]cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sda2[0] sdb2[1]
236425080 blocks super 1.2 [2/2] [UU]
[==========>…] resync = 51.1% (120891968/236425080) finish=36.3min speed=52963K/sec

md0 : active raid1 sda1[0] sdb1[1]
6834164 blocks super 1.2 [2/2] [UU]
[/code]

[code]Disk /dev/sdb: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00057c16

Device Boot Start End Blocks Id System
/dev/sdb1 * 1 852 6835200 fd Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sdb2 852 30285 236426240 fd Linux raid autodetect
/dev/sdb3 30285 30402 935936 82 Linux swap / Solaris

Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00045b20

Device Boot Start End Blocks Id System
/dev/sda1 * 1 852 6835200 fd Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sda2 852 30285 236426240 fd Linux raid autodetect

[/code]

[code]Disk /dev/md0: 6998 MB, 6998183936 bytes
2 heads, 4 sectors/track, 1708541 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/md0 doesn’t contain a valid partition table

Disk /dev/md1: 242.1 GB, 242099281920 bytes
2 heads, 4 sectors/track, 59106270 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/md1 doesn’t contain a valid partition table
[/code]

[code]mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Thu Oct 7 19:17:02 2010
Raid Level : raid1
Array Size : 6834164 (6.52 GiB 7.00 GB)
Used Dev Size : 6834164 (6.52 GiB 7.00 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Thu Oct  7 18:21:48 2010
      State : active

Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

       Name : debian:0  (local to host debian)
       UUID : 3e262650:92e2d644:2d4fda02:14d3ab7f
     Events : 35

Number   Major   Minor   RaidDevice State
   0       8        1        0      active sync   /dev/sda1
   1       8       17        1      active sync   /dev/sdb1

[/code]

[code]mdadm --detail /dev/md1
/dev/md1:
Version : 1.2
Creation Time : Thu Oct 7 19:17:13 2010
Raid Level : raid1
Array Size : 236425080 (225.47 GiB 242.10 GB)
Used Dev Size : 236425080 (225.47 GiB 242.10 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Thu Oct  7 18:20:31 2010
      State : active, resyncing

Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Rebuild Status : 54% complete

       Name : debian:1  (local to host debian)
       UUID : e4b83292:45cca904:d7dd0bff:9d593802
     Events : 31

Number   Major   Minor   RaidDevice State
   0       8        2        0      active sync   /dev/sda2
   1       8       18        1      active sync   /dev/sdb2

[/code]

Le plus inquiétant étant çà :

[code]mdadm --examine /dev/md0
mdadm: No md superblock detected on /dev/md0.

mdadm --examine /dev/md1
mdadm: No md superblock detected on /dev/md1.
[/code]
Pb matériel des dd ?

hum peut etre une piste sur le liens que tu donne plus haut cela renvoie vers cette page :
raid.wiki.kernel.org/index.php/Superblock

si je comprend bien le noyau se base sur la version 0.90 de superblocks.
Alors que mdadm se base sur la version 1.2 d’où mon pb pour démarrer mon raid visiblement non ?

mdadm --examine se fait sur une partition membre (/dev/sdXY), pas un volume résultant (/dev/mdX).
D’après la sortie des autres commandes, je soupçonne que les superblocks sont en version 1.2.

oui je pense que le souci viens de la différence de version de superbloc.

[code]mdadm --examine /dev/sda1
/dev/sda1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3e262650:92e2d644:2d4fda02:14d3ab7f
Name : debian:0 (local to host debian)
Creation Time : Thu Oct 7 19:17:02 2010
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 13668352 (6.52 GiB 7.00 GB)
Array Size : 13668328 (6.52 GiB 7.00 GB)
Used Dev Size : 13668328 (6.52 GiB 7.00 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : active
Device UUID : 861c79b6:569bed0e:7a5fa0af:d3c3b360

Update Time : Thu Oct  7 18:42:42 2010
   Checksum : cb044ba6 - correct
     Events : 35

Device Role : Active device 0
Array State : AA (‘A’ == active, ‘.’ == missing)
[/code]

[code]mdadm --examine /dev/sdb1
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3e262650:92e2d644:2d4fda02:14d3ab7f
Name : debian:0 (local to host debian)
Creation Time : Thu Oct 7 19:17:02 2010
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 13668352 (6.52 GiB 7.00 GB)
Array Size : 13668328 (6.52 GiB 7.00 GB)
Used Dev Size : 13668328 (6.52 GiB 7.00 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : bfcfe16c:48e581ad:aaeeabd4:3ca54f4b

Update Time : Thu Oct  7 18:43:48 2010
   Checksum : 2fa8b9ad - correct
     Events : 34

Device Role : Active device 1
Array State : AA (‘A’ == active, ‘.’ == missing)
[/code]

[code]mdadm --examine /dev/sda2
/dev/sda2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : e4b83292:45cca904:d7dd0bff:9d593802
Name : debian:1 (local to host debian)
Creation Time : Thu Oct 7 19:17:13 2010
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 472850432 (225.47 GiB 242.10 GB)
Array Size : 472850160 (225.47 GiB 242.10 GB)
Used Dev Size : 472850160 (225.47 GiB 242.10 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : active
Device UUID : 30b71894:d7d3cf4e:c634d6d0:a8ee6827

Update Time : Thu Oct  7 18:42:31 2010
   Checksum : 88cbcf8b - correct
     Events : 39

Device Role : Active device 0
Array State : AA (‘A’ == active, ‘.’ == missing)
[/code]

[code]mdadm --examine /dev/sdb2
/dev/sdb2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : e4b83292:45cca904:d7dd0bff:9d593802
Name : debian:1 (local to host debian)
Creation Time : Thu Oct 7 19:17:13 2010
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 472850432 (225.47 GiB 242.10 GB)
Array Size : 472850160 (225.47 GiB 242.10 GB)
Used Dev Size : 472850160 (225.47 GiB 242.10 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : active
Device UUID : 6cc1aa6e:873acf70:69d203e2:3e39ce57

Update Time : Thu Oct  7 18:42:31 2010
   Checksum : c6f028b1 - correct
     Events : 39

Device Role : Active device 1
Array State : AA (‘A’ == active, ‘.’ == missing)
[/code]

Voilà, tu as l’explication. Pour démarrer sans initramfs, le volume racine doit avoir un superblock de type 0.9. Il faut savoir que les superblocks de type 1.x apportent des avantages par rapport à ceux de type 0.9, suivre les liens sur la page du wiki RAID.

C’était juste pour tester ou tu as une raison particulière de vouloir démarrer sans initramfs ?

Alors j’ai un serveur perso en lenny qui tourne sur un kernel perso sans initram et pour mon pc j’ai pris le partie de faire pareil cela depuis plus de 1 an 1/2.
autant sur un serveur sans l’initram est une bonne chose a mon avis autant sur un desktop cela se justifie moins.
Donc le pb sur mon desktop va certainement se poser lors du passage de lenny à squeeze et la ce sera pas top de remettre un intram sur mon serveur.
Donc j’aimerais trouver la solution avant cette fameuse mise à jours lenny -> squeeze.
Hormis redescendre la version de mdadm je vois pas comment faire.
je suis quand même pas le seul au monde à utiliser du raid 1 sans initram ?

Si les volumes RAID de ton serveur sont déjà créés avec des superblocks en version 0.9, alors tu ne devrais pas avoir de problème tant que le noyau supportera l’assemblage automatique. La version de mdadm est indépendante de la version des superblocks.

Le problème ne se pose que pour une nouvelle installation : il faut faire attention à créer les volumes RAID avec un superblock en version 0.9, au moins en ce qui concerne le volume racine qu’il est indispensable d’assembler automatiquement. Si l’installateur Debian ne le permet pas, il sera nécessaire de le faire manuellement avec mdadm.

Donc visiblement avec le D-I cela pose pb.
je vais faire cela manuellement et voir si le pb est toujours présent.
la commande c’est mdadm --create /dev/md0 --metadata 1.2 <blah>
Dans mon cas il faut que je fasse mdadm --create /dev/md0 --metadata 0.9 <blah>
je suppose.

Avant il faudra arrêter et détruire le volume existant. Je suggère aussi d’effacer les superblocks en version 1.2 ensuite avant de recréer les volume en version 0.9 car ils ne sont pas au même endroits, il ne s’écrasent donc pas.

Accessoirement je recommande de toujours effacer les superblocs après avoir démantelé un volume RAID car leur seule présence peut avoir des effets de bord.

hum là je connait pas les commande à passer pour cela .
si je passe par le D-I et je le fait pas lui c’est pareil non ?

La commande mdadm doit être disponible dans D-I via un shell (consoles 2 et 3).
Pour arrêter un volume si actif : mdadm --stop
Pour effacer un superblock : mdadm --zero-superblock

lu
si je crée une partition pour mettre le /boot en raid1 avec des superblock en 0.90 et le reste en 1.2 cela permettra de résoudre le pb ou pas ?

donc c’est bien un pb de superblock
avec un superblock 0.90 pour / cela boot avec un petit message pour le raid 1 du /home qu’il reconnait pas mais pas graves ça.

Par contre c’est plus un pb lie au noyau qu’à debian il me semble.
reste à trouve une alternative pour utiliser les superbloc en version 1 et >

Non. /boot ne contient que le chargeur et le noyau (et l’initramfs le cas échéant) et n’a pas besoin d’être monté au démarrage. D’ailleurs le chargeur et le noyau se lancent, donc il n’y a pas de problème avec /boot. C’est le volume racine / qui doit être monté et donc assemblé lorsqu’il est en RAID.

En effet. Le wiki RAID dit

Je n’ai pas trouvé dans les ChangeLogs des versions suivantes du noyau d’annonce de la suppression de cette limitation. Cela n’est pas étonnant car le même wiki qualifie l’autodétection par le noyau de “deprecated”, donc un développement pour rendre cette fonctionnalité compatible avec les superblocks 1.x est improbable.

oui j’ai fait qq recherche et je suis tomber sur cela :
kerneltrap.org/mailarchive/linux … 723/thread

notamment un message de Neil Brown dev de mdadm :

[quote]And yes, 0.90 is still the only superblock version that supports in-kernel
autodetect, and I have no intention of adding in-kernel autodetect for any
other version.[/quote]
kerneltrap.org/mailarchive/linux … 16/6779833
Donc cela semble “fichue” lol
car j’ai regarder dans les source du 2.6.36 c’est encore le 0.90

Bon il est possible de faire un initram seulement pour mdadm c’est indiquer dans les sources de mdadm
C’est dommage car pas mal en serveur n’utilise plus d’initram qui inclue un risque sécuritaire bien hypothétique mais réel

Après le pb se pose que pour une installation "fraiche"
et j’ai pas encore bien compris la différence entre la 0.90 et 1.2 des superblocs

bon visiblement cela gène personne car peu d’écho du pb sur le net lol
en tous cas merci à toi PascalHambourg

Quel risque pour la sécurité un initramfs implique-t-il au juste ?

heu j’avais lu dans le linux mag hors série N°28 de janvier/février 2007 consacré à etch

[quote]Avantage pour un serveur, l’absence de fonctionnalité de chargement dynamique de modules empêche l’installation de la pire forme de rootkit : celle d’un module noyau.
L’utilisation d’un noyau statiquement compilé est donc un gain de sécurité non négligeable[/quote]
Après c’est peut être plus d’actualité, c’est peux être une co**