~~NOTOC~~
<note important>
Il se peut que les infos ci-dessous ne fonctionnent pas malgré tout. Ca dépend pas mal de votre config. Ce sont juste des pistes.
</note>


Hormis les Dedibox PRO on a pas d'accès console. Du coup quand la machine ne reboote pas on bosse en aveugle. On peut toujours demander un KVM sur IP mais dans certains cas c'est payant (Dedibox en zone A) et la délai d'activations semble un peu long. Ci-dessous les différentes manipulations que j'ai effectué pour me sortir de la mouise.

note : les exemples ci-dessous considèrent la structure suivante :

<code>
dedibox:/etc/xen# df -khP|grep md
/dev/md1              2.0G  269M  1.7G  15% /
/dev/md0              244M   33M  199M  15% /boot
/dev/md3              4.0G  2.0G  1.8G  53% /usr
/dev/md2              4.0G  1.3G  2.5G  35% /var
</code>

====== /etc/fstab foiré ======

Si le fichier ///etc/fstab// contient des entrées incorrectes la machine ne boote pas. Un device ou un LV mal orthographié suffit. Il faut passer en mode //rescue//, monter le / et corriger le fichier :

  mount /dev/md1 /mnt
  vi /mnt/etc/fstab

====== grub foiré ======

On a aussi le cas où Grub s'est barré du MBR, dans ce cas ça boote moins bien. Même technique, on boote en mode rescue. Il suffit de lancer la commande suivante :

  grub-install /sda

Si vous êtes en RAID la mise à jour se fera sur le deuxième disque (ici /dev/sdb). Pour checker l'existence du Grub voir [[http://bazar.ndlp.info/doku.php/informatique:nix:linux:linux_boot?#grub_ou_lilo|ici]].

====== initrd foiré ======

Autre cas sympathique. Lors d'un upgrade kernel ou tout autre manipulation régénérant l'initrd on peut avoir des surprises lors du boot suivant. Pour régénérer l'initrd on lance le mode rescue et on exécute les actions suivantes :

<code>
mount /dev/md1 /mnt
mount /dev/md2 /mnt/var
mount /dev/md3 /mnt/usr
mount /dev/md0 /mnt/boot
chroot /mnt
mount /proc
mount /sys
mkinitramfs -c -k 2.6.18 ou update-initramfs
</code>