Project

General

Profile

Bug #17393

Failed to meet partition size error during persistent volume creation

Added by numbat 3 months ago. Updated about 1 month ago.

Status:
Confirmed
Priority:
Low
Assignee:
-
Category:
Hardware support
Target version:
-
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

A user reported having an error while create Persistence using a portable 1TB SSD from Samsung. They managed to counter that by using gnome-disks to "adjust the size down a bit".

I don't know if this is with this specific device or if it's related to size.

Bug report: 6b64cccc6637f2531a19cefd5064da75

error_creating_partition_Persistence.png View (12.6 KB) numbat, 01/04/2020 01:44 PM


Related issues

Related to Tails - Feature #17394: adjustable persistence size New

History

#1 Updated by intrigeri about 2 months ago

#2 Updated by intrigeri about 2 months ago

  • Subject changed from Persistence on Samsung Portable SSD T5 1TB to Cannot create persistence on Samsung Portable SSD T5 1TB
  • Status changed from New to Confirmed

The error message reads Error creating partition on /dev/sdb: Failed to meet partition size on device '/dev/sdb' (udisks-error-quark, 0).

The user says they had to make the partition 991G instead of the default 992G, so that GNOME Disks succeeds at creating the partition.

I see similar problems reported on:

At first glance, my hunch is:

  • either we pass partition boundaries to udisks in a buggy way, e.g. using some integer type that's too small for large partitions; I find it unlikely that our persistence setup + Cockpit + GNOME Disks all get this wrong;
  • or it's a bug in udisks

segfault, as our in-house udisks expert: do you have the kind of hardware needed to reproduce this and possibly debug the corresponding udisks code?

#3 Updated by segfault about 2 months ago

intrigeri wrote:

segfault, as our in-house udisks expert: do you have the kind of hardware needed to reproduce this and possibly debug the corresponding udisks code?

I currently don't have any spare 1TB disk which I could use to reproduce the issue.

I took a quick look at the code to see where the error message comes from. The "Failed to meet partition size on device" part originates in resize_part() in libblockdev.git:src/plugins/part.c. IIUC, udisks calls bd_part_create_part(), which calls add_part_to_disk(), which calls resize_part(). I would have to be able to reproduce the issue to further debug it.

#4 Updated by intrigeri about 2 months ago

#5 Updated by intrigeri about 2 months ago

Hi,

segfault wrote:

intrigeri wrote:

segfault, as our in-house udisks expert: do you have the kind of hardware needed to reproduce this and possibly debug the corresponding udisks code?

I currently don't have any spare 1TB disk which I could use to reproduce the issue.

I tried to reproduce on a spare 750GB SATA disk plugged via a USB-SATA adapter enclosure.

I'm wondering if we could try to reproduce via our automated test suite: presumably, even with significantly less than 1TB of disk space available, we could create a 1TB qcow2 virtual disk (thanks to sparse files and/or compression).

This might be a relevant starting point:

--- a/features/step_definitions/snapshots.rb
+++ b/features/step_definitions/snapshots.rb
@@ -66,7 +66,7 @@ def checkpoints
:description => "I have started Tails without network from a USB drive without a persistent partition and stopped at Tails Greeter's login screen",
:parent_checkpoint => nil,
:steps => [
-        'I create a 7200 MiB disk named "__internal"',
+        'I create a 1000000 MiB disk named "__internal"',
'I plug USB drive "__internal"',
'I write the Tails USB image to disk "__internal"',
'I start Tails from USB drive "__internal" with network unplugged',

Do you want to pursue this? Otherwise, I could give it a try :)

I took a quick look at the code to see where the error message comes from. The "Failed to meet partition size on device" part originates in resize_part() in libblockdev.git:src/plugins/part.c. IIUC, udisks calls bd_part_create_part(), which calls add_part_to_disk(), which calls resize_part(). I would have to be able to reproduce the issue to further debug it.

OK, thanks for looking into it!

I'm a bit surprised to see anything related to resizing partitions in there but I did not look at the code so perhaps it does something different than what I would guess.

#6 Updated by intrigeri about 2 months ago

intrigeri wrote:

I tried to reproduce on a spare 750GB SATA disk plugged via a USB-SATA adapter enclosure.

Gah, forgot to make it clear: I tried and failed to reproduce. The persistent volume was created just fine. It might be because 750GB << 1TB, or it could be related to sector size.

#7 Updated by segfault about 2 months ago

intrigeri wrote:

I'm wondering if we could try to reproduce via our automated test suite: presumably, even with significantly less than 1TB of disk space available, we could create a 1TB qcow2 virtual disk (thanks to sparse files and/or compression).

I tried that, but the disk creation step fails with "Need 1000000 MiB but only X MiB available".

Then I created a 1 TiB qcow2 disk locally, which worked:

qemu-img create -f qcow2 test.qcow2 1T

But I could not reproduce the issue. I tried attaching it to a Tails VM and creating 992G partition with GNOME Disks, which worked just fine.
Then I copied a USB image to the disk (after associating it with a block device via qemu-nbd), booted it in a VM, and created a persistent partition on it, which also worked fine.

I'm a bit surprised to see anything related to resizing partitions in there but I did not look at the code so perhaps it does something different than what I would guess.

Yes, I was also surprised about that, but that's what libblockdev does. But I did also not investigate further why it does that.

#8 Updated by segfault about 2 months ago

Then I copied a USB image to the disk (after associating it with a block device via qemu-nbd), booted it in a VM, and created a persistent partition on it, which also worked fine.

FWIW, the resulting persistent partition has a size of 1.1 TB (1,099,511,627,776 bytes).

I suspect that the issue only occurs for very specific partition sizes. The 992G you quoted might be rounded.

#9 Updated by segfault about 1 month ago

  • Subject changed from Cannot create persistence on Samsung Portable SSD T5 1TB to Failed to meet partition size error during persistent volume creation

I suspect that the issue only occurs for very specific partition sizes. The 992G you quoted might be rounded.

I got exact disk and partition sizes from another affected user on reddit (https://www.reddit.com/r/tails/comments/f3ganw/error_when_trying_to_set_up_large_size_persistent/fhmgooa/).

I created a virtual disk with the same size but was still not able to reproduce the issue, tails-persistence-setup did successfully create the persistent partition.

#10 Updated by intrigeri 9 days ago

Also available in: Atom PDF