Bug #15974

tails-persistence-setup silently fails to create a persistent volume on a 256Gb USB stick

Added by goupille 2018-09-24 09:59:16 . Updated 2019-04-07 09:16:57 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Persistence
Target version:
Start date:
2018-09-24
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

A user reported that after trying to configure a persistent volume on a 256 GB generic pendrive, the window closes itself after approximatively 4 minutes without any error. after a reboot, the persistent volume is never unlocked.

I found that in the logs :

 amnesia tails-persistence-setup.desktop[8479]: WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. at /usr/share/perl5/Gtk3.pm line 529.

and 4 minutes later :

amnesia kernel: EXT4-fs error (device dm-0): ext4_find_extent:909: inode #8: comm mount: pblk 30965759 bad header/extent: invalid magic - magic 4efc, entries 44277, max 27738(0), depth 56147(0)
amnesia kernel: jbd2_journal_init_inode: Cannot locate journal superblock
amnesia kernel: EXT4-fs (dm-0): Could not load journal inode
amnesia tails-persistence-setup.desktop[8479]: org.freedesktop.UDisks2.Error.Failed: Error mounting /dev/dm-0 at /media/tails-persistence-setup/TailsData: Command-line `mount -t "ext4" -o "uhelper=udisks2,nodev,nosuid" "/dev/dm-0" "/media/tails-persistence-setup/TailsData"' exited with non-zero exit status 32: mount: wrong fs type, bad option, bad superblock on /dev/mapper/luks-c0c58fd4-8357-49b3-87f6-1254f9a60c2d,

Subtasks

History

#1 Updated by intrigeri 2018-10-10 11:32:13

  • Category set to Persistence
  • Assignee changed from intrigeri to goupille
  • QA Check set to Info Needed

Interesting!

> and 4 minutes later :

Not sure where this 4 minutes comes from, this makes me curious! :)

What I see in Bug report ef4423369b7a32cde61619bb6e3a7f84 is:

  1. 08:30:02: t-p-s is started
  2. shortly after 08:30:12: htpdate sets the time back to 08:01:57
  3. 08:07:05 (i.e. ~5 minutes after t-p-s was started, taking into account time change): Entering Bootstrap::operation_finished
  4. and then udisks fails to mount the new ext4 filesystem because it’s corrupted

I’ve taken a look at the code and it tries to set a 1 hour timeout for the mkfs operation, so:

  • either my code is buggy and the timeout is not honored, plus it’s also buggy enough to fail to detect that the mkfs operation failed
  • or udisks/D-Bus/glib got confused by the system time change and did not wait long enough
  • or the USB stick is buggy and returns different data when reading than what we wrote to it

To debug this I’ll need more info from the user:

  1. start Tails
  2. set an administration password
  3. delete the buggy TailsData partition with GNOME Disks
  4. wait for the time to be synchronized i.e. until systemctl status htpdate.service says it has successfully started and exited
  5. run /usr/local/bin/tails-persistence-setup --verbose
  6. if the same problem happens again, send a new WhisperBack report, referencing this ticket

#2 Updated by intrigeri 2018-11-17 13:13:30

  • Status changed from New to Confirmed
  • Assignee changed from goupille to intrigeri
  • QA Check deleted (Info Needed)

#3 Updated by intrigeri 2018-11-17 14:03:09

Asked the bug reported to try a few more things.

#4 Updated by intrigeri 2019-01-11 18:37:50

They replied and I’ve asked them more info again.

#5 Updated by intrigeri 2019-04-07 09:16:57

  • Status changed from Confirmed to Rejected
  • Assignee deleted (intrigeri)

It turned out to be a 16GB USB stick sold as a 256GB one, with a firmware that pretends it’s indeed a 256GB drive.