Bug #10288: Fix newly identified issues to make our test suite more robust and faster
Step a Tails persistence partition exists on USB drive is fragile
I've seen it fail from time to time, and only once in Jenkins for what it remembers.
calling as root: udisksctl info --block-device '/dev/sda2' call returned: [0, "/org/freedesktop/UDisks2/block_devices/sda2: org.freedesktop.UDisks2.Block: Configuration:  CryptoBackingDevice: '/' Device: /dev/sda2 DeviceNumber: 2050 Drive: '/org/freedesktop/UDisks2/drives/QEMU_QEMU_HARDDISK_1_0000_3a00_3a05_2e7_1' HintAuto: true HintIconName: HintIgnore: false HintName: HintPartitionable: true HintSymbolicIconName: HintSystem: true Id: by-uuid-69a18ff0-ac91-4045-b5d7-624d402ad26b IdLabel: IdType: crypto_LUKS IdUUID: 69a18ff0-ac91-4045-b5d7-624d402ad26b IdUsage: crypto IdVersion: 1 MDRaid: '/' MDRaidMember: '/' PreferredDevice: /dev/sda2 ReadOnly: false Size: 1670364672 Symlinks: /dev/disk/by-id/usb-QEMU_QEMU_HARDDISK_1-0000:00:05.7-1-0:0-part2 /dev/disk/by-partlabel/TailsData /dev/disk/by-partuuid/462cbd6f-ba04-4608-8e69-43e75e350358 /dev/disk/by-path/pci-0000:00:05.7-usb-0:1:1.0-scsi-0:0:0:0-part2 /dev/disk/by-uuid/69a18ff0-ac91-4045-b5d7-624d402ad26b org.freedesktop.UDisks2.Encrypted: org.freedesktop.UDisks2.Partition: Flags: 0 IsContained: false IsContainer: false Name: TailsData Number: 2 Offset: 2624585728 Size: 1670364672 Table: '/org/freedesktop/UDisks2/block_devices/sda' Type: 0fc63daf-8483-4772-8e79-3d69d8477de4 UUID: 462cbd6f-ba04-4608-8e69-43e75e350358", ""] calling as root: ls -1 /dev/mapper/ call returned: [0, "control\nluks-\\x28null\\x29\n", ""] calling as root: cryptsetup status control call returned: [4, "/dev/mapper/control is inactive.\n", ""] calling as root: cryptsetup status luks-\x28null\x29 call returned: [4, "/dev/mapper/luks-x28nullx29 is inactive.\n", ""] calling as root: echo asdf | cryptsetup luksOpen /dev/sda2 old call returned: [5, "", "Cannot use device /dev/sda2 which is in use (already mapped or mounted).\n"] Then a Tails persistence partition exists on USB drive "old" # features/step_definitions/usb.rb:285 Couldn't open LUKS device '/dev/sda2' on drive 'old'. <false> is not true. (Test::Unit::AssertionFailedError) ./features/step_definitions/usb.rb:304:in `/^a Tails persistence partition exists on USB drive "([^"]+)"$/' features/usb_upgrade.feature:73:in `Then a Tails persistence partition exists on USB drive "old"' And I shutdown Tails and wait for the computer to power off # features/step_definitions/common_steps.rb:532
I don't know where this
/dev/mapper/luks-x28nullx29 comes from, I never had the chance to trigger that bug with the --pause-on-fail option of our test suite to inspect the system under test. Note that
x29 are the hexadecimal code for
#1 Updated by bertagaz over 2 years ago
- Status changed from Confirmed to In Progress
After some runs with the
--pause-on-fail option and some debugging, it seems to be a problem in tails-persistence-setup, which sometimes leaves the LUKS volume unlocked in /dev/mapper/luks-\x28null\x29. It's probably a UDisks bug in the end (seems like it's using
(null) in place of the LUKS volume UUID), but I don't have the perl nor C skills to track down the bug to the root (not to mention the time it'd take).
There are other approaches to solve this in the test suite though: either by proper quoting, or by using the DM volume path that we can retrieve by following the /dev/mapper/ symlink (usually
/dev/dm-0). I'm testing the first option for now by adding the
b option to the
ls -1 /dev/mapper/ command. Maybe the second would make sense though: there should not be any other DM at this moment.
#2 Updated by bertagaz over 2 years ago
- Assignee deleted (
- % Done changed from 0 to 60
- QA Check set to Ready for QA
- Feature Branch set to test/10558-proper-luks-volume-quoting
Pushed a branch that solves the issue. It properly quotes where needed to handle weird characters in the LUKS DM name like reported. Setting it to RfQA, but I don't know who to assign it to.
Ways to trigger the bug: run features/usb_install.feature:42 scenario from stable on a Tails 2.4 ISO multiple times over the night (on 50 runs I trigger it several times on my harware). In some of the debug logs, you should see that
luks-\x28null\x29 device and the test suite should still be green. :)