Project

General

Profile

Bug #16731

Partitioning on boot sometimes aborts because of partprobe failing

Added by mercedes508 29 days ago. Updated 15 days ago.

Status:
Fix committed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

100%

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

Description

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

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


Related issues

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

Associated revisions

Revision bf1b3b59 (diff)
Added by anonym 16 days ago

Only probe for partitions on the boot device.

Without arguments partprobe will scan all devices, and if it
encounters a device it doesn't support (e.g. fake raid-0 arrays) it
will return non-zero, thus aborting Tails' partitioning script,
resulting in an unbootable install.

Will-fix: #16731

Revision 14fdf238
Added by segfault 16 days ago

Merge branch 'bugfix/16731-explicit-partprobe' into stable (Fix-committed: #16731)

History

#1 Updated by segfault 29 days ago

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 #16389.

#2 Updated by segfault 28 days ago

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 28 days ago

Just saw #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 28 days ago

  • 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 28 days ago

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 #16389 for this and will restore the old feature branch there and use the partprobe related branch here.

#6 Updated by segfault 28 days ago

  • 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 25 days ago

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

#8 Updated by intrigeri 25 days ago

  • 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

#11 Updated by intrigeri 19 days ago

  • 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 16 days ago

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

#13 Updated by segfault 16 days ago

  • 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 16 days ago

  • % Done changed from 0 to 100

#15 Updated by intrigeri 15 days ago

I've in turn merged stable into devel.

Also available in: Atom PDF