Bug 20309 - drakx-rescue required reboot upon boot loader install failure
Summary: drakx-rescue required reboot upon boot loader install failure
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-18 08:51 CET by Bit Twister
Modified: 2020-03-20 16:21 CET (History)
2 users (show)

See Also:
Source RPM: drakx-installer-rescue
CVE:
Status comment:


Attachments

Description Bit Twister 2017-02-18 08:51:09 CET
Description of problem: 6_sta2

drakx-rescue required reboot upon boot loader install failure. When you pick a partition for boot loader re-install and it fails to do the boot loader install, you can not get back to picking another desired partition.

You have to re-boot the rescue media to get back to pick another partition for boot loader re-installation.

I was attempting to create a grub2 entry for booting Mageia-6-sta2-x86_64-DVD.iso 

My /etc/grub.d/20a_DVD script would allow /boot/grub2/grub.cfg to be generated but somehow grub.cfg was corrupt or incomplete.

update-grub2 completed and indicated no problem.
grub2-install /dev/sda indicated install was OK.
Next boot indicated some i386 problem and I was forced to do a boot loader re-install.

I have added scripts to /etc/grub.d/ to do boot installs using labels.
So I reinstall mga5 boot loader, booted it, copied my /mga5/boot/grub2/grub.cfg to /cauldron/boot/grub2/grub.cfg and then was then able to boot cauldron.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

Can only guess at this point that steps 10-12 causes rescue bootloader to display my problem.

1. format another partition for a clone of current install.
2. mkdir /clone
3. add clone to /etc/fstab
4. clone the install onto new partition
5. modify clone's /etc/fstab and /boot/grub2/grub.cfg to use /clone's UUID 
6. boot the clone
7. verify you are on/in the clone partition
8. update-grub2
9. grub2-install
10. head -19 /boot/grub2/grub.cfg > /boot/grub2/grub.cfg_broke
11. mv /boot/grub2/grub.cfg /boot/grub2/grub.cfg_works
12. cp /boot/grub2/grub.cfg_broke /boot/grub2/grub.cfg
13. very boot fails
14. Boot rescue mode install boot loader.
15. pick clone partition which should fail
16. try to get back to select "install" partition.

Note that you might have a slight problem immediately knowing which partition is the install and which is the clone.

Any chance of getting the code to show media label if there is one?
Take my setup for example

$ blkid -s device -s LABEL 
/dev/sda1: LABEL="mga6"
/dev/sda2: LABEL="mga4"
/dev/sda3: LABEL="mga5"
/dev/sda4: LABEL="cauldron"
/dev/sdb3: LABEL="hotbu"
/dev/sdb4: LABEL="cauldron_bkup"
/dev/sdb6: LABEL="net_ins"

cauldron, mga6, cauldron_bkup and net_install all are at the same release so I have to keep a hard copy of which is which in the event I have to use rescue to reinstall boot loader.
Bit Twister 2017-02-18 08:52:58 CET

Keywords: (none) => 6sta2

Marja Van Waes 2017-02-18 20:50:38 CET

CC: (none) => marja11
Assignee: bugsquad => mageiatools

Comment 1 Thierry Vignaud 2020-03-20 16:21:01 CET
err, actually you could:
- go to console
- umount everything under /mnt (/sys, /proc, /dev + any split partition such as /home or whatever)
- then umount /mnt itself
- rerun rescue-gui
And voila

About "Any chance of getting the code to show media label if there is one?", well if you use LABEL= in /etc/fstab, those would be displayed.
The same if you use UUID= but of course that's slightly less readable…

CC: (none) => thierry.vignaud


Note You need to log in before you can comment on or make changes to this bug.