Forum-Francophone-LinuxMint.fr

Bonjour a tous,

Suite a mon précédent post: viewtopic.php?f=20&p=146878#p146878
ou j'avais un problème avec mon pc qui ne démarrait pas, j'ai change mon ssd de pc.

Le SSD est un Samsung SSD 860 de 500 GB et contient un Linux Mint 19 installe en LVM/LUKS (option 2 de l'installeur). J'ai rein fait de plus sur le disque et j'ai laisse le soin a l'installeur de tout prendre en charge.

Le pc a démarré mais m'a indique qu'il ne pouvait pas booter sur ce disque. J'ai du booter sur un liveUSB et monter le SSD depuis ma session Linux pour récupérer les données.. J'imagine que le pc a pas compris comment monter/ouvrir le SSD et ce qu'il fallait faire avec.

Maintenant, j'aimerai voir ... si c'est possible sans trop d'effort... pour réparer le boot pour pouvoir laisser en place mon SSD de 500GB et continuait a travailler sans avoir a passer par une liveUSB.

Grosso modo, par ou je commence ? Qu'avez vous besoin comme info pour mieux cerner mon sujet ?
A+
David

Salut Cyrille,

Suite a tes messages dans les sujets precedents, j'ai regarde pour re-installer le grub la ou il faut.
Donc d'abord, identifier les partitions: Donc on voit que j'ai un boot sur la partition sda1 (sdb1 est ma cle).
J'ai donc essaye de faire tout simplement: qui m'a retourne: Du coup, j'ai fait une recherche sur cet erreur, j'ai trouve ces liens:
https://doc.ubuntu-fr.org/grub-pc#reins ... rer_grub_2
http://ubuntuhandbook.org/index.php/201 ... wont-boot/
Donc j'ai essaye (en root): puis qui m'a donne ceci: je suis content je me dis que ca avance, donc plus qu'a mettre a jour le grub en faisant: et la je retrouve mon erreur...

Donc petite recherche et je trouve:
https://community.linuxmint.com/tutorial/view/2283
j'essaye et ca me fait toujours pareil

Donc je decide d'eteindre le systeme et de redemarrer pour voir... la suite au prochain episode

EDIT:
... bon ben ca a foire... toujours pas de disque bootable pour le systeme... je vais donc tenter l'option 2 .. effacer et reinstaller LM ...
tant pis, au moins j'aurais tente ma chance

Je passerais le sujet quand en "reinstallation" quand je l'aurais termine
A+
David

cyrille a écrit : mar. 9 avr. 2019 09:30 je passerai le tout en LEGACY pour éviter ce genre de soucis

+1000

ben je l'ai lu trop tard le message
Pas grave, j'y penserai pour la prochaine fois, de tout façon ça fait pas de mal de faire un peu de ménage de temps en temps

Bonjour David.

david37 a écrit : mar. 9 avr. 2019 23:00 ben je l'ai lu trop tard le message

laquel? celui sur "legacy" ou celui sur "boot-repair"? Parce que si je m'en souvient, je t'en avais parlé de boot-repair
Mais bon, comme de toute façon ça n'aurai pas fonctionné mieux que ta tentative (on va dire ça, hein ? ).

En te lisant ce que je vois c'est que le grub était bien à sa place sur sda1 qui est la partition de boot efi, de tenter de l'installer
sur sda, n'aurai pas permis de réparer.

Juste pour info. Ta réinstallation, tu l'as donc faite en eufi, mais avec LVM et LUKS aussi?
Je demande, car au delà du fait que d'installer en UEFI quand on a pas de dual boot W$ ne soit pas très judicieux (gestion
d'une partition "boot" en plus). LVM est très bien car vachement manipulable, mais il a un gros défaut qui dans ton cas
pourrait être très préjudiciable (vu que c'est ton outil de travail): Cf wiki-ubuntu :

Inconvénients de LVM
Si un des volumes physiques devient HS, alors c'est l'ensemble des volumes logiques qui utilisent ce volume physique qui sont perdus. Pour éviter ce désastre, il faudra utiliser LVM sur des disques raid par exemple.

(Ça c'est Arghlub, qui me l'a dit et il ne dit pas que des co****ries )
Exemple: sda2 "/home" HS, sda3 "datas" perdu
Question: Est ce une obligation d'être en LVM pour utiliser le chiffrage LUKS?

Je pose ces questions, car comme tu le sais je change sans arrêt mes disques durs d'ordis tous extrêmement différents
en matériel (intel ou amd) et en age (de 2005 à 2015), c'est donc une manipe que j'ai faite plusieurs dizaines de fois
sans aucun soucis. Surtout pour mon disque dur de test (lm 18.3 xfce, legacy, mbr, ext4) qui lui en a vu passer des ordis...
Et donc j'aimerai comprendre, alors que l'ordi est le même modèle (sauf la version du bios), pourquoi cela n'a pas marché
Ne connaissant pas LVM (Logical Volume Manager, ou gestionnaire de volumes logiques en français), je me suis (un peu)
renseigné et j'ai lu qu'il modifiait le MBR (comment, pourquoi?). N'en serait-ce point la la cause ?

Vu les risques à utiliser LVM et accessoirement à chiffrer un disque dur, vu que tes données et travaux sont importants pour
l'avenir de l'humanité, ne serait il pas plus raisonnable d'installer avec une méthode plus fiable, legacy, MBR ou GPT, sans chiffrage?
Sinon, j'ai lu aussi que si on utilise LVM, le mieux est d'être en RAID 1 ou 0+1 afin d'avoir une copie conforme de ton disque.
Mais cela nécessite l'achat d'un second disque...
Je pense que si cette préconisation est faite à plusieurs reprises sur le net (il n' y a pas de fumée sans feu), c'est qu'il doit
souvent y avoir des problèmes avec LVM.

En ce qui concerne le chiffrage, je comprends que tu doives préserver tes travaux, mais tu sais, si accès physique
à l'ordi ou simplement au disque dur, n'importe quel bébé hacker crack ton chiffrage en moins que rien.
Je pense qu'il existe des solutions plus "sécures" pour limiter l'accès à tes données et cela sans utiliser un gestionnaire
de volume logique. je dis "je pense", car je ne me suis jamais penché sur le problème, car tu sais bien que je n'ai
rien à cacher, moi (d'ailleurs j'ai démonté la porte des wc et les volets de ma chambre )

Alors t'en pense quoi, LVM ou pas LVM, la cause du non reboot sur l'autre ordi? (si tu n' y voit pas d’inconvénient, c'est
ton sujet, cette question peut s'adresser à d'autres aussi)

@ +