Booter une copie initialement conforme.

Bonjour

Soit une partition système libellée "Origine" et une autre libellée "Copie". La seconde est la copie "conforme" (par rsync -a) de la première, et les deux sont installées dans un même ordinateur animé (depuis toujours) par Linux. Que faire pour pouvoir booter sur la seconde, tout en continuant de pouvoir booter sur l'originale (bien sûr) ? Je suppose qu'il doit être possible de :
- booter sur l'originale,
- modifier quelque chose du genre /etc/default/grub dans la copie,
- faire un CHROOT magique, puis
- réinstaller GRUB avec l'outil propre à la distribution.
Qu'en pensez-vous ?

À noter que ma machine ne connait pas l'EFI (rien dans le BIOS à ce sujet), bien qu'elle n'ait que 12 ans. Je le sais parce que c'est*“boot-repair” qui me l'a dit, et lui, ne connait que l'EFI. :-)

Si c'est possible, j'apprécierais beaucoup un soutien de votre part, surtout en magie (pour CHROOT)…

update-grub devrait te rajouter une entrée dans GRUB.

Essayes d'abord os-prober pour voir si tes deux OS sont bien vus.

vu le nom (sdc7), celle-ci est une partition logique et non primaire, donc on ne boot pas dessus.

On peut avoir au maximum 4 partition primaire depuis un disque, au delà , on a 3 primaire et une étendu dans laquelle on crée une ou plusieurs partitions logique et celles-ci ne sont destinée à ne contenir que de la données, elles ne sont pas bootables.

Citation:

---

Envoyé par disedorgue

vu le nom (sdc7), celle-ci est une partition logique et non primaire, donc on ne boot pas dessus.

On peut avoir au maximum 4 partition primaire depuis un disque, au delà , on a 3 primaire et une étendu dans laquelle on crée une ou plusieurs partitions logique et celles-ci ne sont destinée à ne contenir que de la données, elles ne sont pas bootables.

---

Oui, je sais cela.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

SSD-Green-p3:~$ sudo fdisk /dev/sdc   Bienvenue dans fdisk (util-linux 2.37.4). Les modifications resteront en mémoire jusqu'à écriture. Soyez prudent avant d'utiliser la commande d'écriture.   Le disque est actuellement utilisé — le repartitionner est probablement une mauvaise idée. Il est recommandé de démonter tous les systèmes de fichiers et désactiver (avec swapoff) toutes les partitions d'échange de ce disque.     Commande (m pour l'aide)*: p   Disque /dev/sdc*: 931,51 GiB, 1000204886016*octets, 1953525168*secteurs Modèle de disque*: WDC WD10EZEX-00B 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*: gpt Identifiant de disque*: 6E848593-0B8E-4B40-9E44-2A328D119AEF   Périphérique Début Fin Secteurs Taille Type /dev/sdc1 2048 214749183 214747136 102,4G Système de fichiers Linux /dev/sdc2 214749184 751620095 536870912 256G Système de fichiers Linux /dev/sdc3 751620096 762105855 10485760 5G Partition d'échange Linux /dev/sdc4 762105856 772591615 10485760 5G Partition d'échange Linux /dev/sdc5 772591616 772796415 204800 100M Système EFI /dev/sdc6 772796416 774893567 2097152 1G Amorçage BIOS /dev/sdc7 774893568 989640703 214747136 102,4G Système de fichiers Linux /dev/sdc8 989640704 1526511615 536870912 256G Système de fichiers Linux   Commande (m pour l'aide)*: q

---

Merci pour vos réponses. J'ai supprimé le message qui comportait trop d'erreurs, m'étant perdu dans mes propres affaires.

Pour la petite histoire, je rame depuis une semaine à cause d'une grosse sottise^* : il y a quelques années, j'ai acheté une carte graphique Nvidia GEFORCE GT 710 que je n'ai pas réussi à installer à l'époque et j'ai cru à ce moment-là qu'elle ne passait pas côté bios, et j'ai décidé de retenter l'affaire la semaine dernière, j'ai compris que le BIOS n'est pas clair et ai corrigé, mais j'ai trop fait confiance à Nvidia et n'ai pas pris mes précautions : l'erreur fût fatale pour mon système qui, après une longue compilation, n'a plus fonctionné du tout.
Ce fût l'occasion d'une mise à niveau de mon système, et c'est pourquoi j'ai tant de version de OpenSuse Leap. Dans mon cas, l'ultime Leap 16 ne convient pas du tout. Le système dont je me sers actuellement est Leap 15.6, installé sur un SSD acheté pour l'occasion. Pour l’anecdote, vous souvenez-vous que les SSD d'il y a quelques années étaient buggés et que leur firmware n'était modifiable que sur WindOverDose ? Je n'avais pas cet OS de censure à l'époque.
^* En fait je voulais utiliser la dernière version de KiCad (v8 ou 9) qui, chez OpenSuse, ne tourne que sur Tumbleweed… J'ai donc essayé Tumbleweed que j'ai vite rejeté !

Je me suis mélangé les pinceaux dans mon post, mais la question initiale est claire, je crois, et reste posée…
J'ai dû utiliser CHROOT une ou deux fois dans ma vie, et cette commande m'effraie un peu… Philippe Dpt35 dans le post #6 y fait référence. Peut-être aurais-je dû poser la question suivante : quelqu'un sur DVP a-t-il déjà effectué cette manœuvre ?

