-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix multipath + LUKS and add a test #1728
Comments
And indeed, this is currently broken. So yeah, we definitely need to add coverage for this. |
In the multipath + LUKS case, `get_luks_uuid()` would incorrectly skip over the multipath partition containing the LUKS header because `is_dm_device()` returned true. The code eventually errors out when it gets to the disks backing the multipath device. The `is_dm_device()` check was added as part of 69b706d ("rootmap: handle filesystems with LUKS integrity") to correctly handle the LUKS integrity case in the Secure Execution path. There, the device right under the LUKS device is another crypt device mapper device used for integrity that we need to skip over. Instead of generically checking for a device mapper target, check specifically that it's a LUKS integrity target before deciding to skip. Part of: coreos/fedora-coreos-tracker#1728
In the multipath + LUKS case, `get_luks_uuid()` would incorrectly skip over the multipath partition containing the LUKS header because `is_dm_device()` returned true. The code eventually errors out when it gets to the disks backing the multipath device. The `is_dm_device()` check was added as part of 69b706d ("rootmap: handle filesystems with LUKS integrity") to correctly handle the LUKS integrity case in the Secure Execution path. There, the device right under the LUKS device is another crypt device mapper device used for integrity that we need to skip over. Instead of generically checking for a device mapper target, check specifically that it's a LUKS integrity target before deciding to skip. Part of: coreos/fedora-coreos-tracker#1728 Co-authored-by: Aashish Radhakrishnan <aaradhak@redhat.com> Co-authored-by: Gursewak Mangat <gursmangat@gmail.com> Co-authored-by: Michael Nguyen <mnguyen@redhat.com> Co-authored-by: Steven Presti <spresti@redhat.com>
coreos/coreos-installer#1473 should fix the underlying issue, but we should still add a test case in f-c-c for this. |
In the multipath + LUKS case, `get_luks_uuid()` would incorrectly skip over the multipath partition containing the LUKS header because `is_dm_device()` returned true. The code eventually errors out when it gets to the disks backing the multipath device. The `is_dm_device()` check was added as part of 69b706d ("rootmap: handle filesystems with LUKS integrity") to correctly handle the LUKS integrity case in the Secure Execution path. There, the device right under the LUKS device is another crypt device mapper device used for integrity that we need to skip over. Instead of generically checking for a device mapper target, check specifically that it's a LUKS integrity target before deciding to skip. Part of: coreos/fedora-coreos-tracker#1728 Co-authored-by: Aashish Radhakrishnan <aaradhak@redhat.com> Co-authored-by: Gursewak Mangat <gursmangat@gmail.com> Co-authored-by: Michael Nguyen <mnguyen@redhat.com> Co-authored-by: Steven Presti <spresti@redhat.com>
In the multipath + LUKS case, `get_luks_uuid()` would incorrectly skip over the multipath partition containing the LUKS header because `is_dm_device()` returned true. The code eventually errors out when it gets to the disks backing the multipath device. The `is_dm_device()` check was added as part of 69b706d ("rootmap: handle filesystems with LUKS integrity") to correctly handle the LUKS integrity case in the Secure Execution path. There, the device right under the LUKS device is another crypt device mapper device used for integrity that we need to skip over. Instead of generically checking for a device mapper target, check specifically that it's a LUKS integrity target before deciding to skip. Part of: coreos/fedora-coreos-tracker#1728 Co-authored-by: Aashish Radhakrishnan <aaradhak@redhat.com> Co-authored-by: Gursewak Mangat <gursmangat@gmail.com> Co-authored-by: Michael Nguyen <mnguyen@redhat.com> Co-authored-by: Steven Presti <spresti@redhat.com>
For testing this, you will want to use the karg $ cat tmp.bu
variant: fcos
version: 1.4.0
boot_device:
luks:
tpm2: true
$ cosa run --qemu-multipath --kargs 'rd.multipath=default' -c -m 4096 -B tmp.bu |
This service was needed in the past to make multipath + LUKS work well. The underlying bug seems to have been fixed now as I can no longer reproduce it in Fedora or RHEL 9.4. Conveniently, this also works around a bug in which that service would sometimes hang because of a bug[[1]] in systemd which is still outstanding in RHEL 9. Drop it. We don't have any tests for this yet. Multipath + LUKS currently doesn't work but should be fixed soon[[2]]. A test will be added as part of that work. [1]: systemd/systemd#29863 [2]: coreos/fedora-coreos-tracker#1728 Fixes: https://issues.redhat.com/browse/OCPBUGS-29325
This service was needed in the past to make multipath + LUKS work well. The underlying bug seems to have been fixed now as I can no longer reproduce it in Fedora or RHEL 9.4. Conveniently, this also works around a bug in which that service would sometimes hang because of a bug[[1]] in systemd which is still outstanding in RHEL 9. Drop it. We don't have any tests for this yet. Multipath + LUKS currently doesn't work but should be fixed soon[[2]]. A test will be added as part of that work. [1]: systemd/systemd#29863 [2]: coreos/fedora-coreos-tracker#1728 Fixes: https://issues.redhat.com/browse/OCPBUGS-29325
This service was needed in the past to make multipath + LUKS work well. The underlying bug seems to have been fixed now as I can no longer reproduce it in Fedora or RHEL 9.4. Conveniently, this also works around a bug in which that service would sometimes hang because of a bug[[1]] in systemd which is still outstanding in RHEL 9. Drop it. We don't have any tests for this yet. Multipath + LUKS currently doesn't work but should be fixed soon[[2]]. A test will be added as part of that work. [1]: systemd/systemd#29863 [2]: coreos/fedora-coreos-tracker#1728 Fixes: https://issues.redhat.com/browse/OCPBUGS-29325 (cherry picked from commit cc2e865)
This service was needed in the past to make multipath + LUKS work well. The underlying bug seems to have been fixed now as I can no longer reproduce it in Fedora or RHEL 9.4. Conveniently, this also works around a bug in which that service would sometimes hang because of a bug[[1]] in systemd which is still outstanding in RHEL 9. Drop it. We don't have any tests for this yet. Multipath + LUKS currently doesn't work but should be fixed soon[[2]]. A test will be added as part of that work. [1]: systemd/systemd#29863 [2]: coreos/fedora-coreos-tracker#1728 Fixes: https://issues.redhat.com/browse/OCPBUGS-29325 (cherry picked from commit cc2e865)
This service was needed in the past to make multipath + LUKS work well. The underlying bug seems to have been fixed now as I can no longer reproduce it in Fedora or RHEL 9.4. Conveniently, this also works around a bug in which that service would sometimes hang because of a bug[[1]] in systemd which is still outstanding in RHEL 9. Drop it. We don't have any tests for this yet. Multipath + LUKS currently doesn't work but should be fixed soon[[2]]. A test will be added as part of that work. [1]: systemd/systemd#29863 [2]: coreos/fedora-coreos-tracker#1728 Fixes: https://issues.redhat.com/browse/OCPBUGS-29325 (cherry picked from commit cc2e865)
This service was needed in the past to make multipath + LUKS work well. The underlying bug seems to have been fixed now as I can no longer reproduce it in Fedora or RHEL 9.4. Conveniently, this also works around a bug in which that service would sometimes hang because of a bug[[1]] in systemd which is still outstanding in RHEL 9. Drop it. We don't have any tests for this yet. Multipath + LUKS currently doesn't work but should be fixed soon[[2]]. A test will be added as part of that work. [1]: systemd/systemd#29863 [2]: coreos/fedora-coreos-tracker#1728 Fixes: https://issues.redhat.com/browse/OCPBUGS-29325 (cherry picked from commit cc2e865)
This service was needed in the past to make multipath + LUKS work well. The underlying bug seems to have been fixed now as I can no longer reproduce it in Fedora or RHEL 9.4. Conveniently, this also works around a bug in which that service would sometimes hang because of a bug[[1]] in systemd which is still outstanding in RHEL 9. Drop it. We don't have any tests for this yet. Multipath + LUKS currently doesn't work but should be fixed soon[[2]]. A test will be added as part of that work. [1]: systemd/systemd#29863 [2]: coreos/fedora-coreos-tracker#1728 Fixes: https://issues.redhat.com/browse/OCPBUGS-29325 (cherry picked from commit cc2e865)
This service was needed in the past to make multipath + LUKS work well. The underlying bug seems to have been fixed now as I can no longer reproduce it in Fedora or RHEL 9.4. Conveniently, this also works around a bug in which that service would sometimes hang because of a bug[[1]] in systemd which is still outstanding in RHEL 9. Drop it. We don't have any tests for this yet. Multipath + LUKS currently doesn't work but should be fixed soon[[2]]. A test will be added as part of that work. [1]: systemd/systemd#29863 [2]: coreos/fedora-coreos-tracker#1728 Fixes: https://issues.redhat.com/browse/OCPBUGS-29325 (cherry picked from commit cc2e865)
This service was needed in the past to make multipath + LUKS work well. The underlying bug seems to have been fixed now as I can no longer reproduce it in Fedora or RHEL 9.4. Conveniently, this also works around a bug in which that service would sometimes hang because of a bug[[1]] in systemd which is still outstanding in RHEL 9. Drop it. We don't have any tests for this yet. Multipath + LUKS currently doesn't work but should be fixed soon[[2]]. A test will be added as part of that work. [1]: systemd/systemd#29863 [2]: coreos/fedora-coreos-tracker#1728 Fixes: https://issues.redhat.com/browse/OCPBUGS-29325 (cherry picked from commit cc2e865)
New enough coreos-installer now landed in FCOS. Now with coreos/coreos-assembler#3822, it's possible to write an external test for this with |
We don't have coverage for this right now but should.
Easiest would be to make it a kola test. Though we could make it an external test if we add the ability to make the primary disk multipathed from the test metadata.
The text was updated successfully, but these errors were encountered: