Bug 5806

screenshot showing the problem: http://i.imgur.com/QxuGH.jpg

Thanks for the bug report.
Could you provide the file /root/drakx/report.bug.gz as an attachment ?
If you don't have the file, you can switch to console 2 (by pressing 'Ctrl-Alt-F2') during installation, put a floppy in floppy drive or plug a USB key/stick and type: 'bug' then press Enter. It will put report.bug on the floppy/key.

Keywords: (none) => NEEDINFO

Created attachment 2278 [details]
report.bug file as requested by Manuel

gparted display of partitions: http://i.imgur.com/J1htw.jpg

I tried another install using mga2RC dual-arch CDrom. Failed in same way.
I used 'Ctrl-Alt-F2' to get a shell and was able to manually mount the D: partition with:
mount -t ntfs /dev/sda2 /mnt/media/win_d

following was displayed:
mount: mount warning: /mnt/media/win_d seems to be mounted read-only

Looking at the output from 'mount' command it looks like the first NTFS partition was mounted in the same way  (as the D: partition):

/dev/sda1 on /mnt/media/win_c type ntfs (ro,relatime,uid=0,gid=0, fmask=0177,dmask=077,nls=default,errors=continue,mft_zone_multiplier=1)

/dev/sda2 on /mnt/media/win_d type ntfs (ro,relatime,uid=0,gid=0, fmask=0177,dmask=077,nls=default,errors=continue,mft_zone_multiplier=1)

Please post or attach the output of blkid.

CC: (none) => davidwhodgins

Output from 'blkid' command as requested by Dave: http://i.imgur.com/8eZ1T.jpg

'blkid' output (copied via usb):

/dev/sr0: LABEL="Mageia-2-rc" TYPE="iso9660" 
/dev/sda1: LABEL="SATA 40gb" UUID="B690C81490C7D8CF" TYPE="ntfs" 
/dev/sda2: LABEL="SATA 8gb" UUID="B690C81490C7D8CF" TYPE="ntfs" 
/dev/sda5: UUID="ca6a59a4-6032-4a59-97ae-78a1c6eb17df" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda6: UUID="604bed44-1d31-11d7-8b1d-0925b764a2c7" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda7: UUID="e0dce2fa-cfbd-4c8b-9d94-be2975db799c" TYPE="ext2" 
/dev/sda8: UUID="61a79422-1d31-11d7-abf8-4f33fe204b78" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda9: UUID="63ce9552-1d31-11d7-9ca2-ff15ff3d8b06" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda10: UUID="682705e4-1d31-11d7-8fab-5fc8230a670c" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda11: UUID="f9c0889b-b37e-4f8d-a58b-3f6453c07a83" TYPE="crypto_LUKS" 
/dev/sda12: UUID="08248d49-de74-4d14-a4c6-d88753f7b82e" TYPE="crypto_LUKS" 
/dev/sda13: UUID="4d59b00a-a11f-4bab-90d0-2836be1e8895" TYPE="crypto_LUKS" 
/dev/loop0: TYPE="squashfs" 
/dev/mapper/crypt_sda11: UUID="de805aa1-e90b-405c-8600-5a2615983747" TYPE="swap" 
/dev/mapper/crypt_sda12: UUID="0435f11d-d687-4464-bbee-e63100523e88" TYPE="ext4" 
/dev/mapper/crypt_sda13: UUID="02f60f06-8f36-415e-9526-5e749a9f763c" TYPE="ext4" 
/dev/sdb: LABEL="ADATA" UUID="34E6-8FE0" TYPE="vfat"

ah! So, why do the two NTFS partitions have the same UUID="B690C81490C7D8CF" ?

(In reply to comment #9)
> ah! So, why do the two NTFS partitions have the same UUID="B690C81490C7D8CF" ?

That will definitely cause problems.  Most likely one of the partitions was
created using dd as a copy of the other one, and then resized.

See http://ubuntuforums.org/showthread.php?t=1240146 for an article on how
to change one of the uuids.  Unfortunately, it requires using a hex editor,
rather than a command, so be careful.  An easier alternative would be to
copy the contents to backup, reformat the partition (don't delete/create,
just reformat with mkfs.ntfs), then restore the data.

So, it's not clear to me why I have two NTFS partitions with the same UUID.

What I am wondering is: it would be useful to be able to indicate to the installer that a partition should not be mounted. I tried setting automount=no in the advanced options but that did not seem to have the right effect: the installer failed at the attempted mount of the 2nd NTFS partition.

In researching for work-around solutions I found a couple of interesting ones.

One is to use dd to replace the UUID and this is discussed here:
https://www.linux.com/community/blogs/133-general-linux/289198

The other is that the gparted liveCD (http://gparted.sourceforge.net/livecd.php)
includes an option for "New UUID" but this could be tricky as I understand that Windoze uses the UUID as part of the Windoze activation.

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Hello Marja,

This bug was originally filed on the pre-release version of Mageia 2.

I believe it has not been fixed by anyone.
So, I expect it is still an issue in Mageia 2.

Unfortunately, in my attempts to get Mageia 2 installed I tried to modify the UUID on the 2nd NTFS partition (D:) to create a different UUID and now it seems broken and won't mount.

I can try to fix the 2nd partition and/or attempt to replicate the problem on another disk drive.

I think one way to fix this would be to modify the installer/partitioning tool so that in the event of one mount failure (which is what happened if a duplicate UUID is encountered) then the user should be offered the option to skip the mount and continue the install process.

TiA!

Cheers
Paul

changed from Cauldron to Mageia 2

Version: Cauldron => 2

Hmm, as this is failed against installer then it can't be Mageia 2. We can't change installer in stable version. Again, bad ping from Marja :(

Version: 2 => Cauldron

I agree with comment 13. Dracut should give the user a choice
to skip a failing mount, instead of dropping them to the
emergency shell, which most users won't have a clue of how to
use, unless it's a critical file system, such as /, /usr,
etc.

Summary: problem mounting 2nd of 2 Windows disk partitions (d:) near end of partitioning stage of install from i586 DVD of mageia 2 RC (latest copy 9th May) => Boot fails, if any filesystem fails to mount, such as when duplicate uuids are found.

It's rather a dracut issue than an installer one.
Though that's not what I would call a supported situation.

CC: (none) => thierry.vignaud
Assignee: bugsquad => mageia
Source RPM: (none) => dracut

@anyone

This is an *old* report of a *rare* situation.

Please review whether this needs to remain open, since nothing has happened under it for 2+ years, I think.

Alternatively, please close a.s.a.p. as resolved -> old.

Thanks.

Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information.

Closing as OLD.

Status: NEW => RESOLVED
CC: (none) => nic
Resolution: (none) => OLD