Description of problem: When installing to an (external) disk, successful installation depends on partitioning method chosen. 'Erase and use' fails to generate bootable system, with fsck and mount problems, while doing the same operations piecemeal using 'custom' on the same disk creates a successful and bootable installation. Version-Release number of selected component (if applicable): MGA5 Classical iso 64 bit DVD Round 7 dated 9/4/2015 How reproducible: Consistent over two installations of each type. Steps to Reproduce: 1. Install above version 2. Choose 'Erase and use entire disk' 3. Reproducible: Steps to Reproduce:
Created attachment 6227 [details] journalctl -s
@ vlad Do you still have /root/drakx/report.bug.xz from the "Erase and use entire disk" install? If not, then please install again, using that option, and afterwards attach that file to this bug report.
CC: (none) => marja11Summary: Inconsistent classic installer installations RV Round 7 => "Erase and use entire disk fails to generate bootable system (was: Inconsistent classic installer installations RV Round 7)
Attachment 6227 mime type: application/octet-stream => text/plain
Summary: "Erase and use entire disk fails to generate bootable system (was: Inconsistent classic installer installations RV Round 7) => "Erase and use entire disk" fails to generate bootable system (was: Inconsistent classic installer installations RV Round 7)Whiteboard: (none) => 5RC
@ Marja The installer executed without any problem and completed normally. I only know how to get a report.bug using Ctl+Alt+F2, but this stops the installation process. Is there a way to resume the installer execution from the Alt+Ctl+F2 CLI? If there is, I am very happy to do this again. The attachment 6227 [details] is syslog from the booted system.
CC: (none) => vzawalin1
(In reply to Vladimir Zawalinski from comment #3) > @ Marja Hi Vlad :-) > > The installer executed without any problem and completed normally. I only > know how to get a report.bug using Ctl+Alt+F2, but this stops the > installation process. /root/drakx/report.bug.xz can be found on the root partition of the just installed Mageia, so in /path/to/that/root/partition/root/drakx/report.bug.xz > > Is there a way to resume the installer execution from the Alt+Ctl+F2 CLI? If > there is, I am very happy to do this again. Did you try to return to the installer screen with Alt+Ctrl+F7 ? I'm not sure what went wrong at which step, but do know for sure that switching to tty2 and typing "bug" while still in the partitioning step, is certainly _too_ early to get a useful log. Please get the full /root/drakx/report.bug.xz logs from after install. > > The attachment 6227 [details] is syslog from the booted system. Yes, thanks :-)
(In reply to Marja van Waes from Comment 4) Hi Marja, I repeated the install(erase and reuse) process to get a report.bug.xz and this time the installed os booted up with no problem. So, out of 3 erase and reuse installs, and one Custom install, two failed (both erase) and two worked (1 erase and 1 custom). So this proves nothing, probably just as well. I have attached the report.bug.xz for this, and thanks for your guidance.
(In reply to Vladimir Zawalinski from comment #5) > I have attached the report.bug.xz for this, and thanks for your > guidance. It isn't there, but that's no problem as the logs from a succesful install would most probably be of little use, anyway. Btw, had you added online media? If so, maybe something was pushed to cauldron between your first two tries and the last one, that fixed this?
Created attachment 6228 [details] report.bug.xz Submitting the report.bug.xz for the 'Erase and Use' for sdd1 even though this installation rebooted correctly to a working system.
(In reply to Marja van Waes from Comment 6) Attachment 6228 [details]!. No, I hadn't. I don't do this as a rule to restrict focus on the iso content as released, so all attempts were from the same source. I will try this again in the next couple of days, but for now, it is 0120!
Further to comment 5: I now don't think the installer partitioning option chosen has anything to do with this issue. The last two installs were by classical installer and since it cannot do anything with the raid array (just shields it from the partitioner) my on-raid Mageia vanished from the boot menu. I refreshed the Suse grub, but this time, the raid-mageia entry there would not boot (cannot find device uuid= xxx etc). So the classical bootloader installation must have done something unhelpful. This report is another duplicate of the various ones already existing about failure to reboot in UEFI after new installs. There are currently 4 linux systems + W8.1 on my laptop. Since Mageia reuses the /boot/EFI on SDA1 (W8.1 has its own separate disk and everything else it wants on sde), the last Mageia installation resets the grub menu (for Mageia, as Suse has its own separate directory in /boot/EFI). I have glanced over the errata wiki for M5 Cauldron, and there is material about what to do in these situations. I might close this bug now, and see how I go about fixing boot-failures as described there.
Status: NEW => RESOLVEDResolution: (none) => FIXED