Bug 15671

Summary: "Erase and use entire disk" fails to generate bootable system (was: Inconsistent classic installer installations RV Round 7)
Product: Mageia Reporter: Vladimir Zawalinski <vzawalin1>
Component: InstallerAssignee: Mageia Bug Squad <bugsquad>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Normal CC: marja11, vzawalin1
Version: Cauldron   
Target Milestone: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: 5RC
Source RPM: CVE:
Status comment:
Attachments: journalctl -s
report.bug.xz

Description Vladimir Zawalinski 2015-04-10 11:31:44 CEST
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:
Comment 1 Vladimir Zawalinski 2015-04-10 11:39:47 CEST
Created attachment 6227 [details]
journalctl -s
Comment 2 Marja Van Waes 2015-04-10 12:33:28 CEST
@ 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) => marja11
Summary: 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)

Marja Van Waes 2015-04-10 12:33:50 CEST

Attachment 6227 mime type: application/octet-stream => text/plain

Marja Van Waes 2015-04-10 12:34:57 CEST

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

Comment 3 Vladimir Zawalinski 2015-04-10 13:11:24 CEST
@ 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

Comment 4 Marja Van Waes 2015-04-10 13:59:27 CEST

(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 :-)
Comment 5 Vladimir Zawalinski 2015-04-10 16:58:22 CEST
(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.
Comment 6 Marja Van Waes 2015-04-10 17:05:03 CEST
(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?
Comment 7 Vladimir Zawalinski 2015-04-10 17:09:47 CEST
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.
Comment 8 Vladimir Zawalinski 2015-04-10 17:19:05 CEST
(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!
Comment 9 Vladimir Zawalinski 2015-04-11 08:05:33 CEST
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 => RESOLVED
Resolution: (none) => FIXED