[Bug 204878] Re: When using biggest_free, you are unable to specify a drive

[Timothy R. Chavez]

** Changed in: somerville
   Importance: Undecided => High

** Changed in: somerville
       Status: New => Fix Released

** Changed in: somerville
     Assignee: (unassigned) => Mario Limonciello (superm1)

** No longer affects: dell

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to partman-auto in Ubuntu.
https://bugs.launchpad.net/bugs/204878

Title:
  When using biggest_free, you are unable to specify a drive

Status in The Somerville Project:
  Fix Released
Status in “partman-auto” package in Ubuntu:
  Fix Released

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/somerville/+bug/204878/+subscriptions