changer de DD

Le
Professeur M
Salut tout le monde !

Pour gagner un peu plus d'espace (stockage de photos qui sont actuellement
sur DD externe et petits montages vidéos) je souhaite changer de DD (80 Go
actuellement pour plus)

actuellement :
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/hdc1 30G 7,8G 21G 28% /
/dev/hdc6 49G 37G 10G 79% /home
/dev/hda5 39G 8,2G 30G 22% /mnt/dos
/dev/hda1 42G 14G 29G 32% /mnt/ntfs

C'est hdc que je veux remplacer.

Ce que je pense faire :

- sauvegarde ;-)
- mettre le nouveau disque sur l'interface usb/ide de mon DD externe
- partitionner (40 - 50 Go pour la racine, le reste pour le future /home)
- copier les fichiers
- installer le nouveau disque sur la nappe IDE.

Est-ce que cela va marcher ? notamment :
- GRUB va-t-il y retrouver ses petits ?
- faudra-t-il modifier /etc/fstab ?
- autre ?

Merci de vos avis et conseils

Méphisto
--
C'est parce que la lumière est plus rapide que le son que certains
ont l'air brillants avant d'avoir l'air con
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #1906078
Professeur Méphisto
wrote in message
- sauvegarde ;-)
- mettre le nouveau disque sur l'interface usb/ide de mon DD externe
- partitionner (40 - 50 Go pour la racine, le reste pour le future /home)
- copier les fichiers
- installer le nouveau disque sur la nappe IDE.


Ça devrait marcher. Attention à bien copier les bons fichiers, en
particulier le /dev caché sous udev.

- GRUB va-t-il y retrouver ses petits ?


Non, il faudra le réinstaller. Le plus simple est de booter sur un Grub
quelconque (cat stage[12] > /dev/usbkey fait une clef USB bootable avec
Grub), et l'utiliser pour lancer la distribution.

- faudra-t-il modifier /etc/fstab ?


Ça dépend si les nouvelles partitions sont exactement les mêmes que les
anciennes.

Professeur M
Le #1906077


- GRUB va-t-il y retrouver ses petits ?


Non, il faudra le réinstaller. Le plus simple est de booter sur un Grub
quelconque (cat stage[12] > /dev/usbkey fait une clef USB bootable avec
Grub), et l'utiliser pour lancer la distribution.



J'oubliais...

si je me souvient bien de mon install (le pb avec linux, c'est que l'on ne
refait pas ça tous les deux mois)... le chargeur de boot est sur hda (le
disque avec un vestige de windows)

Méph'
--
C'est parce que la lumière est plus rapide que le son que certains
ont l'air brillants avant d'avoir l'air con


Nicolas George
Le #1906075
Professeur Méphisto
wrote in message
si je me souvient bien de mon install (le pb avec linux, c'est que l'on ne
refait pas ça tous les deux mois)... le chargeur de boot est sur hda (le
disque avec un vestige de windows)


Ce n'est pas suffisant : le stage1 est sur hda, mais le stage1_5 est
probablement sur hdc. Ce que tu peux essayer de faire, c'est temporairement
installer Grub complètement sur hda. Peut-être un peu technique à faire
proprement, ceci dit.

Professeur M
Le #1906071

Ce n'est pas suffisant : le stage1 est sur hda, mais le stage1_5 est
probablement sur hdc.


ok merci.

Autre question, par rapport à la copie des fichiers :

Je présume qu'il n'y a d'intérêt à essayer à copier que les « vrais »
fichiers. Donc exit /proc et /dev etc. Pourtant, des liens symboliques
existent dans ce bazar (par ex. /dev/cdrom).

Comment vais-je séparer le bon grain de l'ivraie ? Je pense que passer par
un live-CD devrait permettre de faire les choses proprement, mais sinon ?

Méph'
--
C'est parce que la lumière est plus rapide que le son que certains
ont l'air brillants avant d'avoir l'air con

Nicolas George
Le #1906070
Professeur Méphisto
wrote in message
Je présume qu'il n'y a d'intérêt à essayer à copier que les « vrais »
fichiers. Donc exit /proc et /dev etc. Pourtant, des liens symboliques
existent dans ce bazar (par ex. /dev/cdrom).

Comment vais-je séparer le bon grain de l'ivraie ?


Le truc important, c'est de copie un file system, ni plus ni moins. Pour
/home, c'est facile, parce qu'il n'y a normalement rien monté en dessous de
/home. Pour /, c'est plus pénible. Ce que j'ai fait la dernière fois que
j'ai eu à le faire, c'est utiliser un montage lié :

mount -o bind / /mnt/tmp1

On se retrouve avec dans /mnt/tmp1 la même chose que dans /, mais sans tous
les trucs montés par dessus. Il suffit ensuite de faire un bon cp -a, et
c'est fini.

Michel Tatoute
Le #1906069
Professeur Méphisto wrote:


Ce n'est pas suffisant : le stage1 est sur hda, mais le stage1_5 est
probablement sur hdc.


ok merci.

Autre question, par rapport à la copie des fichiers :

Je présume qu'il n'y a d'intérêt à essayer à copier que les « vrais »
fichiers. Donc exit /proc et /dev etc. Pourtant, des liens symboliques
existent dans ce bazar (par ex. /dev/cdrom).



tout ce que je dis là c'est dans l'idee ''sans live cd''

tu as 2 solutions:

a) tu peux faire une copie de l'image de ta partition et utiliser
un 'resizefs' (resize2fs) pour l'adapter à le nouvelle partition plus
grosse.

ou

b) Tu peux copier le contenu de ta partition root (/) sans les montage
(/proc, /sys, /dev etc...) en utilisant mount --bind
par exemple

# mkdir /mnt/old_root_part
# mount --bind / /mnt/old_root_part
# mkdir /mnt/new_root_part
# mount -t <usb partition device> /mnt/new_root_part
# rsync -PHAa /mnt/old_root_part/./ /mnt/new_root_part/./

-- utiliser rsync te permet de faire une reprise sur interruption)
-- les "/./" à la fin sécurise en évitant de créer
-- des /mnt/new_root_part/old_root_part qu'on attend pas


Le probleme dans le a) c'est comment copier le file-system / sans être à
chaud. Il y a plusieurs solutions:
-- tu fais un mount read only de / ... ca doit pouvoir se faire
-- tu passe temporairement en non journalisé (si tu es en ext3) , tu copie à
la sauvage à chaud et tu passe fsck après... puis tu remet tout en
journalisé.

pour la copie de partition, je suppose que partimage t'éviterait de copier
la place libre...

Bon, il reste grub. il ne faudrait pas copier la table de partition avec le
boot secteur. je laisse à d'autre le plaisir de t'expliquer cette partie...

Moi je choisirais b), puis avec --bind je clone /proc, /dev, /sys et
compagnie, (voir df -a) , puis je fais un chroot /mnt/new_root_part, et la
je fignole grub, les identifiants de partition dans fstab... Mais j'aime me
prendre la tête. Ce qui serait vraiment amusant serait de réussir tout sans
jamais redemarer... J'utilise aussi volontier qemu pour booter le nouveau
système, par exemple pour bidouiller le boot secteur... bref je m'amuse.

Comment vais-je séparer le bon grain de l'ivraie ? Je pense que passer par
un live-CD devrait permettre de faire les choses proprement, mais sinon ?

Méph'


Michel.


Michel Tatoute
Le #1906068
Professeur Méphisto wrote:


Ce n'est pas suffisant : le stage1 est sur hda, mais le stage1_5 est
probablement sur hdc.


ok merci.

Autre question, par rapport à la copie des fichiers :

Je présume qu'il n'y a d'intérêt à essayer à copier que les « vrais »
fichiers. Donc exit /proc et /dev etc. Pourtant, des liens symboliques
existent dans ce bazar (par ex. /dev/cdrom).



tout ce que je dis là c'est dans l'idee ''sans live cd''

tu as 2 solutions:

a) tu peux faire une copie de l'image de ta partition et utiliser
un 'resizefs' (resize2fs) pour l'adapter à le nouvelle partition plus
grosse.

ou

b) Tu peux copier le contenu de ta partition root (/) sans les montage
(/proc, /sys, /dev etc...) en utilisant mount --bind
par exemple

# mkdir /mnt/old_root_part
# mount --bind / /mnt/old_root_part
# mkdir /mnt/new_root_part
# mount -t ext2 <usb partition device> /mnt/new_root_part
# rsync -PHAa /mnt/old_root_part/./ /mnt/new_root_part/./

-- utiliser rsync te permet de faire une reprise sur interruption)
-- les "/./" à la fin sécurise en évitant de créer
-- des /mnt/new_root_part/old_root_part qu'on attend pas


Le probleme dans le a) c'est comment copier le file-system / sans être à
chaud. Il y a plusieurs solutions:
-- tu fais un mount read only de / ... ca doit pouvoir se faire
-- tu passe temporairement en non journalisé (si tu es en ext3) , tu copie à
la sauvage à chaud et tu passe fsck après... puis tu remet tout en
journalisé.

