( Take this as a question/idea ) Description of problem: We seem to lack a reliable boot repair functionality The installer repair function (selectable from its boot menu) completely fail my encrypted LVM systems. It sometimes work to instead choose to install, selecting manual partitioning and reuse all partitions, then just have it proceed. Sometimes that fouls up: Bug 22782 - Installer/urpmi get stuck in loop evaluating already installed packages -> Repair impossible! Maybe partly because installed packages are newer than available? Bug 22783 - Make it possible to add all kind of repo media (i.e testing) during install I suggest some dialogue after partitioning asking if it should directly try to restore grub, without going through evaluating everything installed. Maybe it need to see some of what is installed, but do it really need to go through and check all dependencies?! When user can get to grub menu there are kernel options etc to reach some working console, but when grub does not even start on a pesky EFI machine which also seem to wreck it again later... Argh! Had to reinstall. Bug 22552 -- OR --- As an alternative make the repair function work better but i think that is hard; I do think it need user guidance when partitioning is advanced, thus my suggestion to just slightly tweak main installer instead.
If you're trying to repair GRUB2, you should be running the installer in Rescue mode (enter "rescue" at the boot prompt). Have you tried that? Does it work well for what you're trying to do? Years ago our rescue was great, then it started getting buggier, failing to mount your system partition (and bind mount /proc, /sys, and whatever else) correctly, but restoring the boot loader with LILO or GRUB still worked well. I've not tried it with GRUB2 or encrypted partitions. At work with RHEL7's rescue mode I had to mounted the encrypted partitions manually.
Do not remember details but i choosed repair from installer boot menu and it rather quickly skribbled more than a screen full of failed attempts to find partitions. It seemed so completely lost in finding partitions i did not want to try to push it further, as i ave never used it before and it is a production system i must not destroy. Maybe i could have commanded cryptsetup manually, etc, but thought better safe than sorry - i have seen others recommend to use the installer without installing anything, just reusing partitions and proceed, and i think i have done that in the past and succeeded once. Unfortunately that method bombed now as said, so i was thinking of whether checking dependencies and other stuff could be skipped.
For me, "upgrading" the install with the broken grub, using a classical iso with the same version as the broken install, always worked fine to fix the issue. Haven't needed it in the past few years, though.
Assignee: bugsquad => mageiatoolsCC: (none) => marja11Source RPM: (none) => drakx-installer-rescue
Yes, *should* have worked. It is not the first time urpmi chokes for somebody, so i think it would be good if that step could be skipped when the mission is to restore grub. If urpmi chokes, it is easier to fix after grub is restored so the system can boot. It could even be that the installed system have switched to dnf.
Well, but you saw the screens in the partitioning steps, I've never seen those when selecting to Upgrade in this screen http://doc.mageia.org/installer/6/en/content/selectInstallClass.html Are you saying that did _not_ choose "Install" in that screen, but to upgrade the existing install of which grub2 was broken?
Ah you kind of hit the problem it Marja, thanks! I checked again now on another system: it do not display that screen when booting on such set-up! => Bug 22794 - Installer fail to offer upgrade when partitioning use encryption (at least encrypted LVM) The rescue system fails for similar reason i guess: => Bug 22795 - The rescue system fails when system use LUKS (at least when on LVM inside it)
Believing fixing either 22794 or 22795 would be enough solution maybe we can close this bug. Just one thing: I think it would be good to add to the screen http://doc.mageia.org/installer/6/en/content/selectInstallClass.html that § Upgrade can be used also to just repair boot, grub § And the user then should just click trough until the end and let it reboot Something like that. And advertide the repairing functionality in the manual, maybe as a separate chapter heading "Repairing an unbootable system"
CC: (none) => thierry.vignaudSummary: Make installer easier/better to use for only repairing grub2 => Make installer easier/better to use for only repairing grub2 when using encrypted LVM
"Make installer easier/better to use for only repairing grub2 when using encrypted LVM" is basically covered by bug #22795 which is now fixed in git. About upgrading LUKS, I've commented in bug#22794 So let's close this one *** This bug has been marked as a duplicate of bug 22795 ***
Resolution: (none) => DUPLICATEStatus: NEW => RESOLVED