Install sur un PC puis transfert du DD sur un autre PC : possible ?
35 réponses
Alf92
Bjr,
J'ai un (vieux) PC dont le lecteur de DVD est HS et pour lequel le boot
sur USB n'est pas possible.
Puis-je faire l'nstall de Linux Mint (v19.3 car en 32bots...) sur un
autre PC puis transferer le DD sur un ce vieux PC ?
Si oui y aura-t-il une nouvelle découverte des périphériques +
installation des bons drivers ?
Merci.
Pour la même raison, j'ai installé une distribution utilisant un autre init (artix open-rc) et je m'en porte mieux.
Je dois dire que j'ai beaucoup testé avant de passer Í systemd, et qu'Í part quelques bugs facilement corrigeables, je n'ai pas eu trop de souci avec buster. Juste quelques soucis avec certaines fonctions avancés comme les namespaces dans apache2 en virtualisation. systemd est un gros logiciel monolithique qui -- Í mon avis -- s'oppose aux concepts UNIX: mais c'est une tendance assez actuelle qu'un simple logiciel dépende Í dbus, voire systemd. Et vu que ma distribution préférée a décidé de faire le pas, je l'ai fait aussi. Et probablement que d'ici ma prochaine mise Í jour de version en 2024, l'init aura re-changé, donc je n'investis pas trop de savoir faire non plus. Etonnamment, même sur des alix (256 MB de mémoire), passer Í systemd n'a pas été aussi catastrophique que ça. Ca boote plus lentement, le système bouffe plus de mémoire, il y a un peu plus d'I/O, mais questions fonctionnalités il n'y a pas eu de retour en arrière. Mes tests précédents avec jessie et stretch étaient bien plus calamiteux, des choses simples ne fonctionnant plus correctement, les logs étant pleins, les machines crashaient, etc.
Pour la même raison, j'ai installé une distribution utilisant un autre
init (artix open-rc) et je m'en porte mieux.
Je dois dire que j'ai beaucoup testé avant de passer Í systemd, et qu'Í
part quelques bugs facilement corrigeables, je n'ai pas eu trop de souci
avec buster. Juste quelques soucis avec certaines fonctions avancés
comme les namespaces dans apache2 en virtualisation.
systemd est un gros logiciel monolithique qui -- Í mon avis -- s'oppose
aux concepts UNIX: mais c'est une tendance assez actuelle qu'un simple
logiciel dépende Í dbus, voire systemd.
Et vu que ma distribution préférée a décidé de faire le pas, je l'ai
fait aussi. Et probablement que d'ici ma prochaine mise Í jour de
version en 2024, l'init aura re-changé, donc je n'investis pas trop de
savoir faire non plus.
Etonnamment, même sur des alix (256 MB de mémoire), passer Í systemd n'a
pas été aussi catastrophique que ça. Ca boote plus lentement, le
système bouffe plus de mémoire, il y a un peu plus d'I/O, mais questions
fonctionnalités il n'y a pas eu de retour en arrière.
Mes tests précédents avec jessie et stretch étaient bien plus
calamiteux, des choses simples ne fonctionnant plus correctement, les
logs étant pleins, les machines crashaient, etc.
Pour la même raison, j'ai installé une distribution utilisant un autre init (artix open-rc) et je m'en porte mieux.
Je dois dire que j'ai beaucoup testé avant de passer Í systemd, et qu'Í part quelques bugs facilement corrigeables, je n'ai pas eu trop de souci avec buster. Juste quelques soucis avec certaines fonctions avancés comme les namespaces dans apache2 en virtualisation. systemd est un gros logiciel monolithique qui -- Í mon avis -- s'oppose aux concepts UNIX: mais c'est une tendance assez actuelle qu'un simple logiciel dépende Í dbus, voire systemd. Et vu que ma distribution préférée a décidé de faire le pas, je l'ai fait aussi. Et probablement que d'ici ma prochaine mise Í jour de version en 2024, l'init aura re-changé, donc je n'investis pas trop de savoir faire non plus. Etonnamment, même sur des alix (256 MB de mémoire), passer Í systemd n'a pas été aussi catastrophique que ça. Ca boote plus lentement, le système bouffe plus de mémoire, il y a un peu plus d'I/O, mais questions fonctionnalités il n'y a pas eu de retour en arrière. Mes tests précédents avec jessie et stretch étaient bien plus calamiteux, des choses simples ne fonctionnant plus correctement, les logs étant pleins, les machines crashaient, etc.
Nicolas George
Marc SCHAEFER , dans le message <rs1tok$8vj$, a écrit :
a) remettre le script d'auto-génération de jessie qui a l'avantage d'être figé une fois installé (et je peux mettre / en -o ro après)
Tu as mal compris le sens d'«Â auto-génération ». Ce script, comme son nom l'indique, génère des règles. Ce que je t'explique, c'est que tu peux écrire directement ces règles.
Marc SCHAEFER , dans le message <rs1tok$8vj$1@shakotay.alphanet.ch>, a
écrit :
a) remettre le script d'auto-génération de jessie
qui a l'avantage d'être figé une fois installé
(et je peux mettre / en -o ro après)
Tu as mal compris le sens d'«Â auto-génération ». Ce script, comme son nom
l'indique, génère des règles. Ce que je t'explique, c'est que tu peux écrire
directement ces règles.
Marc SCHAEFER , dans le message <rs1tok$8vj$, a écrit :
a) remettre le script d'auto-génération de jessie qui a l'avantage d'être figé une fois installé (et je peux mettre / en -o ro après)
Tu as mal compris le sens d'«Â auto-génération ». Ce script, comme son nom l'indique, génère des règles. Ce que je t'explique, c'est que tu peux écrire directement ces règles.
Nicolas George
Marc SCHAEFER , dans le message <rs23v7$1tc$, a écrit :
Je dois dire que j'ai beaucoup testé avant de passer Í systemd, et qu'Í part quelques bugs facilement corrigeables, je n'ai pas eu trop de souci avec buster.
La plupart des critiques de systemd sont non pertinentes, voire carrément mensongères. Il y a quelques personnes qui ont des critiques valides et intéressantes et qui savent de quoi elles parlent, mais c'est rare. Le reste, c'est surtout des vieux grincheux qui ont inconsciemment peur que leurs connaissances durement acquises deviennent obsolètes et qui se retrouvent Í défendre un système qui était déjÍ moisi il y a des années.
Etonnamment, même sur des alix (256 MB de mémoire), passer Í systemd n'a pas été aussi catastrophique que ça. Ca boote plus lentement, le système bouffe plus de mémoire, il y a un peu plus d'I/O, mais questions fonctionnalités il n'y a pas eu de retour en arrière.
Tu es sÍ»r que c'est le passage Í systemd qui cause le ralentissement, plutÍ´t que les autres mises Í jour simultanées ?
Marc SCHAEFER , dans le message <rs23v7$1tc$1@shakotay.alphanet.ch>, a
écrit :
Je dois dire que j'ai beaucoup testé avant de passer Í systemd, et qu'Í
part quelques bugs facilement corrigeables, je n'ai pas eu trop de souci
avec buster.
La plupart des critiques de systemd sont non pertinentes, voire carrément
mensongères. Il y a quelques personnes qui ont des critiques valides et
intéressantes et qui savent de quoi elles parlent, mais c'est rare. Le
reste, c'est surtout des vieux grincheux qui ont inconsciemment peur que
leurs connaissances durement acquises deviennent obsolètes et qui se
retrouvent Í défendre un système qui était déjÍ moisi il y a des années.
Etonnamment, même sur des alix (256 MB de mémoire), passer Í systemd n'a
pas été aussi catastrophique que ça. Ca boote plus lentement, le
système bouffe plus de mémoire, il y a un peu plus d'I/O, mais questions
fonctionnalités il n'y a pas eu de retour en arrière.
Tu es sÍ»r que c'est le passage Í systemd qui cause le ralentissement, plutÍ´t
que les autres mises Í jour simultanées ?
Marc SCHAEFER , dans le message <rs23v7$1tc$, a écrit :
Je dois dire que j'ai beaucoup testé avant de passer Í systemd, et qu'Í part quelques bugs facilement corrigeables, je n'ai pas eu trop de souci avec buster.
La plupart des critiques de systemd sont non pertinentes, voire carrément mensongères. Il y a quelques personnes qui ont des critiques valides et intéressantes et qui savent de quoi elles parlent, mais c'est rare. Le reste, c'est surtout des vieux grincheux qui ont inconsciemment peur que leurs connaissances durement acquises deviennent obsolètes et qui se retrouvent Í défendre un système qui était déjÍ moisi il y a des années.
Etonnamment, même sur des alix (256 MB de mémoire), passer Í systemd n'a pas été aussi catastrophique que ça. Ca boote plus lentement, le système bouffe plus de mémoire, il y a un peu plus d'I/O, mais questions fonctionnalités il n'y a pas eu de retour en arrière.
Tu es sÍ»r que c'est le passage Í systemd qui cause le ralentissement, plutÍ´t que les autres mises Í jour simultanées ?
Marc SCHAEFER
Nicolas George <nicolas$ wrote:
Tu as mal compris le sens d'«Â auto-génération ». Ce script, comme son nom l'indique, génère des règles. Ce que je t'explique, c'est que tu peux écrire directement ces règles.
Je l'ai déjÍ fait, effectivement. D'un point de vue intégrateur (celui qui installe les systèmes embarqués), le script automatique est plus simple, d'ailleurs il a marché 20 ans.
Nicolas George <nicolas$george@salle-s.org> wrote:
Tu as mal compris le sens d'«Â auto-génération ». Ce script, comme son nom
l'indique, génère des règles. Ce que je t'explique, c'est que tu peux écrire
directement ces règles.
Je l'ai déjÍ fait, effectivement.
D'un point de vue intégrateur (celui qui installe les systèmes
embarqués), le script automatique est plus simple, d'ailleurs il a
marché 20 ans.
Tu as mal compris le sens d'«Â auto-génération ». Ce script, comme son nom l'indique, génère des règles. Ce que je t'explique, c'est que tu peux écrire directement ces règles.
Je l'ai déjÍ fait, effectivement. D'un point de vue intégrateur (celui qui installe les systèmes embarqués), le script automatique est plus simple, d'ailleurs il a marché 20 ans.
Marc SCHAEFER
Nicolas George <nicolas$ wrote:
Tu es sÍ»r que c'est le passage Í systemd qui cause le ralentissement, plutÍ´t que les autres mises Í jour simultanées ?
Oui, j'ai un cas o͹ init est un script shell entièrement manuel, et la performance des services lancés est meilleure qu'avant (apparemment le nouveau kernel et/ou libc, compilateur, etc ont amélioré les choses, systemd les a dégradés). J'ai d'ailleurs hésité Í généraliser cette façon de faire et laisser tomber systemd complètement: mais le travail supplémentaire nécessaire d'"extégration" m'a semblé inutile. Au départ je pensais que c'était le kernel bloat le problème, ou les éventuels work-around pour les divers bugs de sécurité de processeur Intel voire AMD (encore que sur alix, avec un AMD Géode, je n'ai pas évalué ça). Mais comme j'ai dit, je peux vivre avec une telle dégradation due Í systemd. Et je m'en fiche un peu, dans 5 ans, ça sera quelque chose d'autre que Debian aura mitonné, peut-être, et ça sera aussi bien intégré, comme d'habitude avec Debian (enfin, il faut attendre 1 version intermédiaire :->) Et une fois qu'on s'est (temporairement) habitué Í diverses petites choses casse-pied comme le fait qu'il faut faire un daemon-reload, que certaines fonctionnalités ne marchent plus ou autre, on s'habitue assez rapidement.
Nicolas George <nicolas$george@salle-s.org> wrote:
Tu es sÍ»r que c'est le passage Í systemd qui cause le ralentissement, plutÍ´t
que les autres mises Í jour simultanées ?
Oui, j'ai un cas o͹ init est un script shell entièrement manuel, et la
performance des services lancés est meilleure qu'avant (apparemment le
nouveau kernel et/ou libc, compilateur, etc ont amélioré les choses,
systemd les a dégradés).
J'ai d'ailleurs hésité Í généraliser cette façon de faire et laisser
tomber systemd complètement: mais le travail supplémentaire nécessaire
d'"extégration" m'a semblé inutile.
Au départ je pensais que c'était le kernel bloat le problème, ou les
éventuels work-around pour les divers bugs de sécurité de processeur
Intel voire AMD (encore que sur alix, avec un AMD Géode, je n'ai pas
évalué ça).
Mais comme j'ai dit, je peux vivre avec une telle dégradation due Í
systemd. Et je m'en fiche un peu, dans 5 ans, ça sera quelque chose
d'autre que Debian aura mitonné, peut-être, et ça sera aussi bien
intégré, comme d'habitude avec Debian (enfin, il faut attendre 1 version
intermédiaire :->)
Et une fois qu'on s'est (temporairement) habitué Í diverses petites
choses casse-pied comme le fait qu'il faut faire un daemon-reload, que
certaines fonctionnalités ne marchent plus ou autre, on s'habitue assez
rapidement.
Tu es sÍ»r que c'est le passage Í systemd qui cause le ralentissement, plutÍ´t que les autres mises Í jour simultanées ?
Oui, j'ai un cas o͹ init est un script shell entièrement manuel, et la performance des services lancés est meilleure qu'avant (apparemment le nouveau kernel et/ou libc, compilateur, etc ont amélioré les choses, systemd les a dégradés). J'ai d'ailleurs hésité Í généraliser cette façon de faire et laisser tomber systemd complètement: mais le travail supplémentaire nécessaire d'"extégration" m'a semblé inutile. Au départ je pensais que c'était le kernel bloat le problème, ou les éventuels work-around pour les divers bugs de sécurité de processeur Intel voire AMD (encore que sur alix, avec un AMD Géode, je n'ai pas évalué ça). Mais comme j'ai dit, je peux vivre avec une telle dégradation due Í systemd. Et je m'en fiche un peu, dans 5 ans, ça sera quelque chose d'autre que Debian aura mitonné, peut-être, et ça sera aussi bien intégré, comme d'habitude avec Debian (enfin, il faut attendre 1 version intermédiaire :->) Et une fois qu'on s'est (temporairement) habitué Í diverses petites choses casse-pied comme le fait qu'il faut faire un daemon-reload, que certaines fonctionnalités ne marchent plus ou autre, on s'habitue assez rapidement.
JC_Et
Le 24/12/2020 Í 13:19, Alf92 a écrit :
Alf92 (le 23/12/2020 Í 15:01:31) :
question subsidiaire : le support de LM 9.3 est assuré jusqu'en avril 2023. je suppose donc que les mises Í jour cesserons. Ok. mais pourrai-je après cette date encore installer des programmes issus de dépots ?
up
prends une _Debian_ 10 (par exemple( tu auras une durée couverte par Debian jusqu’Í juin 2024 et ensuite une couverture LTS de + 2ans Note la Debian 9 Stretch est en LTS jusqu'au 30 juin 2022 https://wiki.debian.org/fr/LTS/Stretch -- J-C Et.
Le 24/12/2020 Í 13:19, Alf92 a écrit :
Alf92 (le 23/12/2020 Í 15:01:31) :
question subsidiaire : le support de LM 9.3 est assuré jusqu'en avril 2023.
je suppose donc que les mises Í jour cesserons. Ok.
mais pourrai-je après cette date encore installer des programmes issus de
dépots ?
up
prends une _Debian_ 10 (par exemple( tu auras une durée couverte par
Debian jusqu’Í juin 2024 et ensuite une couverture LTS de + 2ans
Note la Debian 9 Stretch est en LTS jusqu'au 30 juin 2022
https://wiki.debian.org/fr/LTS/Stretch
question subsidiaire : le support de LM 9.3 est assuré jusqu'en avril 2023. je suppose donc que les mises Í jour cesserons. Ok. mais pourrai-je après cette date encore installer des programmes issus de dépots ?
up
prends une _Debian_ 10 (par exemple( tu auras une durée couverte par Debian jusqu’Í juin 2024 et ensuite une couverture LTS de + 2ans Note la Debian 9 Stretch est en LTS jusqu'au 30 juin 2022 https://wiki.debian.org/fr/LTS/Stretch -- J-C Et.
Alf92
JC_Et (le 24/12/2020 Í 14:45:51) :
Le 24/12/2020 Í 13:19, Alf92 a écrit :
Alf92 (le 23/12/2020 Í 15:01:31) :
question subsidiaire : le support de LM 9.3 est assuré jusqu'en avril 2023. je suppose donc que les mises Í jour cesserons. Ok. mais pourrai-je après cette date encore installer des programmes issus de dépots ?
prends une _Debian_ 10 (par exemple( tu auras une durée couverte par Debian jusqu’Í juin 2024 et ensuite une couverture LTS de + 2ans
certes mais quid des programmes dans les dépots après juin 2024 ?
Note la Debian 9 Stretch est en LTS jusqu'au 30 juin 2022 https://wiki.debian.org/fr/LTS/Stretch
JC_Et (le 24/12/2020 Í 14:45:51) :
Le 24/12/2020 Í 13:19, Alf92 a écrit :
Alf92 (le 23/12/2020 Í 15:01:31) :
question subsidiaire : le support de LM 9.3 est assuré jusqu'en avril 2023.
je suppose donc que les mises Í jour cesserons. Ok.
mais pourrai-je après cette date encore installer des programmes issus de
dépots ?
prends une _Debian_ 10 (par exemple( tu auras une durée couverte par
Debian jusqu’Í juin 2024 et ensuite une couverture LTS de + 2ans
certes
mais quid des programmes dans les dépots après juin 2024 ?
Note la Debian 9 Stretch est en LTS jusqu'au 30 juin 2022
https://wiki.debian.org/fr/LTS/Stretch
question subsidiaire : le support de LM 9.3 est assuré jusqu'en avril 2023. je suppose donc que les mises Í jour cesserons. Ok. mais pourrai-je après cette date encore installer des programmes issus de dépots ?
prends une _Debian_ 10 (par exemple( tu auras une durée couverte par Debian jusqu’Í juin 2024 et ensuite une couverture LTS de + 2ans
certes mais quid des programmes dans les dépots après juin 2024 ?
Note la Debian 9 Stretch est en LTS jusqu'au 30 juin 2022 https://wiki.debian.org/fr/LTS/Stretch
JC_Et
Le 24/12/2020 Í 14:53, Alf92 a écrit :
certes mais quid des programmes dans les dépots après juin 2024 ?
alors si tu as s bien lu la page LTS donnée pour Debian 9 "..Paquets pris en charge Tous les paquets sont pris en charge Í l'exception des jeux (tous les paquets de la section jeux) et ceux mentionnés comme non pris en charge dans le paquet debian-security-support. .." -- J-C Et.
Le 24/12/2020 Í 14:53, Alf92 a écrit :
certes
mais quid des programmes dans les dépots après juin 2024 ?
alors si tu as s bien lu la page LTS donnée pour Debian 9
"..Paquets pris en charge
Tous les paquets sont pris en charge Í l'exception des jeux (tous les
paquets de la section jeux) et ceux mentionnés comme non pris en charge
dans le paquet debian-security-support. .."
certes mais quid des programmes dans les dépots après juin 2024 ?
alors si tu as s bien lu la page LTS donnée pour Debian 9 "..Paquets pris en charge Tous les paquets sont pris en charge Í l'exception des jeux (tous les paquets de la section jeux) et ceux mentionnés comme non pris en charge dans le paquet debian-security-support. .." -- J-C Et.
Sergio
Le 23/12/2020 Í 00:48, Alf92 a écrit :
Bjr, J'ai un (vieux) PC dont le lecteur de DVD est HS et pour lequel le boot sur USB n'est pas possible. Puis-je faire l'nstall de Linux Mint (v19.3 car en 32bots...) sur un autre PC puis transferer le DD sur un ce vieux PC ? Si oui y aura-t-il une nouvelle découverte des périphériques + installation des bons drivers ?
J'ai fait ça (avec succès) avec un Ubuntu de l'époque (LinuxMint n'existait pas), du temps o͹ Ubuntu ne se prenait (pas encore) pour Windows... sans systemd ni autre nuisance... Je me souviens qu'avec Windows (XP), ça n'avait pas marché... -- Serge http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 23/12/2020 Í 00:48, Alf92 a écrit :
Bjr,
J'ai un (vieux) PC dont le lecteur de DVD est HS et pour lequel le boot
sur USB n'est pas possible.
Puis-je faire l'nstall de Linux Mint (v19.3 car en 32bots...) sur un
autre PC puis transferer le DD sur un ce vieux PC ?
Si oui y aura-t-il une nouvelle découverte des périphériques +
installation des bons drivers ?
J'ai fait ça (avec succès) avec un Ubuntu de l'époque (LinuxMint n'existait pas), du temps o͹ Ubuntu ne se prenait (pas encore) pour Windows... sans systemd ni autre nuisance...
Je me souviens qu'avec Windows (XP), ça n'avait pas marché...
--
Serge http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Bjr, J'ai un (vieux) PC dont le lecteur de DVD est HS et pour lequel le boot sur USB n'est pas possible. Puis-je faire l'nstall de Linux Mint (v19.3 car en 32bots...) sur un autre PC puis transferer le DD sur un ce vieux PC ? Si oui y aura-t-il une nouvelle découverte des périphériques + installation des bons drivers ?
J'ai fait ça (avec succès) avec un Ubuntu de l'époque (LinuxMint n'existait pas), du temps o͹ Ubuntu ne se prenait (pas encore) pour Windows... sans systemd ni autre nuisance... Je me souviens qu'avec Windows (XP), ça n'avait pas marché... -- Serge http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
jp willm
Le 24/12/2020 Í 14:17, Nicolas George a écrit :
Il y a quelques personnes qui ont des critiques valides et intéressantes et qui savent de quoi elles parlent, mais c'est rare. Le reste, c'est surtout des vieux grincheux qui ont inconsciemment peur que leurs connaissances durement acquises deviennent obsolètes et qui se retrouvent Í défendre un système qui était déjÍ moisi il y a des années.
Tu mets tous les init non systemd dans le même sac ? -- jp willm https://willms.pagesperso-orange.fr/ https://www.youtube.com/channel/UCJwHW5GwrK1fq16cxUoBOUw
Le 24/12/2020 Í 14:17, Nicolas George a écrit :
Il y a quelques personnes qui ont des critiques valides et
intéressantes et qui savent de quoi elles parlent, mais c'est rare. Le
reste, c'est surtout des vieux grincheux qui ont inconsciemment peur que
leurs connaissances durement acquises deviennent obsolètes et qui se
retrouvent Í défendre un système qui était déjÍ moisi il y a des années.
Tu mets tous les init non systemd dans le même sac ?
Il y a quelques personnes qui ont des critiques valides et intéressantes et qui savent de quoi elles parlent, mais c'est rare. Le reste, c'est surtout des vieux grincheux qui ont inconsciemment peur que leurs connaissances durement acquises deviennent obsolètes et qui se retrouvent Í défendre un système qui était déjÍ moisi il y a des années.
Tu mets tous les init non systemd dans le même sac ? -- jp willm https://willms.pagesperso-orange.fr/ https://www.youtube.com/channel/UCJwHW5GwrK1fq16cxUoBOUw
