Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Mot-clefs : SSD

Migration vers boot express card SSD

Frédéric Thouin

Quel bonne nouvelle de voir que le kmod-staging était de retour pour ma fedora 15 et donc le module kernel phison. Celui-ci me permet enfin d'utiliser mon expresscard verbatim SSD 16Go. Et là l'idée me prends de migrer ma partition racine (20Go, ocupé 9.3Go) qui est sur mon HDD SATA 5200rpm 500Go vers l'express card.

Problématique

Mon DELL Studio 1737 ne reconnait pas mon expresscard comme périphérique bootable, donc grub ne le voit pas non plus. Mon ExpressCard SSD demande obligatoirement un module kernel spécifique ( phison ) contenu dans les kmod-staging.

Etat des lieux

voici actuelement la séquance de boot de mon system : grub :

title Fedora (2.6.40.3-0.fc15.x86_64)
        root (hd0,2)
        kernel /boot/vmlinuz-2.6.40.3-0.fc15.x86_64 ro root=UUID=d5cb1ae8-748b-4af6-94cb-92188effabb7 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=fr-latin9 rhgb quiet
        initrd /boot/initramfs-2.6.40.3-0.fc15.x86_64.img
title Fedora (2.6.40-4.fc15.x86_64)
        root (hd0,2)

grub récupère le kernel et initramfs sur la partition /dev/sda3.

Principe du futur boot

Utilisé la partition STATA /dev/sda3 qui contient grub et les fichiers du kernel comme partition de boot utiliser pour grub et le chargement du noyau et indiquer où est la nouvelle racine du systeme. A la fin du boot la partition /dev/sda3 ne sera pas montée.

Préparation de l'enviroment de travail

Pour bien faire il me faut un live USB qui contient le module phison.

Avec l'aide du soft : Fedora LiveUSB creator je crée donc une distrib fedora 15 avec une persistance des données.

Je boot dessus et j'intègre les dépôts RPM-fusion afin d'installer le kmod-staging.

Hop cela installe en même temps le dernier kernel, et à partir de maintenant le module phison est monté quand le ssd est présent au démarage.

Génaration de la racine SSD

Reboot sur liveUSB et préparation de la futur racine :

une fois booté sur le liveUSB je monte la racine SATA ( /dev/sda3 ) dans /source, et la futur racine SSD ( /dev/sdc1 ) dans /dest

Copie de la racine

