Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[Résolu] copie système sur SSD

fgland

Bonjour,

ayant récupéré un SSD, j'aimerais votre avis sur la façon dont je l'ai utilisé.

Ayant une F25 à jour, avec /boot, /, swap, /home, /donnees sur un sata 1to, je ne voulais pas refaire une installation complète.
Ce que j'ai fait
-créé une partition sur le SSD
-copié / sur le SSD à partir d'un livecd
-redémarré sur le sata
-modifié le fstab du SSD pour changer l'UUID de /
-grub2-mkconfig -o /boot/grub2/grub.cfg, il a bien détecté la F25 du SSD
-corrigé /boot/grub2/grub.cfg car il a laissé l'UUID / du sata
-redémarré
et tout marche bien

Mais qu'en est-il de l'optimisation du système pour un SSD ? elle se fait à l'installation ou à la volée au démarrage ?

Merci
Gérard

VINDICATORs

Tu peux la faire après, regarde la documentation sur les SSD ou recherche sur le forum on en avait parlé à un moment (je ne sais pas si les modifications sont reportés dans la doc).

Sinon de base ça marche déjà très bien.

winmandrake

Mais qu'en est-il de l'optimisation du système pour un SSD ?

L'optimisation d'un SSD est faite automatiquement : https://wiki.archlinux.fr/SSD#Maximiser_les_performances_d.27un_SSD

remi

C'est là que LVM c'est quand même vachement bien.... pvmove.... même pas besoin de redémarrer.

Et il y en a qui utilisent encore les simples partitions ? la techno du XXème siècle ?

Renault

remi wrote: Et il y en a qui utilisent encore les simples partitions ? la techno du XXème siècle ?

Il y en a encore qui utilisent LVM ? La techno des années 2000. Aujourd'hui c'est Btrfs qui est moderne, non ? 😉

nouvo09

Renault wrote:
remi wrote: Et il y en a qui utilisent encore les simples partitions ? la techno du XXème siècle ?
Il y en a encore qui utilisent LVM ?

YESSSSSSSSSSSSSS !!!

winmandrake

remi wrote:C'est là que LVM c'est quand même vachement bien.... pvmove.... même pas besoin de redémarrer.

Et il y en a qui utilisent encore les simples partitions ? la techno du XXème siècle ?

Oui, moi car si tu veux utiliser plusieurs os, tu peux facilement naviguer parmi tes partitions.

VINDICATORs

Perso cela dépend des usages et du besoin.

Pour le moment je ne me prend pas trop la tête, un partitionnement simple vu que j'utilise 1 disque pour presque 1 usage...

fgland

Les manipulations de partitions sont tellement rares pour moi que je n'ai jamais pris le temps de regarder lvm. Surtout que c'est le genre de manipulation qui n'admet pas l'erreur !
@winmandrake : j'ai ajouté noatime à ma partition, merci.
Avant de mettre ce sujet en résolu, il reste un point : quand je régénère le /boot avec grub2-mkconfig -o /boot/grub2/grub.cfg, dont voici un extrait pour le disque Sata qui n'est pas le disque en service :

menuentry 'Fedora release 25 (Twenty Five) (on /dev/sdb3)' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-183f82a3-207e-4bed-a506-1876fe28b740' {
	insmod part_msdos
	insmod ext2
	set root='hd1,msdos1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1  e567c68c-d174-4cb5-a1c0-839e82c8647c
	else
	  search --no-floppy --fs-uuid --set=root e567c68c-d174-4cb5-a1c0-839e82c8647c
	fi
	linux16 /vmlinuz-4.9.5-200.fc25.x86_64 root=UUID=35680859-d413-4ab7-81cb-6dfd6a542218 ro rhgb quiet
	initrd16 /initramfs-4.9.5-200.fc25.x86_64.img

Il ne me parraît pas normal que l'UUID de la ligne linux16 /vmlinuzxxx (/ du SSD) soit différent de celui de la première ligne (/ du SATA).
Cela vient-il de mes manipulations ? un fichier à modifier quelque part ?
Merci
Gérard

