https://bugzilla.novell.com/show_bug.cgi?id=634681 https://bugzilla.novell.com/show_bug.cgi?id=634681#c0 Summary: Intel ICH10R / 82801JIR, md raid, LVM encrypted root creates unbootable system. Classification: openSUSE Product: openSUSE 11.3 Version: Final Platform: x86-64 OS/Version: openSUSE 11.3 Status: NEW Severity: Critical Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: edward.cullen@hp.com QAContact: jsrain@novell.com Found By: --- Blocker: --- User-Agent: Opera/9.80 (X11; Linux x86_64; U; en-GB) Presto/2.6.30 Version/10.60 During setup of an HP z600 workstation, configured with RAID 0, YaST will notify the user of an 'md comptible RAID' device, asking if md should be used to manage said device. Doing so makes LVM-based partitioning with encryption unusable. Reproducible: Always Steps to Reproduce: 1. Configure RAID 0 in the ICH10R setup. 2. Begin the installation. 3. When prompted to use md to manage the RAID, select 'yes'. 4. Create a /boot partition on the MD device - /dev/mdXXXp1 5. Create an encrypted LVM partion on the MD device - /dev/mdXXXp2 6. Create an LVM volume group in the LVM partition. 7. Create a root and a swap partition in the LVM volume group. 8. Complete setup. Actual Results: On reboot, MD will be started. There will then be repeated errors about being unable to find the LVM volume group, followed by the boot.crypto / LUKS unlock partition prompt. It will NOT be possible to unlock the partition, making booting the system impossible. Expected Results: LUKS prompts for password to unlock the partition and the system boots correctly. This issue is particularly vexing, as YaST itself is able to correctly detect, unlock and mount the partition setup! (E.g. if one re-runs the installation). Having done some poking around, I believe the issue is with the order of init scripts. boot.crypto-early starts before md and LVM. boot.crypto starts after md and LVM. There are two solutions that I believe are viable: 1. If md RAID is used, do NOT allow encrypted LVM partitions. 2. Modify boot.* scripts to reflect the order used by YaST during installation. Clearly, option 2 would be the better solution. This would require the following order of startup: 1. start md 2. unlock LVM partitions 3. start LVM partitions 4. unlock remaining partitions On thinking about this problem, I do not see it as unreasonable for the following reasons: 1. It is the way YaST works during setup. 2. md can be seen as a low-level (hardware) device, whereas LUKS/LVM/DM are software devices; one generally initialises hardware before software. 3. YaST creates a tree showing the volume hierarchy, so working out exactly in which order partitions need to be setup should be trivial (creating the tree is the hard part...) Marked as critical because: 1. Allows creation of a configuration that will always fail. 2. Potential to break a working system. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.