[Cedric_M]

Bonjour,

J'ai pu constater qu'il n'était pas possible d'héberger le FileSystem / sur du LVM lors de l'installation de l'OS CentOS 6.4 via le Manager... Je me suis donc lancé pour procédurer cela (en utilisant un Kernel mis à disposition par OVH). Utiliser LVM pour y héberger ses données a notamment pour intérêt la possibilité d'utiliser les snapshots pour effectuer des sauvegardes "cohérentes".

Je ne dis pas qu'il s'agit de la meilleure méthode pour atteindre l'objectif fixé, mais elle a le mérite d'avoir fonctionné pour moi . Comme d'habitude, avant d'envisager ce type d'action, un back-up est clairement nécessaire !!! (sauf sur un OS fraichement installé comme ce fut le cas pour moi).


I. Installation du serveur via le manager
Etape 1/3
OS: Système d’exploitation Linux
Type de distribution : Distribution de base
Distribution : CentOS 6.4, 64bits
Option : Anglais

Etape 2/3
Partitionnement personnalisé, RAID Software

Etape 3/3
(à adapter à l'usage de votre serveur...)
1. /boot de 512Mo en ext4 (primaire) en RAID 1
2. swap de 3072Mo (logique), ce qui fera un total de 6144Mo
/ de 81.920Mo en ext4 (logique) #Futur PV du système
/mnt de 914.532Mo (tout le reste) en ext3 (logique) #Futur PV des backups

Lancer la réinstallation !!!!

Une fois l’installation terminée, mettre le Netboot en «rescue-pro» puis redémarrer le serveur

II. Mise en LVM de toutes les données
Partitionnement cible (à adapter à l'usage de votre serveur...)
/ de 8G en ext4
/tmp de 2G en ext4
/var de 4G en ext4
/home de 4G en ext4

Petite revue des RAID Soft mis en place

root@rescue:~# mdadm -D --scan
mdadm: cannot open /dev/md/7: No such file or directory
mdadm: cannot open /dev/md/6: No such file or directory
mdadm: cannot open /dev/md/1: No such file or directory
root@rescue:~#

On monte le système installé par le manager dans /mnt

root@rescue:~# mount /dev/md6 /mnt
root@rescue:~# mount /dev/md1 /mnt/boot/
root@rescue:~# du -sh /mnt
575M /mnt
root@rescue:~#

On va utiliser la partition déclarée comme "/mnt" à l'installation du système pour héberger le "Physical Volume", qui constituera le "Volume Group" destiné à héberger les back-ups :

root@rescue:~# pvcreate /dev/md7
Writing physical volume data to disk "/dev/md7"
Physical volume "/dev/md7" successfully created
root@rescue:~# vgcreate vg_backup /dev/md7
Volume group "vg_backup" successfully created
root@rescue:~#

On y crée ensuite un Logical Volume pour y stocker le système fraichement installé via le Manager (1G suffit):

root@rescue:~# lvcreate -L 1G -n all_initial vg_backup
Logical volume "all_initial" created
root@rescue:~# mkfs.ext4 /dev/vg_backup/all_initial
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
65536 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376

Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
root@rescue:~#

Il reste à copier le système fraichement installé via le Manager :

root@rescue:~# mkdir /mnt2
root@rescue:~# mount /dev/vg_backup/all_initial /mnt2
root@rescue:~# rsync -a /mnt/* /mnt2
root@rescue:~# diff /mnt /mnt2
Only in /mnt: .autorelabel
Common subdirectories: /mnt/bin and /mnt2/bin
Common subdirectories: /mnt/boot and /mnt2/boot
Common subdirectories: /mnt/cgroup and /mnt2/cgroup
Common subdirectories: /mnt/dev and /mnt2/dev
Common subdirectories: /mnt/etc and /mnt2/etc
Common subdirectories: /mnt/home and /mnt2/home
Common subdirectories: /mnt/lib and /mnt2/lib
Common subdirectories: /mnt/lib64 and /mnt2/lib64
Common subdirectories: /mnt/lost+found and /mnt2/lost+found
Common subdirectories: /mnt/media and /mnt2/media
Common subdirectories: /mnt/mnt and /mnt2/mnt
Common subdirectories: /mnt/opt and /mnt2/opt
Common subdirectories: /mnt/proc and /mnt2/proc
Common subdirectories: /mnt/root and /mnt2/root
Common subdirectories: /mnt/sbin and /mnt2/sbin
Common subdirectories: /mnt/selinux and /mnt2/selinux
Common subdirectories: /mnt/srv and /mnt2/srv
Common subdirectories: /mnt/sys and /mnt2/sys
Common subdirectories: /mnt/tmp and /mnt2/tmp
Common subdirectories: /mnt/usr and /mnt2/usr
Common subdirectories: /mnt/var and /mnt2/var
root@rescue:~# umount /mnt2
root@rescue:~#

Comme pour le LV "all_initial" créé à l'instant, procéder à la création des LV tels que vous voulez les retrouver sur votre système cible (et les formater en ext4). Voilà le résultat que cela donne me concernant :

root@rescue:~# lvdisplay | egrep "LV (Path|Size)"
LV Path /dev/vg_backup/all_initial
LV Size 1.00 GiB
LV Path /dev/vg_backup/lv_sys
LV Size 8.00 GiB
LV Path /dev/vg_backup/lv_tmp
LV Size 2.00 GiB
LV Path /dev/vg_backup/lv_var
LV Size 4.00 GiB
LV Path /dev/vg_backup/lv_home
LV Size 4.00 GiB
root@rescue:~#

Monter ces nouveaux volumes (sur /mnt2 par exemple) tels que vous voulez les retrouver sur votre système cible et y copier le système installé via le manager (vous noterez que je démonte /mnt/boot car ce dernier ne sera pas sous LVM) :

root@rescue:~# mount /dev/vg_backup/lv_sys /mnt2
root@rescue:~# cd /mnt2
root@rescue:/mnt2# mkdir tmp
root@rescue:/mnt2# mount /dev/vg_backup/lv_tmp tmp
root@rescue:/mnt2# mkdir var
root@rescue:/mnt2# mount /dev/vg_backup/lv_var var
root@rescue:/mnt2# mkdir home
root@rescue:/mnt2# mount /dev/vg_backup/lv_home home
root@rescue:/mnt2# umount /mnt/boot
root@rescue:/mnt2# df -h *
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_backup-lv_home 4.0G 190M 3.7G 5% /mnt2/home
/dev/mapper/vg_backup-lv_sys 8.0G 249M 7.4G 4% /mnt2
/dev/mapper/vg_backup-lv_tmp 2.0G 96M 1.9G 5% /mnt2/tmp
/dev/mapper/vg_backup-lv_var 4.0G 190M 3.7G 5% /mnt2/var
root@rescue:/mnt2# cd ..
root@rescue:/# rsync -a /mnt/* /mnt2
root@rescue:/#

Pour éviter tout dysfonctionnement lors du montage des FS déclarés dans le fichier fstab lors du boot, il faut modifier /mnt/etc/fstab pour ne plus monter /dev/md7 sur /mnt (car /dev/md7 héberge désormais un PV LVM...) :

root@rescue:/mnt/etc# cp -p fstab fstab.init
root@rescue:/mnt/etc# grep -v "/mnt" fstab.init > fstab
root@rescue:/mnt/etc# diff fstab fstab.init
3a4
> /dev/md7 /mnt ext3 defaults 1 2
root@rescue:/mnt/etc#

Le backup est prêt et notre futur partitionnement est mis en place.
On reboot en mode «hd» pour poursuivre les modifications.


III. Mise en place de l’activation des volumes LVM au boot

Afin de créer du fichier initramfs pour provoquer le boot sur les volumes LVM, installation de dracut (outil qui nous permettra de créer l’image) :

yum -y update
yum -y install dracut

Création du fichier qui permettra d’activer les volumes LVM avant de monter lerootfs (le pipe vinfo permet de voir le résultat des commandes dans /var/log/messages... ce qui peut se révéler intéressant pour une phase de debug...) :

[root@ks368088 log]# mkdir -p /root/initramfs
[root@ks368088 log]# echo "lvm pvscan -d 2>&1 | vinfo" > /root/initramfs/50lvmactivation.sh
[root@ks368088 log]# echo "lvm vgscan -d 2>&1 | vinfo" >> /root/initramfs/50lvmactivation.sh
[root@ks368088 log]# echo "lvm lvscan -d 2>&1 | vinfo" >> /root/initramfs/50lvmactivation.sh
[root@ks368088 log]# echo "lvm vgchange -a y -d 2>&1 | vinfo" >> /root/initramfs/50lvmactivation.sh
[root@ks368088 log]# echo "lvm lvdisplay -d 2>&1 | vinfo" >> /root/initramfs/50lvmactivation.sh
[root@ks368088 log]# chmod 700 /root/initramfs/50lvmactivation.sh
[root@ks368088 log]#

Création de l’image, avec le script créé à l'instant mis en place dans le dossier "pre-mount" (dossier dont le contenu est exécuté avant la tentative de montage du rootfs sans le script "init" de l'image). Sans cela, les volumes logiques LVM ne seront pas actifs lorsque l'on souhaitera monter le "rootfs" :

[root@ks368088 log]# dracut -a "mdraid lvm" --no-kernel -i /root/initramfs/50lvmactivation.sh /pre-mount/50lvmactivation.sh /boot/initramfs.`uname -r`.img
[root@ks368088 log]# ls -lrt /boot
total 14015
drwxr-xr-x 3 root root 1024 8 juil. 2011 efi
-rw-r--r-- 1 1002 1002 2206409 2 avril 2012 System.map-3.2.13-xxxx-grs-ipv6-64
-rw-r--r-- 1 1002 1002 6134704 2 avril 2012 bzImage-3.2.13-xxxx-grs-ipv6-64
drwx------ 2 root root 12288 13 mars 22:19 lost+found
drwxr-xr-x 2 root root 1024 13 mars 22:26 grub
-rw-r--r-- 1 root root 5995368 13 mars 23:24 initramfs.3.2.13-grsec-xxxx-grs-ipv6-64.img
[root@ks368088 log]#

Téléchargement du kernel «standard» car le kernel «grsec» ne permet pas le lancement de initrd. Il faut être dans /boot pour lancer les commandes suivantes :

[root@ks368088 boot]# wget ftp://ftp.ovh.net/made-in-ovh/bzImag.../*-std-ipv6-64
--2013-03-13 23:28:15-- ftp://ftp.ovh.net/made-in-ovh/bzImag.../*-std-ipv6-64
=> «.listing»
Résolution de ftp.ovh.net... 213.186.33.9
Connexion vers ftp.ovh.net|213.186.33.9|:21...connecté.
Ouverture de session en anonymous...Session établie!
==> SYST ... complété. ==> PWD ... complété.
==> TYPE I ... complété. ==> CWD (1) /made-in-ovh/bzImage/3.2.13 ... complété.
==> PASV ... complété. ==> LIST ... complété.

[ <=> ] 2 761 --.-K/s ds 0,001s

2013-03-13 23:28:15 (4,74 MB/s) - «.listing» sauvegardé [2761]

«.listing» détruit.
--2013-03-13 23:28:15-- ftp://ftp.ovh.net/made-in-ovh/bzImag...xx-std-ipv6-64
=> «System.map-3.2.13-xxxx-std-ipv6-64»
==> CWD n'est pas requis.
==> PASV ... complété. ==> RETR System.map-3.2.13-xxxx-std-ipv6-64 ... complété.
Longueur: 2208887 (2,1M)

100%[================================================== ==>] 2 208 887 7,02M/s ds 0,3s

2013-03-13 23:28:15 (7,02 MB/s) - «System.map-3.2.13-xxxx-std-ipv6-64» sauvegardé [2208887]

--2013-03-13 23:28:15-- ftp://ftp.ovh.net/made-in-ovh/bzImag...xx-std-ipv6-64
=> «bzImage-3.2.13-xxxx-std-ipv6-64»
==> CWD n'est pas requis.
==> PASV ... complété. ==> RETR bzImage-3.2.13-xxxx-std-ipv6-64 ... complété.
Longueur: 6046128 (5,8M)

100%[================================================== ==>] 6 046 128 10,8M/s ds 0,5s

2013-03-13 23:28:15 (10,8 MB/s) - «bzImage-3.2.13-xxxx-std-ipv6-64» sauvegardé [6046128]

[root@ks368088 boot]# ls -lrt
total 22078
drwxr-xr-x 3 root root 1024 8 juil. 2011 efi
-rw-r--r-- 1 root root 2208887 28 mars 2012 System.map-3.2.13-xxxx-std-ipv6-64
-rw-r--r-- 1 root root 6046128 28 mars 2012 bzImage-3.2.13-xxxx-std-ipv6-64
-rw-r--r-- 1 1002 1002 2206409 2 avril 2012 System.map-3.2.13-xxxx-grs-ipv6-64
-rw-r--r-- 1 1002 1002 6134704 2 avril 2012 bzImage-3.2.13-xxxx-grs-ipv6-64
drwx------ 2 root root 12288 13 mars 22:19 lost+found
drwxr-xr-x 2 root root 1024 13 mars 22:26 grub
-rw-r--r-- 1 root root 5995368 13 mars 23:24 initramfs.3.2.13-grsec-xxxx-grs-ipv6-64.img
[root@ks368088 boot]#

Modification du fichier grub.conf pour utiliser le nouveau kernel et lancer l’image initramfs. Ci-dessous le fichier /boot/grub/grub.conf tel qu'il apparaît après la modification :

[root@ks368088 grub]# cat grub.conf
default=0
timeout=5

title linux centos6_64
kernel /bzImage-3.2.13-xxxx-std-ipv6-64 root=/dev/md6 ro
initrd /initramfs.3.2.13-grsec-xxxx-grs-ipv6-64.img
root (hd0,0)
[root@ks368088 grub]#

Lancement de «init 6» pour vérifier que le boot fonctionne. A la fin de ce reboot, le système qui démarrera sera toujours celui qui est sur "/dev/md6". L'objectif de ce reboot est de s'assurer que l'activation des volumes logiques est bien effectif.

Suite au boot, lancer un "grep dracut /var/log/messages". Vous devriez trouver des informations sur le statut des LV. Le statut "inactive" ne doit pas vous inquiéter, il s'agit du statut au début du script que nous avons inséré dans l'image lancée via l'initrd :

[root@ks368088 log]# grep dracut messages | head -30
Mar 13 23:17:51 ks368088 yum[3233]: Installed: dracut-004-303.el6.noarch
Mar 13 23:40:32 ks368088 kernel: dracut: dracut-004-303.el6
Mar 13 23:40:32 ks368088 kernel: dracut: Starting plymouth daemon
Mar 13 23:40:32 ks368088 kernel: dracut: PV /dev/md7 VG vg_backup lvm2 [848.04 GiB / 829.04 GiB free]
Mar 13 23:40:32 ks368088 kernel: dracut: Total: 1 [848.04 GiB] / in use: 1 [848.04 GiB] / in no VG: 0 [0 ]
Mar 13 23:40:32 ks368088 kernel: dracut: Reading all physical volumes. This may take a while...
Mar 13 23:40:32 ks368088 kernel: dracut: Found volume group "vg_backup" using metadata type lvm2
Mar 13 23:40:32 ks368088 kernel: dracut: inactive '/dev/vg_backup/all_initial' [1.00 GiB] inherit
Mar 13 23:40:32 ks368088 kernel: dracut: inactive '/dev/vg_backup/lv_sys' [8.00 GiB] inherit
Mar 13 23:40:32 ks368088 kernel: dracut: inactive '/dev/vg_backup/lv_tmp' [2.00 GiB] inherit
Mar 13 23:40:32 ks368088 kernel: dracut: inactive '/dev/vg_backup/lv_var' [4.00 GiB] inherit
Mar 13 23:40:32 ks368088 kernel: dracut: inactive '/dev/vg_backup/lv_home' [4.00 GiB] inherit
Mar 13 23:40:32 ks368088 kernel: dracut: 5 logical volume(s) in volume group "vg_backup" now active
Mar 13 23:40:32 ks368088 kernel: dracut: --- Logical volume ---
Mar 13 23:40:32 ks368088 kernel: dracut: LV Path /dev/vg_backup/all_initial
Mar 13 23:40:32 ks368088 kernel: dracut: LV Name all_initial
Mar 13 23:40:32 ks368088 kernel: dracut: VG Name vg_backup
Mar 13 23:40:32 ks368088 kernel: dracut: LV UUID IFmIce-P2Lr-sskA-LsdR-xwo9-rDSa-5dV3mI
Mar 13 23:40:32 ks368088 kernel: dracut: LV Write Access read/write
Mar 13 23:40:32 ks368088 kernel: dracut: LV Creation host, time rescue.ovh.net, 2013-03-13 21:41:05 +0000
Mar 13 23:40:32 ks368088 kernel: dracut: LV Status available
Mar 13 23:40:32 ks368088 kernel: dracut: # open 0
Mar 13 23:40:32 ks368088 kernel: dracut: LV Size 1.00 GiB
Mar 13 23:40:32 ks368088 kernel: dracut: Current LE 256
Mar 13 23:40:32 ks368088 kernel: dracut: Segments 1
Mar 13 23:40:32 ks368088 kernel: dracut: Allocation inherit
Mar 13 23:40:32 ks368088 kernel: dracut: Read ahead sectors auto
Mar 13 23:40:32 ks368088 kernel: dracut: - currently set to 256
Mar 13 23:40:32 ks368088 kernel: dracut: Block device 253:0
Mar 13 23:40:32 ks368088 kernel: dracut:
[root@ks368088 log]#

On constate donc que l’image initramfs créée a permis d’activer les LV avant de monter le rootfs. On peut donc chercher à booter sereinement sur le rootfs hébergé sur LVM !


IV. Mise en place du boot sur les LV.
Il faut modifier le fichier /etc/fstab du LV /dev/vg_backup/lv_sys pour que soient montés correctement tous les FS lors de la séquence de boot (je l'ai fait en mode rescue, mais ce n'est pas une nécessité...) :

root@rescue:/mnt/etc# diff fstab fstab.initial
2c2
< /dev/vg_backup/lv_sys / ext4 errors=remount-ro 0 1
---
> /dev/md6 / ext4 errors=remount-ro 0 1
4,6c4
< /dev/vg_backup/lv_tmp /tmp ext4 defaults 0 1
< /dev/vg_backup/lv_var /var ext4 defaults 0 1
< /dev/vg_backup/lv_home /home ext4 defaults 0 1
---
> /dev/md7 /mnt ext3 defaults 1 2
root@rescue:/mnt/etc#

Ensuite, il faut modifier le fichier grub.conf pour lancer le démarrage depuis /dev/vg_backup/lv_sys

[root@ks368088 grub]# cp -p grub.conf grub.conf.std.md

On édite et ci-dessus le "diff" que cela me génère :

[root@ks368088 grub]# diff grub.conf grub.conf.std.md
5c5
< kernel /bzImage-3.2.13-xxxx-std-ipv6-64 root=/dev/vg_backup/lv_sys ro
---
> kernel /bzImage-3.2.13-xxxx-std-ipv6-64 root=/dev/md6 ro
[root@ks368088 grub]#

On a plus qu’à croiser les doigts : «init 6» ! Pour moi, tout fonctionne. Le boot a bien lieu en s'appuyant sur les volumes LVM.

V. Finition.
Si tout s'est bien déroulé, vous pouvez poursuivre en utilisant "/dev/md6" (qui héberge le système tel qu'il a été créé lors de l'installation via le Manager, mais dont nous n'avons plus besoin) pour y créer un PV, puis un VG, puis les LV que vous voulez. Ensuite, utiliser les données du LV "all_initial" pour y recréé un système "clean".

Les points d'attention :
*Modifier /boot/grub/grub.conf pour rensigner le bon volume sur lequel booter.
*Mettre à jour le fichier /etc/fstab sur ce nouveau système pour monter les bons FS /var, /tmp, ...

Si vous avez un soucis quelquonque, je ne suis en aucun cas responsable et ne suis pas tenue de vous aider non plus, de faire un support ou je ne sais quoi. En cas de problème, je vous invite cependant à postez ici