Fifi

Non, ce n'est pas normal. Ce doit être le même UUID.
Si la commande blkid te donne 35680859-d413-4ab7-81cb-6dfd6a542218, tu dois avoir la même valeur partout.
Normalement on ne modifie pas le grub.cfg, mais si tu changes 183f82a3-207e-4bed-a506-1876fe28b740 par 35680859-d413-4ab7-81cb-6dfd6a542218 et que tu régénère, par après,le fichier avec grub2-mkconfig -o /boot/grub2/grub.cfg, la valeur est elle modifiée à la première ligne ou est ce que ça n'est pas modifié ?

D'ailleurs, /dev/sdb3 ne correspond pas non plus à root=hd1,msdos1

C'est bizarre, ton truc.

nouvo09

Désigne tes partitions par leur label, ça évitera de te prendra la tête sur ce genre de question.

Mets dans grub2.cfg la directive root=LABEL=/F25 ou autre

le jour où tu changes la partition tu n'as qu'à modifier ce label avec e2label.

ça fonctionne aussi dans fstab

fgland

Voici mes disques avec leur UUID

Disque /dev/sda : 111,8 GiB, 120034123776 octets, 234441648 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x247d4122

Périphérique Amorçage     Début       Fin  Secteurs Taille Id Type
/dev/sda1                  2048 116754431 116752384  55,7G 83 Linux.................35680859-d413-4ab7-81cb-6dfd6a542218
/dev/sda2             116754432 234440703 117686272  56,1G 83 Linux


Disque /dev/sdb : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x475bc34b

Périphérique Amorçage     Début        Fin   Secteurs Taille Id Type
/dev/sdb1    *             2048     976895     974848   476M 83 Linux..........................................................e567c68c-d174-4cb5-a1c0-839e82c8647c
/dev/sdb2                976896  196288511  195311616  93,1G 83 Linux...................................................04d39672-7e40-43d5-8cba-7a0a3e273fa8
/dev/sdb3             196288512  293943295   97654784  46,6G 83 Linux.................................................183f82a3-207e-4bed-a506-1876fe28b740
/dev/sdb4             293943296 1953523711 1659580416 791,4G  5 Étendue
/dev/sdb5             293945344  309569535   15624192   7,5G 82 partition d'échange Linux / Solaris...1b5331b1-3279-4ce8-963e-1ae5bd3e440b
/dev/sdb6             309571584 1953523711 1643952128 783,9G 83 Linux.............................................57181ed0-c687-47e3-9201-b2cef4693f98

et le grub.cfg généré

entrée pour le sda (SSD)
menuentry 'Fedora (4.9.5-200.fc25.x86_64) 25 (Twenty Five)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.9.5-200.fc25.x86_64-advanced-35680859-d413-4ab7-81cb-6dfd6a542218' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='hd1,msdos1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1  e567c68c-d174-4cb5-a1c0-839e82c8647c
	else
	  search --no-floppy --fs-uuid --set=root e567c68c-d174-4cb5-a1c0-839e82c8647c
	fi
	linux16 /vmlinuz-4.9.5-200.fc25.x86_64 root=UUID=35680859-d413-4ab7-81cb-6dfd6a542218 ro rhgb quiet 
	initrd16 /initramfs-4.9.5-200.fc25.x86_64.img

entrée pour le sdb
### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Fedora release 25 (Twenty Five) (on /dev/sdb3)' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-183f82a3-207e-4bed-a506-1876fe28b740' {
	insmod part_msdos
	insmod ext2
	set root='hd1,msdos1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1  e567c68c-d174-4cb5-a1c0-839e82c8647c
	else
	  search --no-floppy --fs-uuid --set=root e567c68c-d174-4cb5-a1c0-839e82c8647c
	fi
	linux16 /vmlinuz-4.9.5-200.fc25.x86_64 root=UUID=35680859-d413-4ab7-81cb-6dfd6a542218 ro rhgb quiet
	initrd16 /initramfs-4.9.5-200.fc25.x86_64.img
}

