Discussion :

[Paul_Le_Heros]

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)…

[Christophe]

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

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

[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.

[Paul_Le_Heros]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[disedorgue]

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 ?

[Paul_Le_Heros]

Voici la situation actuelle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

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

SSD_Green est mon système "courant".

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

WD2_s2_sys

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

Je ne comprends pa la question :-)

...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.

[Paul_Le_Heros]

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.

[Paul_Le_Heros]

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é…