Description of problem: Deleting LVM does not lead to writing changes into disk immediately. If LVM deleted and then another one created, it can produce corrupted partition inside LVM. If root partition inside this new LVM, the system won't boot and even root partition cannot be mounted. Installation produces no errors, all seems fine until system tries to boot. This also can happen on system reinstall, with deleting LVM and creating new one. This only happens if new LVM is encrypted. I tested it in VirtualBox with EFI enabled. Version-Release number of selected component (if applicable): Mageia 5 LiveDVD KDE4 x86_64 How reproducible: Always. Steps to Reproduce: 1. Start installation, use clean disk. 2. Select custom partitioning. 3. Create ESP partition. 4. Create LVM partition. 5. Click on "Add to LVM". 6. Confirm writing changes into disk (!). 7. Click on "Remove from LVM". 8. Delete LVM partition. 9. Create new _encrypted_ LVM. 10. Confirm writing changes into disk (!). 11. Click on "Add to LVM". 12. Create root partition in vg. 13. Proceed installation. 14. After reboot enter password befor grub and on system start. 15. The boot should fail and drop into dracut debug shell. There is one workaround available. After step 8 proceed the installation and changes will be written into disk. Then return back and proceed from step 9. The system should boot. Reproducible: Steps to Reproduce:
Created attachment 6862 [details] Log from dracut
Whiteboard: (none) => MGA5TOOCC: (none) => thierry.vignaudVersion: 5 => CauldronBlocks: (none) => 15527
CC: (none) => pterjan
@ Nikita Can you still reproduce this issue with 6sta1 or later?
Keywords: (none) => NEEDINFOCC: (none) => marja11
I haven't checked it yet. Is it fixed?
CC: (none) => fri
(In reply to Nikita Krupenko from comment #3) > I haven't checked it yet. Is it fixed? I can't tell, but your checking it again would be a valuable contribution, if you can find time for it. Thanks!
Assignee: bugsquad => mageiatoolsTarget Milestone: --- => Mageia 6
Blocks: 15527 => (none)
Priority: Normal => High
Closing as OLD, because no one here confirmed having this issue since almost six years ago.
Resolution: (none) => OLDStatus: NEW => RESOLVED