Bug 16046

The final dot is too much
http://filebin.net/qi97bycx8b

A cople remarks:
1) You don't have to put a .xz file in a .zip one.
  it's already compressed, you won't gain anything
2) a 155kb file is not too big for our bugzilla

That's said, this test was done with an old ISO (Drakx v16.91 whereas we're currently at 16.101).
Please test a pre release ISO instead.

Keywords: (none) => NEEDINFO
CC: (none) => thierry.vignaud
Source RPM: (none) => drakx-installer-stage2-16.91

Created attachment 6654 [details]
report.bug.xz

Sorry I mixed up several files.
Here is the right one. I redid the installation to be sure and rebooted several times. That showed me that the emergency mode didn't showed up each time, it may happen that the boot is correct.

So closing as OLD?

Severity: critical => normal

I don't follow you, the last release (2015/05/27) starts half the time here.

Thierry reacted to "it may happen that the boot is correct" which can have several meanings. He thought you said the bug is maybe fixed, but you meant sometimes boot is fine, but at other times you get emergency mode.

You didn't reinstalled the system between the different reboot tries?

So if the same system, once installed, reboots OK only half the times, the issue is likely with dracut.
We needs you to attach a photo of the screen when you're asked about emergency mode?

Keywords: (none) => NEEDINFO
CC: (none) => mageia, tmb
Component: Installer => RPM Packages
Source RPM: drakx-installer-stage2-16.91 => dracut? kernel?

