Bug 1363664
| Summary: | Fails to find VG when Sil3132 controller is present after cryptroot unlocks enclosing LUKS | ||
|---|---|---|---|
| Product: | [Community] LVM and device-mapper | Reporter: | Xen <bugs> |
| Component: | lvm2 | Assignee: | LVM Team <lvm-team> |
| lvm2 sub component: | Other | QA Contact: | cluster-qe <cluster-qe> |
| Status: | NEW --- | Docs Contact: | |
| Severity: | medium | ||
| Priority: | unspecified | CC: | agk, bugs, heinzm, jbrassow, msnitzer, prajnoha, zkabelac |
| Version: | 2.02.122 | Flags: | rule-engine:
lvm-technical-solution?
bugs: needinfo? (bugs) rule-engine: lvm-test-coverage? |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Xen
2016-08-03 10:09:24 UTC
Oh and the disks load just fine: /dev/sde1: UUID="14DCC30ADCC2E558" TYPE="ntfs" PARTUUID="021460ee-01" /dev/sde2: UUID="5866C79466C770F4" TYPE="ntfs" PARTUUID="021460ee-02" sde 8:64 0 698.7G 0 disk ├─sde1 8:65 0 450M 0 part └─sde2 8:66 0 58.6G 0 part Maybe Grub passes the wrong parameters to the initrd. The BIOS likes to shift any attached disks to the front; but Grub2 finds the devices just fine (using "ls") and the boot failure also happens when no disks are present. I am sorry, I had to write this somewhere. However, just let me restate here in brevity: - on this system, there is a typical LUKS container inside a partition - Inside the LUKS container is a typical PV containing typical LVs. - When the Sil3132 controller is merely _present_ in the system on booting and unlocking the crypt container in the initrd the PV (VG) appears to not get activated. I am not entirely keen on what exactly I meant when I wrote this report. Sorry for the confusion. It appears as though additional devices (such as /boot on the same VG as /) cannot be loaded. Something is directly referencing the VG which I assume is going to be for either root (/dev/vgname/root as it were) or boot (/dev/vgname/boot) as it were. The error came pretty soon though and I assume it was the root device that was not getting loaded. Meaning the error would be in the initrd. All I know is that in /usr/share/initramfs-tools/scripts/local-top/lvm2 a call is made merely for "lvm lvchange -aay -y --sysinit <root device>" and nothing else. I also know in the resulting initrd the ORDER files specifies cryptroot _after_ lvm2. That means that after cryptroot is run, lvm2 is not run again, and it must be activated in some other way (udev? I don't know these things really). The cryptroot file (script) explicitly sets itself last in the order by causing all other scripts in the directory to be prereqs. That's not really helpful if I want to force an activation at a later stage. All I can see is that cryptroot will check for LVM2_member using blkid and then call vgscan and vgchange -a y --sysinit. The reluctance that exists in the lvm2 script to not activate everything; is not heeded here, or found here, it will just activate all VG. Apparently something goes wrong there that doesn't go wrong when booting a system that doesn't use LUKS. So I assume the difference would be in the order; in the booting system lvm2 script will handle the activation of the root device; in the nonbooting system, cryptroot script will handle the activation of the root device; the difference is also that cryptroot script activates everything (but might fail) while the lvm2 script only activates root (and might succeed). That's the only analysis I can make at this point. The weird thing is that opening the LUKS from a running system gives no problems. Then again, cryptsetup may not depend on a manual call, but on dmeventd or udev instead. The question is what will happen if I change the cryptroot script to use a root-only activation call such as lvm lvchange -aay --sysinit $NEWROOT or even to skip the blkid test, so I guess that is the next step in testing this. Regards. |