pour la copie de partition, je suppose que partimage t'éviterait de copier
la place libre...

Bon, il reste grub. il ne faudrait pas copier la table de partition avec le
boot secteur. je laisse à d'autre le plaisir de t'expliquer cette partie...

Moi je choisirais b), puis avec --bind je clone /proc, /dev, /sys et
compagnie, (voir df -a) , puis je fais un chroot /mnt/new_root_part, et la
je fignole grub, les identifiants de partition dans fstab... Mais j'aime me
prendre la tête. Ce qui serait vraiment amusant serait de réussir tout sans
jamais redemarer... J'utilise aussi volontier qemu pour booter le nouveau
système, par exemple pour bidouiller le boot secteur... bref je m'amuse.

Comment vais-je séparer le bon grain de l'ivraie ? Je pense que passer par
un live-CD devrait permettre de faire les choses proprement, mais sinon ?

Méph'


Michel.


Nicolas George
Le #1906067
Michel Tatoute wrote in message
a) tu peux faire une copie de l'image de ta partition et utiliser
un 'resizefs' (resize2fs) pour l'adapter à le nouvelle partition plus
grosse.


Ce n'est vraiment pas une bonne idée, ça.

-- utiliser rsync te permet de faire une reprise sur interruption)


Mais il rate les ACL.

-- les "/./" à la fin sécurise en évitant de créer


Pas la peine : rsync a un comportement tout à fait prévisible : si ça se
termine par /, il copie le contenu du répertoire, sans copier le répertoire
lui-même. Je n'en dirais pas autant de tous les outils, cependant, donc le
truc du /./ est bon à diffuser.

je fignole grub


Ça ne marche pas si simplement que ça : grub a besoin de savoir comment le
BIOS verra le disque dur, et il y a des mauvaises interactions.

Michel Tatoute
Le #1906065
Nicolas George wrote:

Michel Tatoute wrote in message
a) tu peux faire une copie de l'image de ta partition et utiliser
un 'resizefs' (resize2fs) pour l'adapter à le nouvelle partition plus
grosse.


Ce n'est vraiment pas une bonne idée, ça.

-- utiliser rsync te permet de faire une reprise sur interruption)


Mais il rate les ACL.


$ man rsync
// blablabla
-A, --acls preserve ACLs (implies -p) [non-standard]
// blablabla


-- les "/./" à la fin sécurise en évitant de créer


Pas la peine : rsync a un comportement tout à fait prévisible : si ça se
termine par /, il copie le contenu du répertoire, sans copier le
répertoire lui-même. Je n'en dirais pas autant de tous les outils,
cependant, donc le truc du /./ est bon à diffuser.

je fignole grub


Ça ne marche pas si simplement que ça : grub a besoin de savoir comment le
BIOS verra le disque dur, et il y a des mauvaises interactions.


Ok. Mais c'est drôle quand même...

Michel.


tonto
Le #1907470
Salut tout le monde !

Pour gagner un peu plus d'espace (stockage de photos qui sont actuellement
sur DD externe et petits montages vidéos) je souhaite changer de DD (80 Go
actuellement pour ... plus)

actuellement :
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/hdc1 30G 7,8G 21G 28% /
/dev/hdc6 49G 37G 10G 79% /home
/dev/hda5 39G 8,2G 30G 22% /mnt/dos
/dev/hda1 42G 14G 29G 32% /mnt/ntfs

C'est hdc que je veux remplacer.

Ce que je pense faire :

- sauvegarde ;-)
- mettre le nouveau disque sur l'interface usb/ide de mon DD externe
- partitionner (40 - 50 Go pour la racine, le reste pour le future /home)
40Go pour la racine c'est beaucoup trop !

J'ai ubuntu avec gnome + Kde (paquet kubuntu-desktop) et le tout ne
prends que 3.8Go.

- copier les fichiers
- installer le nouveau disque sur la nappe IDE.

Est-ce que cela va marcher ? notamment :
- GRUB va-t-il y retrouver ses petits ?
- faudra-t-il modifier /etc/fstab ?
Si le fstab utilise les uuid, pas besoin de le changer.


Sans uuid, il suffirai de brancher une clé usb ou carte mémoire pour que
le disque passe de sda à sdb, ce qui l'empècherai de démarrer.

http://doc.ubuntu-fr.org/uuid_et_label#differencier_deux_peripheriques_usb

Publicité
Poster une réponse
Anonyme