| Summary: | Cauldron UEFI Vbox client netinstall no boot on reboot | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | William Kenney <wilcal.int> |
| Component: | Installer | Assignee: | Mageia tools maintainers <mageiatools> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | minor | ||
| Priority: | Low | CC: | mageia, marja11, thierry.vignaud, tmb |
| Version: | Cauldron | Keywords: | NEEDINFO |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: | UEFI Interactive Shell screen | ||
|
Description
William Kenney
2018-12-06 22:11:10 CET
Can you access the root partition of that install? If so: there's a directory with a very long hexadecimal name in /that/partition's/var/log/journal/ please run, as root, journalctl -D /path/into/that/hexadecimal/directory/ > journal.txt and then attach journal.txt to this bug report. (Compress the journal with "xz journal.txt" if it's too large to attach.) And also attach /root/drakx/report.bug.xz from that root partition. Assignee:
bugsquad =>
mageiatools (In reply to Marja Van Waes from comment #1) > Can you access the root partition of that install? Unfortunately not. I took some time today to go through this step by step. Using the newly released iso: Mageia-7-beta1-x86_64.iso 12/4/18 MD5: 0e7ccb8786cade01e006f5e675a6cd2b Vbox -> System -> boot priority Hard Disk then Optical -> Enable EFI unchecked First I executed a Legacy boot Vbox client install. All went well except for the known gremlins. It installs cleanly, boots to a working desktop, configures nicely then reboots back to a working desktop. Then it updates without a problem and boots back to a working desktop Same everything except Enable EFI is checked Install completes without problems, boots to a working desktop, configures nicely, MCC -> Local disks -> Manage disk partitions -> Shows the small FAT32 UEFI boot partiton. Upon reboot what it says is a UEFI Interactive Shell screen is presented and boot proceeds no further. I have attached a screen shot of that screen to this bug. I have run through this process on several VirtualBox machines and all of them act the same way. This should be an easily repeatable bug. Using this same iso on a USB stick on real hardware with the Bios set to UEFI only the install is clean, the UEFI FAT32 partition is created, after the install a usable Plasma desktop is presented. The desktop can be configured and the system reboots back to a working desktop without a problem. The install can then be updated and rebooted back to a working desktop. Created attachment 10533 [details]
UEFI Interactive Shell screen
Yeah, vbox uefi implementation is not really stable. And since uefi does not really gain you anything in a vm, I dont think we will waste any time on figuring this out, atleast for now CC:
(none) =>
tmb Thanks tmb for confirming. Lets leave this alone for now. Setting to Resolved WONTFIX for now. Status:
NEW =>
RESOLVED UEFI in VM is mainly for devs in order to test drakx on UEFI. For that, we can use virt-mananger: 1) before starting install, click on "Customize configuration before install" in step 5 of creating a VM 2) Then select "UEFI..." in the firmware pull-down menu in the "Overview" tab CC:
(none) =>
thierry.vignaud May I remind you of bug 23785 comment 2. For Mageia 7, there's another, easier, solution. When you get to the summary screen, reconfigure the bootloader and select rEFInd, not GRUB2. Then, at the next screen, check the box labelled "Install in /EFI/BOOT (workaround for some BIOSs)". The installed system should now boot without any problem. CC:
(none) =>
mageia |