(In reply to Thierry Vignaud from comment #7)
> You didn't reinstalled the system between the different reboot tries?
> 
No

> So if the same system, once installed, reboots OK only half the times, the
> issue is likely with dracut.
> We needs you to attach a photo of the screen when you're asked about
> emergency mode?

As a problem with LiveDVD was solved disabling Windows fastboot, I though fastboot could be the problem also here. So after disabling fastboot I re-did the installation, it doesn't solve the problem, it always boots half the time but the behaviour is different, the error message is :
dracut warning: /sysroot has no proper rootfs layout, ignoring anr remmoving offending mount hook.
Dracut Warning: can't mountroot filesystem

Generating "/run/initramfs/rdsosreport.txt"
You might want to save "/run/initramfs/rdsosreport.txt" to a .....
...
Dropping to debug shell
dracut:#

Created attachment 6655 [details]
report quoted in previous comment

here is rdsosreport

We really need the photo of the whole messages!

Sorry, your attachment looks complete.
@André: can you attach your /root/drakx/report.bug.xz file?

@Colin, any idea?
The UUID is the /dev/sda5 (an ext4fs partition -- probably GPT)
The symlink /dev/disk/by-uuid/b3f4c56f-4738-47e8-86f8-83d27ce9b2e8 -> ../../sda5
looks good.
Fsck succeeded but mount failed????


EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
dracut: Checking ext4: /dev/disk/by-uuid/b3f4c56f-4738-47e8-86f8-83d27ce9b2e8
dracut: issuing e2fsck -a  /dev/disk/by-uuid/b3f4c56f-4738-47e8-86f8-83d27ce9b2e8
 sdb: sdb1
sd 5:0:0:0: [sdb] Attached SCSI removable disk
dracut: /dev/disk/by-uuid/b3f4c56f-4738-47e8-86f8-83d27ce9b2e8: clean, 15/624624 files, 77461/2493952 blocks
dracut: Mounting /dev/disk/by-uuid/b3f4c56f-4738-47e8-86f8-83d27ce9b2e8 with -o ro
EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
dracut Warning: /sysroot has no proper rootfs layout, ignoring and removing offending mount hook
dracut Warning: Can't mount root filesystem

argh report.bug.xz is already attached (too much wake-up-due-to-baby last night...)

Keywords: NEEDINFO => (none)

(In reply to Thierry Vignaud from comment #11)
> Sorry, your attachment looks complete.
> @André: can you attach your /root/drakx/report.bug.xz file?
> 
> @Colin, any idea?
> The UUID is the /dev/sda5 (an ext4fs partition -- probably GPT)
> The symlink /dev/disk/by-uuid/b3f4c56f-4738-47e8-86f8-83d27ce9b2e8 ->
> ../../sda5
> looks good.
> Fsck succeeded but mount failed????

> dracut: Mounting /dev/disk/by-uuid/b3f4c56f-4738-47e8-86f8-83d27ce9b2e8 with
> -o ro
> EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
> dracut Warning: /sysroot has no proper rootfs layout, ignoring and removing
> offending mount hook
> dracut Warning: Can't mount root filesystem

There are duplicate UUIDs on the system:

/dev/sda5: UUID="b3f4c56f-4738-47e8-86f8-83d27ce9b2e8" TYPE="ext4" PARTUUID="0b1a36c6-f47a-45cc-88c9-df0e7887cd62"
/dev/sda7: UUID="b3f4c56f-4738-47e8-86f8-83d27ce9b2e8" TYPE="ext4" PARTUUID="d1eda0ac-acf1-41e5-a0c4-b8fbbdb06529"

Looks like udev got the wrong one and changed link to sda7 or something and it doesn't look like a root FS.

If we know sda5 is the right one, try booting with root=/dev/sda5, then fixing the UUID on /dev/sda7 to be different. Alternatively if sda7 is the right one, then try root=/dev/sda7 and fix the sda5 UUID.

(likely caused by dd'ing sda5 to sda7 as a backup or something).

Anyway, I'd fix the duplicated UUIDs first then see if there are remaining problems after that.

NB, you can also use root=PARTUUID=0b1a36c6-f47a-45cc-88c9-df0e7887cd62 or root=PARTUUID=d1eda0ac-acf1-41e5-a0c4-b8fbbdb06529 but the ones I gave in the previous message are likely easier to type in ;)

OK then it's not a Mageia bug...

Summary: Classical DVD on UEFI system. Reboot fails despite a fine installation => Reboot fails despite a fine installation (b/c of duplicated UUIDs) [Classical DVD on UEFI system]

Just to make it clear, are we sure the duplicate UUIDs are not a consequence of using Mageia's tools?

May be a consequence of having used Alt+Ctrl+home during a previous test?
I could format sda5 and sda7 and make new install on both partitions.

(In reply to André DESMOTTES from comment #17)
> May be a consequence of having used Alt+Ctrl+home during a previous test?
> I could format sda5 and sda7 and make new install on both partitions.

This shouldn't cause duplicate UUIDs.

The only way a duplicate UUID at a filesystem level can realistically occur is if it was mirrored at some point (e.g. "dd if=/dev/sda5 of=/dev/sda7" or even just "cat /dev/sda5 >/dev/sda7" or similar)

But once the UUIDs are duplicated, our tools will try their best to maintain the UUID across formats. e.g. if you format a partition in the installer, it will take note of the current UUID, format it, then restore the UUID after.

We should probably add some safeguards that refuse to preserve UUIDs in the event of duplicates. Thierry, does that seem sensible?

Well, would that be the correct way.
Maybe it would be the other partition that should got a new UUID and we would just break the user setup.
There's no good solution here

(In reply to Thierry Vignaud from comment #19)
> Well, would that be the correct way.
> Maybe it would be the other partition that should got a new UUID and we
> would just break the user setup.

I would say if a user is actively formatting a partition, it should be the one we change when duplicates are detected. If they are not formatting a partition, we shouldn't fiddle with the UUID even if there are conflicts - or at least we should pop up a separate dialog warning of that situation - not take unilateral action!

> There's no good solution here

Indeed.

(In reply to Colin Guthrie from comment #20)
> (In reply to Thierry Vignaud from comment #19)
> > Well, would that be the correct way.
> > Maybe it would be the other partition that should got a new UUID and we
> > would just break the user setup.
> 
> I would say if a user is actively formatting a partition, it should be the
> one we change when duplicates are detected. If they are not formatting a
> partition, we shouldn't fiddle with the UUID even if there are conflicts -
> or at least we should pop up a separate dialog warning of that situation -
> not take unilateral action!

Assigning to mageiatools maintainers, for them to decide to go for Colin's suggestion, or not.

> 
> > There's no good solution here
> 
> Indeed.

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

Solved

Status: NEW => RESOLVED
Resolution: (none) => FIXED