Tails

#2 Updated by intrigeri 2018-12-02 14:53:52

• Parent task set to Feature #15293

#4 Updated by segfault 2018-12-02 17:39:05

• Assignee changed from segfault to intrigeri
• QA Check set to Ready for QA

#5 Updated by segfault 2018-12-02 17:40:45

• Status changed from Confirmed to In Progress

Applied in changeset commit:tails|709e2c95c8ed01e6e8c5b8a20baa169f4a24587c.

#7 Updated by intrigeri 2018-12-02 20:04:29

• Assignee changed from intrigeri to segfault
• % Done changed from 0 to 80
• QA Check changed from Ready for QA to Info Needed

The good news is that double-checking allowed me to spot a bug in the test suite: Bug #16003#note-10 :)

The bad news is that my manual test methology yields results that disagree with your conclusion that fatresize resets the filesystem label. Here’s what I did:

I’ve started for the first time a USB image built this morning from commit:3b3b7bc1abfe9bea845b960c8d91ec9b785040d5, after growing it to 8GB with truncate. In the booted Tails system:

# MTOOLS_SKIP_CHECK=1 mlabel -i /dev/sda1 -s
 Volume label is Tails (abbr=TAILS      )
# udisksctl info --block-device /dev/sda1
[…]
    IdLabel:                    TAILS
[…]
    Symlinks:                   /dev/disk/by-id/usb-QEMU_QEMU_HARDDISK_1-0000:00:05.7-4-0:0-part1
[…]
                                /dev/disk/by-label/TAILS

Then I’ve shut down this Tails, run kpartx -av bla.img, and:

sudo MTOOLS_SKIP_CHECK=1 mlabel -i /dev/mapper/loop0p1 -s                               
 Volume label is Tails (abbr=TAILS      )

So to me the filesystem label looks OK.

Is my test methodology wrong? If the mistake/confusion is on your side, please fix the “fatresize resets partition attributes and filesystem label” comment (but it’s fine to leave the code as-is, it’s not worth modifying and testing again).

#8 Updated by segfault 2018-12-03 21:50:59

• Assignee changed from segfault to intrigeri
• QA Check changed from Info Needed to Ready for QA

I could reproduce your results. But when I use the parse_vbr.py script I wrote for tails-verifier to parse the VBR of the system partition, I see a field PartitionLabel.

In the image created from create-usb-image-from-iso, this field contains the value Tails . After running fatresize, the field contains NO NAME . When setting the label with mlabel afterwards, the field contains Tails again.

I assumed that this “PartitionLabel” is the filesystem label, because it’s right next to PartitionID field, which is the 8 Byte filesystem ID (the field names both come from syslinux/libfat/fat.h).

But udisks, mlabel -s, and sgdisk --info=1 always show Tails as the filesystem / partition label, so I guess this field isn’t used by any of these tools. Still, I think it’s better to have this set the same in the repartitioned image as in the released image.

#10 Updated by intrigeri 2018-12-04 06:55:47

• Assignee changed from intrigeri to segfault
• QA Check changed from Ready for QA to Dev Needed

Thanks for the great research! I’m relieved to see that my test methodology is correct.

segfault wrote:
> Still, I think it’s better to have this set the same in the repartitioned image as in the released image.

Agreed. So please fix the comment and then close this ticket as resolved :)

#11 Updated by segfault 2018-12-04 09:13:57

• Status changed from In Progress to Resolved
• % Done changed from 80 to 100
• QA Check deleted (Dev Needed)

#12 Updated by intrigeri 2018-12-29 10:09:32

• Assignee deleted (segfault)