When using biggest_free, you are unable to specify a drive

Bug #204878 reported by Mario Limonciello
2
Affects Status Importance Assigned to Milestone
partman-auto (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: partman-auto

With the Dell factory process, we have a specific scheme that two partitions are created before Ubiquity (and consequently partman-auto) activate. These two partitions must remain in place.

In our seed file we are specifying:

     d-i partman-auto/init_automatically_partition select biggest_free
     d-i partman-auto/expert_recipe string ......

The expected behavior is that the expert_recipe is placed into the free space. This works properly when only a single drive is present.

When a second drive is added to the mix, it always chooses the bigger drive because it doesn't have those two existing partitions.

Logically, you might expect that it would be able to specify which disks to check like this:

     d-i partman-auto/disk string /dev/sda

Unfortunately, the biggest_free recipe ignores this variable. The only time it is used is when you also specify:

    d-i partman-auto/method string regular

In doing this, free space isn't taken into consideration at all. The recipe gets used, but wipes away both of the existing partitions on /dev/sda.

So I see two possible solutions:

1) Letting init_automatically_partition listen to the disk debconf option, and then restrict the disks it's allowed to check
2) Expand display.d/initial_auto to cover this case, perhaps adding a new method like regular_freespace.

The former option seems like a better solution though to me.

Related branches

Changed in dell:
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Colin Watson (cjwatson) wrote :

I agree that having the biggest_free autopartitioning method listen to partman-auto/disk seems like the best option here.

Changed in partman-auto:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Colin Watson (cjwatson) wrote :

I'm on holiday for the next week, so I won't really be able to test this properly, but perhaps you could try out the attached patch? You can apply it to /lib/partman/automatically_partition/50biggest_free/choices before starting ubiquity.

Revision history for this message
Mario Limonciello (superm1) wrote :

Colin,

The attached patch works as advertised on the dual hard drive system that we're using to preseed.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package partman-auto - 73ubuntu6

---------------
partman-auto (73ubuntu6) hardy; urgency=low

  * Make biggest_free respect the selection made in partman-auto/disk
    (LP: #204878). Thanks Colin Watson.

 -- Evan Dandrea <email address hidden> Mon, 24 Mar 2008 12:01:56 -0400

Changed in partman-auto:
status: Confirmed → Fix Released
Changed in dell:
assignee: nobody → superm1
status: Confirmed → Fix Committed
Changed in dell:
status: Fix Committed → Fix Released
Changed in somerville:
assignee: nobody → Mario Limonciello (superm1)
importance: Undecided → High
status: New → Fix Released
no longer affects: dell
Revision history for this message
Timothy R. Chavez (timrchavez) wrote :

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1305496

no longer affects: somerville
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.