Bug #16731

Partitioning on boot sometimes aborts because of partprobe failing

Added by mercedes508 2019-05-19 15:25:22 . Updated 2019-07-10 11:58:21 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_3.15
Start date:
Due date:
% Done:

100%

Feature Branch:
bugfix/16731-explicit-partprobe
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:
316

Description

We received a WB report (da054cb0246450ddda6657a8a9999d70) about a failure on second boot.

Apprently due to the execution of partprobe from init-premount script.

Subtasks

Related issues

Related to Tails - Bug #16389: Some USB sticks become unbootable in legacy BIOS mode after first boot Resolved 2019-01-25

History

#1 Updated by segfault 2019-05-20 00:23:10

So, the bug report is about a USB image booted on a non-UEFI computer, where the partitioning script fails at the partprobe command and thus doesn’t execute the sgdisk command which sets legacy BIOS bootable.

The error message of the partprobe command is “Error: Can’t have a partition outside the disk!”. I didn’t yet look into what could have caused this error.

I think that this could be the cause of some of the issues reported on Bug #16389.

#2 Updated by segfault 2019-05-20 17:38:20

I started investigating what the cause for “Can’t have a partition outside the disk” could be.

partprobe fails with this error if (part->geom.end >= disk->dev->length). So I see these possible causes:

  1. We use a too big partition size in the sgdisk command to create the partition.
  2. partprobe gets an incorrect partition geometry, which has a too big geom.end value.
  3. partprobe compares with a different device size (disk->dev->length) than what we used to calculate the partition size for the sgdisk command.

#3 Updated by segfault 2019-05-20 18:08:52

Just saw Bug #16389#note-71. I assume that the user reporting this same issue on XMPP is the same user who sent the bug report, because they describe exactly the same issue and both already did some investigation on their own.

anonym found out that the partprobe error was caused by a fake raid array and is unrelated to the partition we create. Therefore I will now stop investigating and prepare the fix anonym suggested.

#4 Updated by segfault 2019-05-20 18:12:49

  • Subject changed from Fail to properly resize USB stick on first boot to partitioning sometimes aborts because of partprobe failing
  • Feature Branch set to bugfix/16389-explicit-partprobe

#5 Updated by segfault 2019-05-20 18:16:22

anonym already pushed a commit to bugfix/16389-explicit-partprobe.

I don’t see how this issue could be solved by sgdisk --recompute-chs, which did fix the second boot issue for at least one user. So I don’t want to hijack Bug #16389 for this and will restore the old feature branch there and use the partprobe related branch here.

#6 Updated by segfault 2019-05-20 18:22:29

  • Feature Branch changed from bugfix/16389-explicit-partprobe to bugfix/16731-explicit-partprobe

Adjusting the ticket number in the branch name. Pushed the new branch and deleted the old one.

#7 Updated by intrigeri 2019-05-23 07:40:03

  • related to Bug #16389: Some USB sticks become unbootable in legacy BIOS mode after first boot added

#8 Updated by intrigeri 2019-05-23 07:42:51

  • Subject changed from partitioning sometimes aborts because of partprobe failing to Partitioning on boot sometimes aborts because of partprobe failing
  • Status changed from Confirmed to In Progress

#9 Updated by intrigeri 2019-05-23 07:43:50

  • Deliverable for set to 316

#11 Updated by intrigeri 2019-05-29 16:19:48

  • Target version set to Tails_3.15
  • QA Check set to Ready for QA

It looks like the only thing left here to do is to review anonym’s branch and merge it, right?

#12 Updated by segfault 2019-06-01 22:23:45

  • Status changed from In Progress to Fix committed
  • % Done changed from 0 to 100

Applied in changeset commit:tails|14fdf238b08a686c75028e09a5cb90c45ad14972.

#13 Updated by segfault 2019-06-01 22:24:21

  • Assignee deleted (segfault)
  • % Done changed from 100 to 0
  • QA Check changed from Ready for QA to Pass

intrigeri wrote:
> It looks like the only thing left here to do is to review anonym’s branch and merge it, right?

Done

#14 Updated by segfault 2019-06-01 22:24:35

  • % Done changed from 0 to 100

#15 Updated by intrigeri 2019-06-02 09:45:02

I’ve in turn merged stable into devel.

#16 Updated by CyrilBrulebois 2019-07-08 21:37:21

I’m not sure what to do here (if anything) as this ticket has target version Tails_3.15 so shows up on the RM view for 3.15, while the fix was actually merged into 3.14.1. Should the target version have been changed to Tails_3.14? Or is it considered fine/OK/unimportant to have a few tickets fixed in emergency releases show up on the RM view for the next bugfix/major release?

#17 Updated by intrigeri 2019-07-09 12:10:37

> I’m not sure what to do here (if anything) as this ticket has target version Tails_3.15 so shows up on the RM view for 3.15, while the fix was actually merged into 3.14.1. Should the target version have been changed to Tails_3.14? Or is it considered fine/OK/unimportant to have a few tickets fixed in emergency releases show up on the RM view for the next bugfix/major release?

In general I prefer having tickets closed with the correct version. This avoids mistakes in the changelog, release notes, and makes future analysis easier.

I’ve already corrected a bunch of these mistakes from the 3.14.X release process. I missed this one. Whatever, close with version = 3.15.

#18 Updated by CyrilBrulebois 2019-07-10 10:32:40

  • Status changed from Fix committed to Resolved

#19 Updated by CyrilBrulebois 2019-07-10 11:58:21

Alright, thanks.