Pas tout compris:
-tu boot comment actuellement et où (quel partition) ?
-tu veux faire un chroot où (quelle partition) ?
-est-ce que les 2 partitions sont iso d'un point de vu os,noyaux,etc... ?

et que doit on obtenir au final ?

Voici la situation actuelle :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

part. (Label) -> linux GRUB EFI -> sda1 SWAP -> sda2 SSD_Green -> sda3 >--+ copiée… Leap 15.5 SSD_Green_2 -> sda4 | | sea500_sav -> sdb2 | <- système de secours Leap 15.4 sea500_sys -> sdb3 | var -> sdb4 | tmp -> sdb5 | 7_western_sav -> sdb7 | 8_western_rab -> sdb8 | WD2_p1_sys -> sdc1 | Leap 15.6 WD2_p1_home -> sdc2 | WD2_p1_var -> sdc3 | WD2_p1_tmp -> sdc4 | wdc_pserru -> sdb6 | WD2_s2_sys -> sdc7 <--+ … ici Leap 15.6 *** WD2_s2_home -> sdc8 EFI_petitDu -> sdd6 petitDur -> sdd7 Leap 15.6

---

Ceci est affiché par grub au second boot de SSD_Green (voir ci-dessous). L'info marquée ^*** est fausse !
1- J'ai rebooté sur mon système de secours
2- jai fait la copie :

Code:

---

1 2 3

mount /linux/WD2_s2_sys mount -o remount,ro /linux/SSD_Green rsync -a --delete /linux/SSD_Green /Linux/WD2_s2_sys

---

3- j'ai rebooté sur SSD_Green et réinstallé GRUB grâce à YAST (le gestionnaire de paquets de OpenSuse)
4- j'ai rebooté sur SSD_Green pour voir ce qu'offre GRUB et fait une photo de l'écran pour compléter le tableau ci-dessus.

Citation:

---

Envoyé par disedorgue

...
-tu boot comment actuellement et où (quel partition) ?

---

SSD_Green est mon système "courant".

Citation:

---

Envoyé par disedorgue

...
-tu veux faire un chroot où (quelle partition) ?

---

WD2_s2_sys

Citation:

---

Envoyé par disedorgue

...
-est-ce que les 2 partitions sont iso d'un point de vu os,noyaux,etc... ?

---

Je ne comprends pa la question :-)

Citation:

---

Envoyé par disedorgue

...et que doit on obtenir au final ?

---

Une offre de GRUB (à partir de la partition usuelle, soit "SSD_Green") proposant Leap 15.5 (et non 15.6 comme proposé plus haut) fonctionnelle.

^*** Je me demande d'où a tiré cette erreur affichée par GRUB !

J'espère ne pas avoir introduit d'erreur :-( avec toutes ces manipulations.

Vous vous demandez probablement pourquoi tant de disques et de partitions.

Un disque est faillible, mais prévient (généralement) avant de ne plus fonctionner du tout. J'ai donc "normalement" deux disques l'un pour la sauvegarde quotidienne du répertoire $HOME, la musique et le système de secours, et donc peu sollicité. L'autre divisé en deux parties presque identiques : une partie servant de sauvegarde de l'autre au moment d'un changement genre mise à niveau du système et autres installations spéciales, et l'autre servant 99% du temps J'avais complètement perdu confiance dans les SSD. J'en avais acheté trois ou quatre qui ont déconné de près ou de loin : rejet total, et je les ai donnés à un WindOverDosiste. Mais je viens de me ré-équiper… Je sais que les bons SSD sont du genre de ceux montés dans les serveurs et sont couteux, mais j'espère que celui installé fonctionnera quelques années. Les gains de temps sont sérieux mais le sont-ils au prix de la fiabilité ?

ᐸEDITᐳ: Autre*précision*il y a*ici et là, des partitions "var" et "tmp" qui ne sont pas utilisées, en lien avec ces SSDs mal nés. Pour éviter de les utiliser trop souvent en écriture et en plus de ne plus actualiser les nœuds du système de fichier à chaque accès (noatime), j'ai voulu monter ces répertoires sur un autre disque dur (et fiable, celui-là). J'ai eu des difficultés, et ai même consulté les experts de DVP à ce sujet ! (Ça date de septembre 2020, et c'est ici : Forum -> Systèmes -> Linux -> Administration système -> openSuse : montage /var et /tmp durant le boot ?). Il semble également me souvenir que si l'un des répertoires (/var ou /tmp) est trop petit, ça peut bloquer gravement le système à l'occasion de manœuvres ordinaires sur des fichiers bien gros et bien gras :-) ᐸ╱EDITᐳ


Les mises à niveau des différentes versions de Leap 15 se sont généralement bien passées. Je suis donc reparti de rien avec une version sûre pour "upgrader" ensuite. Et finalement une version fonctionnant correctement est installé sur le SSD, mais il me manque des logiciels. Je ne la lâche pas mais voudrais continuer les installations et les mises à niveau, voir passer à Leap 16. C'est pourquoi j'ai ajouté un disque 2.5_" ("petitDur :-) sur lequel je fais des essais.
Aujourd'hui, je voudrais faire une copie bootable du système installé sur le SSD.

Merci Philippe Ronflette
Merci chrtophe (-: Christophe)

Je reprendrai les posts ici, dès que j'aurais fait quelques essais, et préciserai "résolu" si tout c'est bien passé…