Bon, je sais comment installer linux sur le dd interne, mais je souhaite
copier l'installation actuelle sur un disque externe puis passer ce
disque en interne.
j'imagine que copier l'intégralité du disque n'est pas suffisant pour
que le disque externe passé en interne soit reconnu.
il y a vraisemblablement d'autres choses à faire, mais quoi ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
Le 23/07/2017 à 09:07, Une Bévue a écrit :
Bon, je sais comment installer linux sur le dd interne, mais je souhaite copier l'installation actuelle sur un disque externe puis passer ce disque en interne.
Quelle est le but du remplacement ?
j'imagine que copier l'intégralité du disque n'est pas suffisant pour que le disque externe passé en interne soit reconnu. il y a vraisemblablement d'autres choses à faire, mais quoi ?
Copier l'intégralité du disque (secteur par secteur) peut être suffisant à quelques conditions. - La capacité du disque destinataire est supérieure ou égale à celle du disque source. - Les deux disques ont la même taille de secteur logique (512 ou 4096 octets). - Aucune structure de données des deux disques ne doit être susceptible d'être modifiée pendant la copie. Notamment, aucune partition ne doit être montée en lecture-écriture. Il peut y avoir des ajustements à faire ensuite selon la situation. Si les deux disques sont susceptibles d'être utilisés ensemble par la suite, il est préférable de modifier les identifiants persistants (UUID, LABEL, PARTUUID, PARTLABEL, identifiant/signature du MBR) de l'un de deux. Si la capacité du disque destinataire est supérieure à celle du disque source, il faut mettre à jour la table de partition avec la nouvelle taille si elle est au format GPT. Selon la distribution, pour que les futures mises à jour du chargeur d'amorçage se passent bien il peut être nécessaire de mettre à jour la désignation du périphérique d'installation du chargeur d'amorçage dans la configuration du gestionnaire de paquetages, si elle est liée à l'identifiant matériel du disque.
Le 23/07/2017 à 09:07, Une Bévue a écrit :
Bon, je sais comment installer linux sur le dd interne, mais je souhaite
copier l'installation actuelle sur un disque externe puis passer ce
disque en interne.
Quelle est le but du remplacement ?
j'imagine que copier l'intégralité du disque n'est pas suffisant pour
que le disque externe passé en interne soit reconnu.
il y a vraisemblablement d'autres choses à faire, mais quoi ?
Copier l'intégralité du disque (secteur par secteur) peut être suffisant
à quelques conditions.
- La capacité du disque destinataire est supérieure ou égale à celle du
disque source.
- Les deux disques ont la même taille de secteur logique (512 ou 4096
octets).
- Aucune structure de données des deux disques ne doit être susceptible
d'être modifiée pendant la copie. Notamment, aucune partition ne doit
être montée en lecture-écriture.
Il peut y avoir des ajustements à faire ensuite selon la situation.
Si les deux disques sont susceptibles d'être utilisés ensemble par la
suite, il est préférable de modifier les identifiants persistants (UUID,
LABEL, PARTUUID, PARTLABEL, identifiant/signature du MBR) de l'un de deux.
Si la capacité du disque destinataire est supérieure à celle du disque
source, il faut mettre à jour la table de partition avec la nouvelle
taille si elle est au format GPT.
Selon la distribution, pour que les futures mises à jour du chargeur
d'amorçage se passent bien il peut être nécessaire de mettre à jour la
désignation du périphérique d'installation du chargeur d'amorçage dans
la configuration du gestionnaire de paquetages, si elle est liée à
l'identifiant matériel du disque.
Bon, je sais comment installer linux sur le dd interne, mais je souhaite copier l'installation actuelle sur un disque externe puis passer ce disque en interne.
Quelle est le but du remplacement ?
j'imagine que copier l'intégralité du disque n'est pas suffisant pour que le disque externe passé en interne soit reconnu. il y a vraisemblablement d'autres choses à faire, mais quoi ?
Copier l'intégralité du disque (secteur par secteur) peut être suffisant à quelques conditions. - La capacité du disque destinataire est supérieure ou égale à celle du disque source. - Les deux disques ont la même taille de secteur logique (512 ou 4096 octets). - Aucune structure de données des deux disques ne doit être susceptible d'être modifiée pendant la copie. Notamment, aucune partition ne doit être montée en lecture-écriture. Il peut y avoir des ajustements à faire ensuite selon la situation. Si les deux disques sont susceptibles d'être utilisés ensemble par la suite, il est préférable de modifier les identifiants persistants (UUID, LABEL, PARTUUID, PARTLABEL, identifiant/signature du MBR) de l'un de deux. Si la capacité du disque destinataire est supérieure à celle du disque source, il faut mettre à jour la table de partition avec la nouvelle taille si elle est au format GPT. Selon la distribution, pour que les futures mises à jour du chargeur d'amorçage se passent bien il peut être nécessaire de mettre à jour la désignation du périphérique d'installation du chargeur d'amorçage dans la configuration du gestionnaire de paquetages, si elle est liée à l'identifiant matériel du disque.
Nicolas George
Pascal Hambourg , dans le message <ol1jqu$2vc9$, a écrit :
Copier l'intégralité du disque (secteur par secteur) peut être suffisant à quelques conditions.
Mais ce n'est pas forcément le meilleur choix. Copier les fichiers sur un filesystem fraîchement créé peut présenter des avantages. En particulier, si le disque dur est peu plein, ça ira probablement beaucoup plus vite (en revanche, s'il est bien plein de petits fichiers écrits dans le désordre, si c'est un disque rotatif ça sera dramatiquement lent). Et surtout c'est beaucoup moins sensible aux conditions que tu indiques :
- La capacité du disque destinataire est supérieure ou égale à celle du disque source. - Les deux disques ont la même taille de secteur logique (512 ou 4096 octets). - Aucune structure de données des deux disques ne doit être susceptible d'être modifiée pendant la copie. Notamment, aucune partition ne doit être montée en lecture-écriture. Il peut y avoir des ajustements à faire ensuite selon la situation. Si les deux disques sont susceptibles d'être utilisés ensemble par la suite, il est préférable de modifier les identifiants persistants (UUID, LABEL, PARTUUID, PARTLABEL, identifiant/signature du MBR) de l'un de deux. Si la capacité du disque destinataire est supérieure à celle du disque source, il faut mettre à jour la table de partition avec la nouvelle taille si elle est au format GPT.
... et probablement redimensionner la partition et le filesystem qu'elle contient pour profiter de la capacité supplémentaire. Dans les deux cas (copie de la partition puis changement d'UUID ou copie des fichiers), il faudra éditer /etc/fstab.
Pascal Hambourg , dans le message <ol1jqu$2vc9$1@saria.nerim.net>, a
écrit :
Copier l'intégralité du disque (secteur par secteur) peut être suffisant
à quelques conditions.
Mais ce n'est pas forcément le meilleur choix. Copier les fichiers sur
un filesystem fraîchement créé peut présenter des avantages.
En particulier, si le disque dur est peu plein, ça ira probablement
beaucoup plus vite (en revanche, s'il est bien plein de petits fichiers
écrits dans le désordre, si c'est un disque rotatif ça sera
dramatiquement lent).
Et surtout c'est beaucoup moins sensible aux conditions que tu
indiques :
- La capacité du disque destinataire est supérieure ou égale à celle du
disque source.
- Les deux disques ont la même taille de secteur logique (512 ou 4096
octets).
- Aucune structure de données des deux disques ne doit être susceptible
d'être modifiée pendant la copie. Notamment, aucune partition ne doit
être montée en lecture-écriture.
Il peut y avoir des ajustements à faire ensuite selon la situation.
Si les deux disques sont susceptibles d'être utilisés ensemble par la
suite, il est préférable de modifier les identifiants persistants (UUID,
LABEL, PARTUUID, PARTLABEL, identifiant/signature du MBR) de l'un de deux.
Si la capacité du disque destinataire est supérieure à celle du disque
source, il faut mettre à jour la table de partition avec la nouvelle
taille si elle est au format GPT.
... et probablement redimensionner la partition et le filesystem qu'elle
contient pour profiter de la capacité supplémentaire.
Dans les deux cas (copie de la partition puis changement d'UUID ou copie
des fichiers), il faudra éditer /etc/fstab.
Pascal Hambourg , dans le message <ol1jqu$2vc9$, a écrit :
Copier l'intégralité du disque (secteur par secteur) peut être suffisant à quelques conditions.
Mais ce n'est pas forcément le meilleur choix. Copier les fichiers sur un filesystem fraîchement créé peut présenter des avantages. En particulier, si le disque dur est peu plein, ça ira probablement beaucoup plus vite (en revanche, s'il est bien plein de petits fichiers écrits dans le désordre, si c'est un disque rotatif ça sera dramatiquement lent). Et surtout c'est beaucoup moins sensible aux conditions que tu indiques :
- La capacité du disque destinataire est supérieure ou égale à celle du disque source. - Les deux disques ont la même taille de secteur logique (512 ou 4096 octets). - Aucune structure de données des deux disques ne doit être susceptible d'être modifiée pendant la copie. Notamment, aucune partition ne doit être montée en lecture-écriture. Il peut y avoir des ajustements à faire ensuite selon la situation. Si les deux disques sont susceptibles d'être utilisés ensemble par la suite, il est préférable de modifier les identifiants persistants (UUID, LABEL, PARTUUID, PARTLABEL, identifiant/signature du MBR) de l'un de deux. Si la capacité du disque destinataire est supérieure à celle du disque source, il faut mettre à jour la table de partition avec la nouvelle taille si elle est au format GPT.
... et probablement redimensionner la partition et le filesystem qu'elle contient pour profiter de la capacité supplémentaire. Dans les deux cas (copie de la partition puis changement d'UUID ou copie des fichiers), il faudra éditer /etc/fstab.
Pascal Hambourg
Le 23/07/2017 à 12:32, Nicolas George a écrit :
Pascal Hambourg , dans le message <ol1jqu$2vc9$, a écrit :
Copier l'intégralité du disque (secteur par secteur) peut être suffisant à quelques conditions.
Mais ce n'est pas forcément le meilleur choix.
Evidemment. Ce n'est pas à toi que j'apprendrai qu'une optimisation se base sur des critères, que l'OP n'a pas indiqués.
Copier les fichiers sur un filesystem fraîchement créé peut présenter des avantages.
Evidemment. Y compris la possibilité de changer de type de système de fichiers pour un plus moderne ou performant.
Et surtout c'est beaucoup moins sensible aux conditions que tu indiques :
- La capacité du disque destinataire est supérieure ou égale à celle du disque source.
Une contrainte similaire mais moins forte existe avec la copie des fichiers : la taille du contenu de la source doit être inférieure ou égale à la capacité de la destination.
- Les deux disques ont la même taille de secteur logique (512 ou 4096 octets).
En effet cette contrainte est rédhibitoire avec la copie brute mais sans objet avec la copie de fichiers.
- Aucune structure de données des deux disques ne doit être susceptible d'être modifiée pendant la copie. Notamment, aucune partition ne doit être montée en lecture-écriture.
Là aussi il y a quand même une contrainte moins forte avec la copie de fichiers : les fichiers formant un ensemble qui doit être cohérent ne doivent pas être modifiés pendant la copie. Je pense notamment aux bases de données qui devraient être arrêtés pendant la copie. En gros c'est la même contrainte que pour une sauvegarde.
Il peut y avoir des ajustements à faire ensuite selon la situation.
(...)
... et probablement redimensionner la partition et le filesystem qu'elle contient pour profiter de la capacité supplémentaire.
Dépend de la finalité. Pas de redimensionnement si on veut plus d'espace pour installer un autre système ou créer d'autres partitions.
Le 23/07/2017 à 12:32, Nicolas George a écrit :
Pascal Hambourg , dans le message <ol1jqu$2vc9$1@saria.nerim.net>, a
écrit :
Copier l'intégralité du disque (secteur par secteur) peut être suffisant
à quelques conditions.
Mais ce n'est pas forcément le meilleur choix.
Evidemment. Ce n'est pas à toi que j'apprendrai qu'une optimisation se
base sur des critères, que l'OP n'a pas indiqués.
Copier les fichiers sur
un filesystem fraîchement créé peut présenter des avantages.
Evidemment. Y compris la possibilité de changer de type de système de
fichiers pour un plus moderne ou performant.
Et surtout c'est beaucoup moins sensible aux conditions que tu
indiques :
- La capacité du disque destinataire est supérieure ou égale à celle du
disque source.
Une contrainte similaire mais moins forte existe avec la copie des
fichiers : la taille du contenu de la source doit être inférieure ou
égale à la capacité de la destination.
- Les deux disques ont la même taille de secteur logique (512 ou 4096
octets).
En effet cette contrainte est rédhibitoire avec la copie brute mais sans
objet avec la copie de fichiers.
- Aucune structure de données des deux disques ne doit être susceptible
d'être modifiée pendant la copie. Notamment, aucune partition ne doit
être montée en lecture-écriture.
Là aussi il y a quand même une contrainte moins forte avec la copie de
fichiers : les fichiers formant un ensemble qui doit être cohérent ne
doivent pas être modifiés pendant la copie. Je pense notamment aux bases
de données qui devraient être arrêtés pendant la copie. En gros c'est la
même contrainte que pour une sauvegarde.
Il peut y avoir des ajustements à faire ensuite selon la situation.
(...)
... et probablement redimensionner la partition et le filesystem qu'elle
contient pour profiter de la capacité supplémentaire.
Dépend de la finalité. Pas de redimensionnement si on veut plus d'espace
pour installer un autre système ou créer d'autres partitions.
Pascal Hambourg , dans le message <ol1jqu$2vc9$, a écrit :
Copier l'intégralité du disque (secteur par secteur) peut être suffisant à quelques conditions.
Mais ce n'est pas forcément le meilleur choix.
Evidemment. Ce n'est pas à toi que j'apprendrai qu'une optimisation se base sur des critères, que l'OP n'a pas indiqués.
Copier les fichiers sur un filesystem fraîchement créé peut présenter des avantages.
Evidemment. Y compris la possibilité de changer de type de système de fichiers pour un plus moderne ou performant.
Et surtout c'est beaucoup moins sensible aux conditions que tu indiques :
- La capacité du disque destinataire est supérieure ou égale à celle du disque source.
Une contrainte similaire mais moins forte existe avec la copie des fichiers : la taille du contenu de la source doit être inférieure ou égale à la capacité de la destination.
- Les deux disques ont la même taille de secteur logique (512 ou 4096 octets).
En effet cette contrainte est rédhibitoire avec la copie brute mais sans objet avec la copie de fichiers.
- Aucune structure de données des deux disques ne doit être susceptible d'être modifiée pendant la copie. Notamment, aucune partition ne doit être montée en lecture-écriture.
Là aussi il y a quand même une contrainte moins forte avec la copie de fichiers : les fichiers formant un ensemble qui doit être cohérent ne doivent pas être modifiés pendant la copie. Je pense notamment aux bases de données qui devraient être arrêtés pendant la copie. En gros c'est la même contrainte que pour une sauvegarde.
Il peut y avoir des ajustements à faire ensuite selon la situation.
(...)
... et probablement redimensionner la partition et le filesystem qu'elle contient pour profiter de la capacité supplémentaire.
Dépend de la finalité. Pas de redimensionnement si on veut plus d'espace pour installer un autre système ou créer d'autres partitions.
Nicolas George
Pascal Hambourg , dans le message <ol26vg$320$, a écrit :
Evidemment. Ce n'est pas à toi que j'apprendrai qu'une optimisation se base sur des critères, que l'OP n'a pas indiqués.
Non, ce n'est pas à moi qu'il faut l'apprendre, c'est à Une Bévue : la forme de la question laisse penser qu'elle n'est pas bien au fait de ces subtilités.
Une contrainte similaire mais moins forte existe avec la copie des fichiers : la taille du contenu de la source doit être inférieure ou égale à la capacité de la destination.
Ça, j'espère que c'est évident pour tout le monde susceptible d'envisager ce genre d'opération.
Pascal Hambourg , dans le message <ol26vg$320$1@saria.nerim.net>, a
écrit :
Evidemment. Ce n'est pas à toi que j'apprendrai qu'une optimisation se
base sur des critères, que l'OP n'a pas indiqués.
Non, ce n'est pas à moi qu'il faut l'apprendre, c'est à Une Bévue : la
forme de la question laisse penser qu'elle n'est pas bien au fait de ces
subtilités.
Une contrainte similaire mais moins forte existe avec la copie des
fichiers : la taille du contenu de la source doit être inférieure ou
égale à la capacité de la destination.
Ça, j'espère que c'est évident pour tout le monde susceptible
d'envisager ce genre d'opération.
Pascal Hambourg , dans le message <ol26vg$320$, a écrit :
Evidemment. Ce n'est pas à toi que j'apprendrai qu'une optimisation se base sur des critères, que l'OP n'a pas indiqués.
Non, ce n'est pas à moi qu'il faut l'apprendre, c'est à Une Bévue : la forme de la question laisse penser qu'elle n'est pas bien au fait de ces subtilités.
Une contrainte similaire mais moins forte existe avec la copie des fichiers : la taille du contenu de la source doit être inférieure ou égale à la capacité de la destination.
Ça, j'espère que c'est évident pour tout le monde susceptible d'envisager ce genre d'opération.
Une B=c3=a9vue
Le 23/07/2017 à 09:39, Pascal Hambourg a écrit :
Quelle est le but du remplacement ?
le silence et la vitesse : en fait mon dd interne est un "vieux" dd à plateau et je souhaite le remplacer par un ssd en rab'.
Le 23/07/2017 à 09:39, Pascal Hambourg a écrit :
Quelle est le but du remplacement ?
le silence et la vitesse : en fait mon dd interne est un "vieux" dd à
plateau et je souhaite le remplacer par un ssd en rab'.
le silence et la vitesse : en fait mon dd interne est un "vieux" dd à plateau et je souhaite le remplacer par un ssd en rab'.
Une B=c3=a9vue
Le 23/07/2017 à 15:11, Nicolas George a écrit :
Non, ce n'est pas à moi qu'il faut l'apprendre, c'est à Une Bévue : la forme de la question laisse penser qu'elle n'est pas bien au fait de ces subtilités.
ben non... j'en ai fait l'expérience récemment : voulant donné au secours pop' un "vieux" dell D620 monté en ssd qui tournait bien sous linux mint, j'ai remplacé le ssd interne par son vieux dd à plateau, espérant ensuite, avec une clé USB d'install, ré-installer un linux. ça n'a pas marché, le bios (?) m'injuriant sur un problème de mauvaise config, je n'ai pas su réparer ça. (je n'ai pas plus de détail à fournir car je n'ai plus ce dell d620) là il s'agit de remplacer le dd (à plateau) interne par un petit ssd en rab' (128 GO) pour son silence et sa vitesse sur un dell vostro qu'on m'a filé. compte-tenu de votre discussion, je ne copierai pas, je ré-installerai un linux XFCE sur le ssd à partir d'une clé USB. me reste donc à : - 1 - créer la clé usb bootable avec un linux léger (mint XFCE?) pour l'installer sur cet ordi j'utiliserai : - xscreensaver (c'est l'utilisation principale) : l'ordi présente une photo prise dans le répertoire adequat du disque externe de ma freebox ; - Firefox Developer Edition (installation "manuelle" ?) ; - Thunderbird. - 2 - échanger les disques en m'assurant que le bios (?) ne couine pas quand après que le ssd ait été installé, pour pouvoir, finalement : - 3 - installer un linux sur le ssd.
Le 23/07/2017 à 15:11, Nicolas George a écrit :
Non, ce n'est pas à moi qu'il faut l'apprendre, c'est à Une Bévue : la
forme de la question laisse penser qu'elle n'est pas bien au fait de ces
subtilités.
ben non...
j'en ai fait l'expérience récemment :
voulant donné au secours pop' un "vieux" dell D620 monté en ssd qui
tournait bien sous linux mint, j'ai remplacé le ssd interne par son
vieux dd à plateau, espérant ensuite, avec une clé USB d'install,
ré-installer un linux.
ça n'a pas marché, le bios (?) m'injuriant sur un problème de mauvaise
config, je n'ai pas su réparer ça.
(je n'ai pas plus de détail à fournir car je n'ai plus ce dell d620)
là il s'agit de remplacer le dd (à plateau) interne par un petit ssd en
rab' (128 GO) pour son silence et sa vitesse sur un dell vostro qu'on
m'a filé.
compte-tenu de votre discussion, je ne copierai pas, je ré-installerai
un linux XFCE sur le ssd à partir d'une clé USB.
me reste donc à :
- 1 - créer la clé usb bootable avec un linux léger (mint XFCE?) pour
l'installer sur cet ordi j'utiliserai :
- xscreensaver (c'est l'utilisation principale) : l'ordi présente une
photo prise dans le répertoire adequat du disque externe de ma freebox ;
- Firefox Developer Edition (installation "manuelle" ?) ;
- Thunderbird.
- 2 - échanger les disques en m'assurant que le bios (?) ne couine pas
quand après que le ssd ait été installé, pour pouvoir, finalement :
Non, ce n'est pas à moi qu'il faut l'apprendre, c'est à Une Bévue : la forme de la question laisse penser qu'elle n'est pas bien au fait de ces subtilités.
ben non... j'en ai fait l'expérience récemment : voulant donné au secours pop' un "vieux" dell D620 monté en ssd qui tournait bien sous linux mint, j'ai remplacé le ssd interne par son vieux dd à plateau, espérant ensuite, avec une clé USB d'install, ré-installer un linux. ça n'a pas marché, le bios (?) m'injuriant sur un problème de mauvaise config, je n'ai pas su réparer ça. (je n'ai pas plus de détail à fournir car je n'ai plus ce dell d620) là il s'agit de remplacer le dd (à plateau) interne par un petit ssd en rab' (128 GO) pour son silence et sa vitesse sur un dell vostro qu'on m'a filé. compte-tenu de votre discussion, je ne copierai pas, je ré-installerai un linux XFCE sur le ssd à partir d'une clé USB. me reste donc à : - 1 - créer la clé usb bootable avec un linux léger (mint XFCE?) pour l'installer sur cet ordi j'utiliserai : - xscreensaver (c'est l'utilisation principale) : l'ordi présente une photo prise dans le répertoire adequat du disque externe de ma freebox ; - Firefox Developer Edition (installation "manuelle" ?) ; - Thunderbird. - 2 - échanger les disques en m'assurant que le bios (?) ne couine pas quand après que le ssd ait été installé, pour pouvoir, finalement : - 3 - installer un linux sur le ssd.
Une B=c3=a9vue
Précision : le ssd je peux très bien, dans une première étape le monter en externe, car j'ai un câble qui va bien ATA <=> USB.
Précision :
le ssd je peux très bien, dans une première étape le monter en externe,
car j'ai un câble qui va bien ATA <=> USB.
