Bug #11558

Step a Tails persistence partition exists on USB drive is fragile

Added by bertagaz 2016-07-05 03:31:52 . Updated 2016-08-02 09:29:48 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Test suite
Target version:
Tails_2.5
Start date:
2016-07-05
Due date:
% Done:

100%

Feature Branch:
test/10558-proper-luks-volume-quoting
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:
270

Description

I’ve seen it fail from time to time, and only once in Jenkins for what it remembers.

Interesting excerpt:

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 x28 and x29 are the hexadecimal code for ( and ).

Subtasks

History

#1 Updated by bertagaz 2016-07-06 05:06:33

  • 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 2016-07-06 11:29:29

  • Assignee deleted (bertagaz)
  • % 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. :)

#3 Updated by intrigeri 2016-07-13 12:03:27

  • Assignee set to intrigeri

#4 Updated by intrigeri 2016-07-13 13:05:17

  • Status changed from In Progress to Fix committed
  • Assignee deleted (intrigeri)
  • % Done changed from 60 to 100
  • QA Check changed from Ready for QA to Pass

The reasoning + patch makes sense, and I’ll trust your testing => merged.

#5 Updated by intrigeri 2016-07-21 08:59:55

  • Deliverable for set to 270

#6 Updated by intrigeri 2016-08-02 09:29:48

  • Status changed from Fix committed to Resolved