Bug #12501

Tails Upgrader mistakenly identifies read-write USB boot device as a DVD or a read-only device

Added by intrigeri 2017-05-02 16:36:23 . Updated 2017-05-23 09:07:54 .

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
Target version:
Start date:
2017-05-02
Due date:
% Done:

100%

Feature Branch:
bugfix/12501-second-automatic-upgrade
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Upgrader
Deliverable for:

Description

I’ve started Tails 3.0~beta3 from a (virtual, removable) USB stick in libvirt/KVM, and it tells me:

You should do a manual upgrade to Tails 3.0~beta4.

For more information about this new version, go to https://tails.boum.org/news/test_3.0-beta4/

It is not possible to automatically upgrade your device to this new version: Tails was started from a DVD or a read-only device.

Someone else reported the same issue on tails-testers@. It’s weird that other Tails contributors didn’t report it yet, so perhaps this doesn’t happen all the time?


Subtasks


History

#1 Updated by intrigeri 2017-05-02 17:01:35

The corresponding check is:

    -e file($self->dev_dir, 'bilibop');

… in method started_from_writable_device, in the Tails::RunningSystem class. Indeed, there’s no /dev/bilibop on this system.
Tails 3.0~beta3 has bilibop 0.5.2 installed, just like Tails 3.0~beta2 (guessing from the snapshots serial & Debian PTS) that didn’t expose this problem. So presumably something has changed elsewhere, e.g. in the kernel, in the way aufs mountpoints are exposed, in udisks or something.

This can be debugged with sudo sh -x /lib/bilibop/test $BOOT_DEVICE.

I can’t reproduce this problem on a dev build from commit:70091e587c08d60981019f660a9333035450597d that has no incremental upgrade installed. The system I have that exposes this problem has the beta2 incremental upgrade applied already (and the same version of bilibop and udev as 3.0~beta3), in case it matters.

#2 Updated by intrigeri 2017-05-02 17:35:58

Downgrading to bilibop from Jessie fixes the problem for me.

#3 Updated by intrigeri 2017-05-02 18:01:02

Reported upstream: https://bugs.debian.org/861685

#4 Updated by intrigeri 2017-05-11 10:42:46

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

Upstream proposed a fix that I should test.

#5 Updated by intrigeri 2017-05-11 12:10:52

Quick testing:

  1. boot a 3.0~betaN USB stick that has at least one incremental uprade applied
  2. sudo sh -x /lib/bilibop/test $BOOT_DEVICE should fail
  3. apply upstream bugfix
  4. sudo sh -x /lib/bilibop/test $BOOT_DEVICE should work

Full testing procedure:

  1. boot a 3.0~beta2 USB stick
  2. set channel “stable” in /etc/os-release (that one now advertises the 3.0~beta3 IUK)
  3. upgrade to 3.0~beta3 with Tails Upgrader
  4. reboot
  5. wait for Tails Upgrader to expose the bug this ticket is about
  6. apply the upstream bugfix
  7. run udevadm trigger to have /dev/bilibop created
  8. run Tails Upgrader again
  9. the update to 3.0~beta4 should be applied

#6 Updated by intrigeri 2017-05-17 06:43:13

  • % Done changed from 10 to 20
  • Feature Branch set to bugfix/12501-second-automatic-upgrade

#7 Updated by intrigeri 2017-05-17 08:31:16

  • Assignee changed from intrigeri to anonym
  • % Done changed from 20 to 50
  • QA Check set to Ready for QA

#8 Updated by anonym 2017-05-18 10:51:35

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

Looks good! I didn’t test it, but I trust your tests, and the fact that this patch reverts back to the code we’ve been using successfully in Jessie.

#9 Updated by intrigeri 2017-05-23 09:07:54

  • Status changed from Fix committed to Resolved