cp -a /source/* /dest

Préparation au reboot

INITRD

Là un point important qu'il faut bien prendre en compte est que l'image initramfs-2.6.40.3-0.fc15.x86_64.img actuelle placer sur /dev/sda3 ne contient pas le module phison, donc de base le boot du kernel ne peut pas voir l'expressCard. Il faut donc créer un initramfs avec le module phison. Biensur cette image devra etre dans le répertoire /boot de /dev/sda3 ( actuelement monté dans /source)

 mkinitrd --preload phison -f /source/boot/initramfs-2.6.40.3-0.fc15.x86_64ssd.img 2.6.40.3-0.fc15.x86_64

Cette commande est donc composé de :

--preload phison : indique qu'un module complémentaire doit etre intégré à l'image.

-f /source/boot/initramfs-2.6.40.3-0.fc15.x86_64ssd.img : indique le nom de l'image à créer

2.6.40.3-0.fc15.x86_64 : indique la version du kernel à utiliser pour générer l'initrd.

Nous somme donc avec une image initrd contenant le module phison, et une image ne contenant pas ce module.

Je rajoute donc une nouvelle ligne dans le grub.conf de la partition /dev/sda3 (/source/boot/grub.conf) :

title Fedora SSD (2.6.40.3-0.fc15.x86_64)
        root (hd0,2)
        kernel /boot/vmlinuz-2.6.40.3-0.fc15.x86_64 ro root=UUID=6530d8a4-7406-4163-9735-64c4b9175b83 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=fr-latin9 rhgb quiet
        initrd /boot/initramfs-2.6.40.3-0.fc15.x86_64ssd.img

J'indique donc à grub que ses fichiers seront du hd0,2 (/dev/sda3) et que la racine du système n'est plus sur UUID du /dev/sda3, mais sur l'UUID de l'expresscard (/dev/sdb1).

Et biensur je lui dis d'utiliser le initrd contenant le module phison ( /boot/initramfs-2.6.40.3-0.fc15.x86_64ssd.img ).

FSTAB

Il faudra bien-sur modifier le fstab de la nouvelle racine ( actuellement monter dans /dest/etc/fstab) et changer l'UUID de /dev/sda3 pour celui de /dev/sdc1.

UUID=6530d8a4-7406-4163-9735-64c4b9175b83 /                       auto    defaults        1 1

SELINUX

Puis qu'on a effectué une simple copie de la racine SATA vers la racine SSD il faut obligatoirement préparer le premier boot en SSD pour que SELINUX relabèlise les fichiers de la nouvelle racine.

Dans le cas contraire le système de démarrera pas car SELINUX refusera de donner accès aux fichiers système ( une solution par très propre est de rajouter selinux=0 dans la ligne du kernel dans grub.conf A NE PAS FAIRE).

Pour cela il faut créer un fichier .autorelabel à la racine du du futur filesystem racine. donc ici :

touch /dest/.autorelabel

Lors du boot, selinux voyant se fichier, il tentera de relabéliser le filesystem, cela peut prendre un certain temps, et dans mon cas j'ai du rebooter 2 fois pour que la relabélisation soit complète.

résumer

On a donc copier la racine sur le ssd, générer un initrd spécifique avec le module phison ( prise en charge de l'expresscard) copier dans le /boot (de la partition SATA), ajouter une entré dans le grub.conf (de la partition SATA), modifier le fstab ( de la partition SSD), préparé la racine SSD pour que selinux relabélise le file system)

REBOOT

C'est le moment de prier crom, car on va rebooté le système. au reboot on indique bien à grub de booter sur l'entrée Fedora SSD (2.6.40.3-0.fc15.x86_64) et la magie s'opère.

Et le futur ?

La dificulté de tout cela sera dans les mise à jours du kernel (c'est pas tout les jours), et de grub ( c'est encore plus rare).

Pour les mise à jours du kernel il ne faudra simplement pas oublier de régénérer un initrd pour la nouvelle version de kernel, copie le nouveau kernel et l'initrd_ssd dans le repertoire /boot de la partition /dev/sad1. et modifier le grub.conf dans la partition /dev/sda3.

Pour les mise a jours de grub, je vois pas trop, à la limite je ne le metterais pas à jours.

Conclusion

temps de boot

voila mon temps de boot avant :

Sep  1 08:12:35 dellp2 systemd[1]: Startup finished in 1s 457ms 538us (kernel) + 7s 17ms 520us (initrd) + 38s 393ms 430us (userspace) = 46s 868ms 488us.

et après :

Sep  1 11:06:29 dellp2 systemd[1]: Startup finished in 1s 415ms 263us (kernel) + 11s 357ms 679us (initrd) + 20s 101ms 712us (userspace) = 32s 874ms 654us.

soit un gain de 14secondes. ce qui est bien mais pas top.

vitesse des disques

hdparm -Tt /dev/sda
/dev/sda:
 Timing cached reads:   3204 MB in  2.00 seconds = 1603.48 MB/sec
 Timing buffered disk reads: 224 MB in  3.04 seconds =  73.71 MB/sec

hdparm -Tt /dev/sdb
/dev/sdb:
 Timing cached reads:   3312 MB in  2.00 seconds = 1657.42 MB/sec
 Timing buffered disk reads: 328 MB in  3.02 seconds = 108.74 MB/sec

Soit un gain de 35MB/sec ce qui là n'est pas négligeable, et l'ouverture des applications est réellement plus rapide.

Pour rappelle l'expresscard Verbatim SSD 16Go sur mon pc est conecté en PCIexpress 1X !!

Donc cela m'ouvre la porte vers l'envie d'acheter un disque SATA SSD qui là donnera bien plus de performances.

Rajouter un disque (SSD) dans un groupe de volumes LVM

Guillaume Kulakowski

Je viens de profiter des soldes pour muscler une fois de plus ma station de travail. enterprise passe donc à 8Go de RAM mais surtout possède à présent 64Go de disque SSD en SATA III. L'occasion pour moi de faire un article sur comment rajouter un disque dans un groupe de volumes et comment y déplacer les partitions qui vont bien.

Remarques :

  • Je possède 2 groupes de volumes : VG00 et VG01, dans cette article VG01 ne rentre pas en compte. Je l'ignore donc volontairement.
  • J'utilise system-config-lvm pour illustrer mes propos. Bien évidement vous pouvez passer par gparted et system-config-lvm pour faire tout ce que je décris ici, mais c'est quand même moins sport et puis le jour où vous administrerez un serveur j'espère que vous n'aurez pas ces GUI sous la main !
  • Merci à Remi Collet pour ses conseils sur le LVM et pour son article LVM c'est quand même bien qui m'a servi de base.
  • Pour ceux qui ne connaissent que Windows, ils vont avoir un choc : avec LVM on peut déplacer une partition d'un disque dur vers un autre à chaud et cela même si la partition est la partition système !

Préambule

Ma carte mère gère le SATA III, j'ai donc choisi un disque SSD SATA III de la marque Crucial. Lors du premier boot, je n'ai pas trouvé mon nouveau disque. Pour cela j'ai du passer l'option "Marvell Controller" de IDE vers AHCI, si vous rencontrez le même problème je vous invite à lire le mode d'emploi de votre carte mère.

Partitionnement du disque

Maintenant que le disque dur est visible il faut le partitionner. La Commande fdisk -l me retourne moult informations mais surtout m'indique que mon disque se prénomme /dev/sda. Je vais donc le partitionner en 2 :

  • 512Mo pour le /boot,
  • le reste pour mon LVM.

Il est possible de faire ceci avec parted ou même gparted, je me le suis fait à l'ancienne (fdisk) :

root@enterprise ~> fdisk /dev/sda
Le périphérique ne contient pas une table de partitions DOS ou Sun, SGI, OSF valide
Création d'une nouvelle étiquette DOS avec id de disque 0x51d8c6f2.
Les modifications restent en mémoire jusqu'à ce que vous les écriviez.
Après quoi, bien sûr, le contenu précédent sera irrécupérable.
 
AVERTISSEMENT: fanion 0x0000 non valide dans la table de partitions 4, sera corrigé par w(écriture)
 
Commande (m pour l'aide): m
Commande d'action
   a   bascule le fanion d'amorce
   b   éditer l'étiquette BSD du disque
   c   basculer le fanion de compatibilité DOS
   d   supprimer la partition
   l   lister les types de partitions connues
   m   afficher ce menu
   n   ajouter une nouvelle partition
   o   créer une nouvelle table vide de partitions DOS
   p   afficher la table de partitions
   q   quitter sans enregistrer les changements
   s   créer une nouvelle étiquette vide pour disque de type Sun
   t   modifier l'id de système de fichiers d'une partition
   u   modifier les unités d'affichage/saisie
   v   vérifier la table de partitions
   w   écrire la table sur le disque et quitter
   x   fonctions avancées (pour experts seulement)
 
Commande (m pour l'aide): n
Commande d'action
   e   étendue
   p   partition primaire (1-4)
p
Numéro de partition (1-4, par défaut 1): 
Premier secteur (2048-125045423, par défaut 2048): 
Utilisation de la valeur par défaut 2048
Dernier secteur, +secteurs or +taille{K,M,G} (2048-125045423, par défaut 125045423): +512M
 
Commande (m pour l'aide): n
Commande d'action
   e   étendue
   p   partition primaire (1-4)
p
Numéro de partition (1-4, par défaut 2): 
Utilisation de la valeur par défaut 2
Premier secteur (1050624-125045423, par défaut 1050624): 
Utilisation de la valeur par défaut 1050624
Dernier secteur, +secteurs or +taille{K,M,G} (1050624-125045423, par défaut 125045423): 
Utilisation de la valeur par défaut 125045423
 
Commande (m pour l'aide): w
La table de partitions a été altérée!
 
Appel de ioctl() pour relire la table de partitions.
Synchronisation des disques.

A ce moment j'ai donc 1 groupe de volume (VG00) étalé sur 1 volume physique (/dev/sdb2) : LVM : 1 VG pour 1 PV

La prochaine étape sera donc de rajouter mon disque SSD à VG00.

Création du volume physique et affectation au groupe de volumes VG00

Nous allons créer un volume physique à partir de /dev/sda2 et le rajouter au groupe VG00 :

root@enterprise ~> pvcreate /dev/sda2
  Physical volume "/dev/sda2" successfully created
root@enterprise ~> vgextend VG00 /dev/sda2
  Volume group "VG00" successfully extended

A cette instant j'ai 1 groupe de volumes (VG00) réparti sur 2 volumes physique (/dev/sda2, /dev/sdb2) : LVM : 1 VG pour 2 PV

Déplacement des partitions systèmes sur le nouveau PV

Le SSD c'est bien mais c'est cher ! Comptez environs 120€ pour 64Go. A ce prix là on ne peut pas avoir un PC 100% SSD. Nous allons donc déplacer sur le SSD les partitions systèmes qui doivent être les plus rapides :

  • Le système (LV_root),
  • le swap (LV_swap),
  • le tmp (LV_tmp),
root@enterprise ~> pvmove -v -n LV_root /dev/sdb2 /dev/sda2
    Finding volume group "VG00"
    Archiving volume group "VG00" metadata (seqno 37).
    Creating logical volume pvmove0
    Moving 640 extents of logical volume VG00/LV_root
    Found volume group "VG00"
    activation/volume_list configuration setting not defined, checking only host tags for VG00/LV_root
    Updating volume group metadata
    Found volume group "VG00"
    Found volume group "VG00"
    Suspending VG00-LV_root (253:2) with device flush
    Found volume group "VG00"
    activation/volume_list configuration setting not defined, checking only host tags for VG00/pvmove0
    Creating VG00-pvmove0
    Loading VG00-pvmove0 table (253:7)
    Resuming VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Loading VG00-pvmove0 table (253:7)
    Suppressed VG00-pvmove0 identical table reload.
    Loading VG00-LV_root table (253:2)
    Resuming VG00-LV_root (253:2)
    Creating volume group backup "/etc/lvm/backup/VG00" (seqno 38).
    Checking progress before waiting every 15 seconds
  /dev/sdb2: Moved: 0,2%
  /dev/sdb2: Moved: 4,8%
  /dev/sdb2: Moved: 9,2%
  /dev/sdb2: Moved: 13,9%
  /dev/sdb2: Moved: 18,1%
  /dev/sdb2: Moved: 22,7%
  /dev/sdb2: Moved: 27,3%
  /dev/sdb2: Moved: 31,7%
  /dev/sdb2: Moved: 36,1%
  /dev/sdb2: Moved: 40,5%
  /dev/sdb2: Moved: 45,0%
  /dev/sdb2: Moved: 49,4%
  /dev/sdb2: Moved: 53,6%
  /dev/sdb2: Moved: 58,3%
  /dev/sdb2: Moved: 62,5%
  /dev/sdb2: Moved: 66,4%
  /dev/sdb2: Moved: 70,8%
  /dev/sdb2: Moved: 75,3%
  /dev/sdb2: Moved: 79,7%
  /dev/sdb2: Moved: 83,6%
  /dev/sdb2: Moved: 88,3%
  /dev/sdb2: Moved: 92,7%
  /dev/sdb2: Moved: 96,6%
  /dev/sdb2: Moved: 100,0%
    Found volume group "VG00"
    Found volume group "VG00"
    Loading VG00-LV_root table (253:2)
    Suspending VG00-LV_root (253:2) with device flush
    Suspending VG00-pvmove0 (253:7) with device flush
    Found volume group "VG00"
    Found volume group "VG00"
    Found volume group "VG00"
    Resuming VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Resuming VG00-LV_root (253:2)
    Found volume group "VG00"
    Removing VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Removing temporary pvmove LV
    Writing out final volume group after pvmove
    Creating volume group backup "/etc/lvm/backup/VG00" (seqno 40).

LVM : LV_root sur le disque SSD

root@enterprise ~> pvmove -v -n LV_swap /dev/sdb2 /dev/sda2
    Finding volume group "VG00"
    Archiving volume group "VG00" metadata (seqno 40).
    Creating logical volume pvmove0
    Moving 64 extents of logical volume VG00/LV_swap
    Found volume group "VG00"
    activation/volume_list configuration setting not defined, checking only host tags for VG00/LV_swap
    Updating volume group metadata
    Found volume group "VG00"
    Found volume group "VG00"
    Suspending VG00-LV_swap (253:6) with device flush
    Found volume group "VG00"
    activation/volume_list configuration setting not defined, checking only host tags for VG00/pvmove0
    Creating VG00-pvmove0
    Loading VG00-pvmove0 table (253:7)
    Resuming VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Loading VG00-pvmove0 table (253:7)
    Suppressed VG00-pvmove0 identical table reload.
    Loading VG00-LV_swap table (253:6)
    Resuming VG00-LV_swap (253:6)
    Creating volume group backup "/etc/lvm/backup/VG00" (seqno 41).
    Checking progress before waiting every 15 seconds
  /dev/sdb2: Moved: 0,0%
  /dev/sdb2: Moved: 43,8%
  /dev/sdb2: Moved: 87,5%
  /dev/sdb2: Moved: 100,0%
    Found volume group "VG00"
    Found volume group "VG00"
    Loading VG00-LV_swap table (253:6)
    Suspending VG00-LV_swap (253:6) with device flush
    Suspending VG00-pvmove0 (253:7) with device flush
    Found volume group "VG00"
    Found volume group "VG00"
    Found volume group "VG00"
    Resuming VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Resuming VG00-LV_swap (253:6)
    Found volume group "VG00"
    Removing VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Removing temporary pvmove LV
    Writing out final volume group after pvmove
    Creating volume group backup "/etc/lvm/backup/VG00" (seqno 43).
root@enterprise ~> pvmove -v -n LV_tmp /dev/sdb2 /dev/sda2
    Finding volume group "VG00"
    Archiving volume group "VG00" metadata (seqno 43).
    Creating logical volume pvmove0
    Moving 64 extents of logical volume VG00/LV_tmp
    Found volume group "VG00"
    activation/volume_list configuration setting not defined, checking only host tags for VG00/LV_tmp
    Updating volume group metadata
    Found volume group "VG00"
    Found volume group "VG00"
    Suspending VG00-LV_tmp (253:5) with device flush
    Found volume group "VG00"
    activation/volume_list configuration setting not defined, checking only host tags for VG00/pvmove0
    Creating VG00-pvmove0
    Loading VG00-pvmove0 table (253:7)
    Resuming VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Loading VG00-pvmove0 table (253:7)
    Suppressed VG00-pvmove0 identical table reload.
    Loading VG00-LV_tmp table (253:5)
    Resuming VG00-LV_tmp (253:5)
    Creating volume group backup "/etc/lvm/backup/VG00" (seqno 44).
    Checking progress before waiting every 15 seconds
  /dev/sdb2: Moved: 0,0%
  /dev/sdb2: Moved: 40,6%
  /dev/sdb2: Moved: 84,4%
  /dev/sdb2: Moved: 100,0%
    Found volume group "VG00"
    Found volume group "VG00"
    Loading VG00-LV_tmp table (253:5)
    Suspending VG00-LV_tmp (253:5) with device flush
    Suspending VG00-pvmove0 (253:7) with device flush
    Found volume group "VG00"
    Found volume group "VG00"
    Found volume group "VG00"
    Resuming VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Resuming VG00-LV_tmp (253:5)
    Found volume group "VG00"
    Removing VG00-pvmove0 (253:7)
    Found volume group "VG00"
    Removing temporary pvmove LV
    Writing out final volume group after pvmove
    Creating volume group backup "/etc/lvm/backup/VG00" (seqno 46).

Maintnant j'ai donc 2 PV, l'un avec mes partitions de stockage (le disque dur), l'autre avec les partitions systèmes (le SSD) : VG00_PV_SSD.png VG00_dd.png

Déplacer le boot sur le SSD

Maintenant nous allons déplacer la dernière partition qui n'est pas un LVM puisque c'est le /boot en ext4, pour ça j'utilise la méthode de Remi :

root@enterprise ~> mke2fs -j -T ext4 -L boot /dev/sda1
root@enterprise ~> mount /dev/sda1 /mnt/tmp
root@enterprise ~> tar cf - -C /boot . | tar xvf - -C /mnt/tmp
root@enterprise ~> umount /mnt/tmp
root@enterprise ~> umount /boot

Ensuite il faut aller modifier le /etc/fstab en mettant à jour le UUID que vous trouverez avec :

root@enterprise ~> ll /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 16 janv. 10:55 10bd9879-81cc-4813-a0a7-4bb33c1a7c5f -> ../../sda1
lrwxrwxrwx 1 root root 10 15 janv. 20:17 128e5cbc-7a29-463a-8710-a2de40b74084 -> ../../dm-1
lrwxrwxrwx 1 root root 10 15 janv. 20:36 240b9e30-190e-48a6-9fcf-0d1edd85d801 -> ../../dm-2
lrwxrwxrwx 1 root root 10 15 janv. 20:40 848181fa-38fd-40e1-87b6-501ac68686fc -> ../../dm-6
lrwxrwxrwx 1 root root 10 15 janv. 20:17 86e1bee2-32d7-4103-b2f8-c654110d5a75 -> ../../dm-4
lrwxrwxrwx 1 root root 10 15 janv. 20:27 b166653c-e4ed-4481-a2b9-81162209696a -> ../../sdb1
lrwxrwxrwx 1 root root 10 15 janv. 20:41 b9665501-2d21-4f0a-af94-cd15ae238d3a -> ../../dm-5
lrwxrwxrwx 1 root root 10 15 janv. 20:17 d776dc2a-174f-46e5-99ca-084caed2da7e -> ../../dm-0
lrwxrwxrwx 1 root root 10 15 janv. 20:17 f6481e9e-a8c5-400c-a35d-4204f4a015d9 -> ../../dm-3

Pour terminer on monte le nouveau boot et on fait un grub-install

root@enterprise ~> mount /booot
root@enterprise ~> grub-install /dev/sda --recheck

Ensuite on récupère l'ancien boot (/dev/sdb1) et on le rajoute à VG00 :

root@enterprise ~> pvcreate /dev/sdb1
  Physical volume "/dev/sdb1" successfully created
root@enterprise ~> vgextend VG00 /dev/sdb1
  Volume group "VG00" successfully extended

Ce qui nous donne à la fin : VG00_final.png