Sur quoi se base os-prober ? sur le /etc/fstab du système détecté ?

fstab de sda1
UUID=35680859-d413-4ab7-81cb-6dfd6a542218 /                       xfs     defaults,noatime 0 0
UUID=e567c68c-d174-4cb5-a1c0-839e82c8647c /boot                   ext4    defaults        1 2
UUID=57181ed0-c687-47e3-9201-b2cef4693f98 /donnees                xfs     defaults        0 2
UUID=04d39672-7e40-43d5-8cba-7a0a3e273fa8 /home                   xfs     defaults        0 2
UUID=1b5331b1-3279-4ce8-963e-1ae5bd3e440b swap                    swap    defaults        0 0

fstab de sdb3
UUID=183f82a3-207e-4bed-a506-1876fe28b740 /                       xfs     defaults        0 0
UUID=e567c68c-d174-4cb5-a1c0-839e82c8647c /boot                   ext4    defaults        1 2
UUID=57181ed0-c687-47e3-9201-b2cef4693f98 /donnees                xfs     defaults        0 2
UUID=04d39672-7e40-43d5-8cba-7a0a3e273fa8 /home                   xfs     defaults        0 2
UUID=1b5331b1-3279-4ce8-963e-1ae5bd3e440b swap                    swap    defaults        0 0

Merci
Gérard

nouvo09

Je pense que cet article est susceptible de t'intéresser:

https://opensource.com/article/17/1/solid-state-drives-linux-enabling-trim-ssds?sc_cid=70160000001206iAAA

fgland

@nouvo09 ce que j'y vois surtout est qu'on recommande un format ext4 alors que je suis en xfs.
Cela a-t-il une incidence ?
Merci
Gérard

winmandrake

Ce que tu as fait : création de partition sur ton ssd, puis copie des données.
En créant tes partitions, le système a créer un UUID pour chaque partition de manière unique. (https://fr.wikipedia.org/wiki/Universal_Unique_Identifier)

Donc, ton fstab est bon, puisque tu as bien ton UUID de ton ssd bien renseignée.

fgland

winmandrake wrote: Donc, ton fstab est bon, puisque tu as bien ton UUID de ton ssd bien renseignée.

normal puisque c'est moi qui l'ai modifié manuellement la première fois mais ce qui est moins normal, c'est le grub.cfg généré. Je m'en suis rendu compte car au premier démarrage sur le SSD, il est parti sur le DD
Gérard

nouvo09

Parce que tu as d abord créé les partitions, fait un mkfs, et recopié tes fichiers.

Le mkfs donne un nouveau numéro UUID.

winmandrake

fgland wrote:
winmandrake wrote: Donc, ton fstab est bon, puisque tu as bien ton UUID de ton ssd bien renseignée.
normal puisque c'est moi qui l'ai modifié manuellement la première fois mais ce qui est moins normal, c'est le grub.cfg généré. Je m'en suis rendu compte car au premier démarrage sur le SSD, il est parti sur le DD
Gérard

Alors, enlève les lignes

fstab de sdb3
UUID=183f82a3-207e-4bed-a506-1876fe28b740 /                       xfs     defaults        0 0
UUID=e567c68c-d174-4cb5-a1c0-839e82c8647c /boot                   ext4    defaults        1 2
UUID=57181ed0-c687-47e3-9201-b2cef4693f98 /donnees                xfs     defaults        0 2
UUID=04d39672-7e40-43d5-8cba-7a0a3e273fa8 /home                   xfs     defaults        0 2
UUID=1b5331b1-3279-4ce8-963e-1ae5bd3e440b swap                    swap    defaults        0 0

Regénère grub et reboot. Tu devrais utiliser sans problème ton ssd.

fgland

je crois qu'on va s'en tenir là car on s'emmêle les pinceaux !
Je n'ai pas de problème pour l'utilisation du SSD mais je comptais garder la possibilité de démarrer sur l'un ou sur l'autre et là ce n'est possible que si je corrige la ligne linux16 /vmlinuzxxx du deuxième disque.
Mais c'est un détail
Merci
Gérard