diskdrake claims that partitions in an LVM on LUKS previously formatted as e.g. XFS, JFS or swap are ext4. Consequently, it cannot mount them. To reproduce: 1. Create partition $fubar in an LVM on LUKS and format it as e.g. XFS, JFS or swap. Use any system or diskdrake in Mageia 3alpha1 to do that, but do *not* set a mount point. 2. Reboot into 3alpha1. 3. Start diskdrake, enter LUKS key. Partition $fubar will be shown as ext4. 4. Set mount point and click mount. Mounting fails. However, diskdrake behaves correctly after vgchange -ay and then either A. mount $fubar /somewhere, or B. blkid $fubar. I reproduced this in an installed, updated 3alpha1 on a physical i586 machine and in the 3alpha1 net installer in an x86_64 VM. Bug 4238 may be related, but there it seems blkid does not work, while this bug here occurs even though blkid works. Pascal, I'm sure policy does not allow me to assign bugs, but I hope it is okay in this case, because of what Marja said: https://bugs.mageia.org/show_bug.cgi?id=5505#c16
Whiteboard: (none) => 3alpha1
Reproduced in 3alpha2 net installer (vmlinuz/all.rdz from 02-Oct-2012).
Whiteboard: 3alpha1 => 3alpha2
Reproduced in 3alpha3 Live DVD Gnome x86_64, both in the installer selected in grub or in the live system's diskdrake. However, this same LVM on LUKS setup was created by the the 3alpha3 Dual CD. It installed itself into this LVM and works.
Source RPM: (none) => drakxtoolsWhiteboard: 3alpha2 => 3alpha3
CC: (none) => thierry.vignaud
CC: (none) => nelg
should this be a release blocker?
I rise the severity to critical as it trashed a luks partition in an install with a version of installer 2
CC: (none) => mageiaSeverity: normal => critical
There has been some work on diskdrake and the installer since then. Can you tell me if this bug is still valid in Mageia 4 and if possible in latest Cauldron ?
Keywords: (none) => NEEDINFO
Still valid with Mageia-4.1-LiveDVD-KDE4-x86_64-DVD.iso and Mageia-5-beta3-LiveCD-KDE4-en-i586-CD.iso.
Keywords: NEEDINFO => (none)Whiteboard: 3alpha3 => 3alpha3 MGA4TOO 5beta3
Setting release_blocker as it could affect DVD upgrades. Please verify the bug exists in 5 RC isos which should be released over the weekend. There have been many changes between beta3 and RC so things might have changed.
Priority: Normal => release_blocker
CC: (none) => mageia, tmbBlocks: (none) => 14069
CC: (none) => eeeemail
Bug still valid with Mageia-5-RC-LiveCD-KDE4-en-i586-CD.iso in Virtualbox. The blkid workaround I gave works when running the Live system (then either diskdrake from Control Center or the Live installer), but does not seem to get diskdrake to work when booting directly into the installer.
This was supposed to be fixed by those 2 commits: http://gitweb.mageia.org/software/drakx/commit/perl-install/diskdrake/interactive.pm?id=4974a4e759e2672b058d2c506b0f45d15ff762ee http://gitweb.mageia.org/software/drakx/commit/perl-install/diskdrake/interactive.pm?id=3980ebfd98fe7be5cce63bdfba0c567a052d996a But reading them: - It will not run vgchange -ay if not in installer - It will not update the view of the disks after doing so, so will not know there is a new LVM as this is done a few lines earlier
commit 1e292ec66fcad786a80a29af904b06f2f62ca2db Author: Pascal Terjan <pterjan@...> Date: Sun Apr 26 22:08:01 2015 +0000 Run vgchange before updating the list of LVMs, not after, and even if not in install (should help with mga#7578). --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=1e292ec66fcad786a80a29af904b06f2f62ca2db
I booted into the installer in Mageia-5-RC-LiveCD-KDE4-en-i586-CD.iso and manually applied the patch from Comment #11. This fixed my bug.
Closing.
Status: NEW => RESOLVEDResolution: (none) => FIXED