Groovy cloud-images failing during growpart

Cloud-init version : /usr/bin/cloud-init 20.1-10-g71af48df-0ubuntu5

Adding output of ubuntu-bug cloud-init

Why is sfdisk not part of the image ?

# dpkg -S `which sfdisk`
util-linux: /sbin/sfdisk

Also, not directly releated, but Focal dpkg does not know where sfdisk is from:

(crispyboi) ~ % lsb_release -rd
Description: Ubuntu 20.04 LTS
Release: 20.04
(crispyboi) ~ % dpkg --list | grep util-linux
ii util-linux 2.34-0.1ubuntu9 amd64 miscellaneous system utilities
(crispyboi) ~ % dpkg -L util-linux | grep sfdisk
(crispyboi) ~ % which sfdisk
/usr/sbin/sfdisk

On my focal desktop, I see sfdisk as part of the fdisk package, not util-linux:

  $ dpkg -S `which sfdisk`
  fdisk: /sbin/sfdisk

(In a groovy container, I had to install fdisk to get sfdisk.)

These are both from the util-linux source package, so I wonder if a binary has been relocated?

OK, a binary wasn't relocated, but the dependency from util-linux -> fdisk was dropped (in https://launchpad.net/ubuntu/+source/util-linux/2.34-0.1ubuntu3):

util-linux (2.34-0.1ubuntu3) focal; urgency=medium

  * Drop dependency from util-linux to fdisk. The transition to split-out
    fdisk was done before 18.04 so the transitional dependency is no longer
    needed, and fdisk should not be pulled into the essential package set
    since it's not needed in container environments. For bootable systems
    which need fdisk, it will be pulled in directly.

 -- Steve Langasek <email address hidden> Fri, 22 Nov 2019 13:40:12 -0800

(I've just pinged Steve in IRC asking him to weigh in on how cloud images were intended to end up with fdisk still installed.)

Things that need fdisk/sfdisk must depend on that package. It is intended to drop that package out of the smallest chroots, because chroots need not to manipulate disks.

Imho cloud-init should depend on fdisk.

But also, fdisk should be seeded somewhere appropriately. I don't know if that's "server", "cloud", or "boot" seeds.

Looking at seeds, it seems like maybe "cloud-image" should have fdisk seeded in both focal & groovy.

cloud-init invokes growpart
  growpart is from cloud-guest-utils
    cloud-init depends on cloud-guest-utils
       cloud-guest-utils depends on util-linux

So, when fdisk was split out, we now miss a dependency.

How, in generate does one protect against packaging changes which remove dependent parts?

cloud-guest-utils should depend on fdisk (for sfdisk) or gdisk (for sgdisk).

It *does* explicitly list its dependency on util-linux.
When someone split out fdisk from util-linux they should have looked at and fixed reverse depends.

On Thu, Apr 30, 2020 at 05:27:49PM -0000, Dimitri John Ledkov wrote:
> Looking at seeds, it seems like maybe "cloud-image" should have fdisk
> seeded in both focal & groovy.

This would mean that fdisk was in our default lxd container builds,
which I believe the dependency change was intended to avoid.
(Introducing it as a dependency on cloud-init or cloud-image-utils has a
similar problem, I think.)

On Thu, Apr 30, 2020 at 07:16:01PM -0000, Ryan Harper wrote:
> cloud-init invokes growpart
> growpart is from cloud-guest-utils
> cloud-init depends on cloud-guest-utils
> cloud-guest-utils depends on util-linux
>
> So, when fdisk was split out, we now miss a dependency.
>
> How, in generate does one protect against packaging changes which remove
> dependent parts?

I was going to say that I expect we would have caught this if
cloud-guest-utils had autopkgtests that exercised the sfdisk dependency,
but it appears we already do have such autopkgtests:
https://git.launchpad.net/ubuntu/+source/cloud-utils/tree/debian/tests

(Given that this package change happened early last cycle, I don't know
how feasible tracking down if they didn't run/were ignored would be;
perhaps a more distro-focused person could help?)

independent of how sfdisk gets into a cloud-image, cloud-utils should identify its dependency.
Something like https://paste.ubuntu.com/p/Fzwkm2PgqF/

On Thu, Apr 30, 2020 at 05:27:49PM -0000, Dimitri John Ledkov wrote:
> Looking at seeds, it seems like maybe "cloud-image" should have fdisk
> seeded in both focal & groovy.

I think this belongs in the server seed, not just cloud-image.

But given that fdisk is no longer part of the essential set, packages that
invoke it should also be fixed to declare a dependency on it.

We're wary of fdisk being in a seed for cloud-image, because we want to make sure we remain consistent with the rest of the distro and bringing an old package forward with us (say if we as a distro move towards gdisk).

I'm good with cloud-init depending on fdisk (or sometime in the future, gdisk)

On Thu, Apr 30, 2020 at 2:50 PM Steve Langasek <email address hidden>
wrote:

> On Thu, Apr 30, 2020 at 05:27:49PM -0000, Dimitri John Ledkov wrote:
> > Looking at seeds, it seems like maybe "cloud-image" should have fdisk
> > seeded in both focal & groovy.
>
> I think this belongs in the server seed, not just cloud-image.

From the changelog you dropped fdisk to avoid having it in chroots and
squashfs'.
Adding it to the seed would negate that without then removing it again from
those
images, which feels fragile.

I read the removal of fdisk as direction for the OS generally and will note
the chroots
and squashfs still carry gdisk/sgdisk (Although now I can't figure out how
that gets into
the image). But why wouldn't we leave it out of the seeds and if the user
needs fdisk
in addition to gdisk then they must now explicitly install it?

> But given that fdisk is no longer part of the essential set, packages that
> invoke it should also be fixed to declare a dependency on it.
>

+1 on packages explicitly declaring a dependency. Is this being worked for
cloud-utils?

I realize this is probably just seen as noise. But I think its important that everyone here understand.

Growpart supports using either fdisk or gdisk. But I have recently considered deleting the gdisk support.

I'm curious why fdisk is seen as "an old package". fdisk/sfdisk supports GPT partition tables and has for several years.

Also,
 * it is part of util-linux source (which is Essential).
 * It is maintained and updated (107 commits reference fdisk in util linux since Jan 1, 2019. gpt-fdisk has 25 total commits in that time frame. As much infrastructure is shared with other util-linux tools, that count is not complete).
 * fdisk (installed 505, size 119712) is smaller than gdisk (installed 860, size 214516) and has fewer dependencies.
 * In my opinion, sfdisk is dramatically more usable than sgdisk.
 * I'd even argue that the ui of fdisk is better than gdisk.

If the goal is to have one "partitioner", then fdisk/sfdisk is probably the one to keep.

> From the changelog you dropped fdisk to avoid having it in chroots and
> squashfs'.

Could there not be a chroot-essential set

> But given that fdisk is no longer part of the essential set, packages that
> invoke it should also be fixed to declare a dependency on it.

When do consumers of the essential set get to participate in the discussion of
what is or is NOT considered essential. This pattern has been repeated many
times over the many years and Server, specifically cloud-init team somehow is
out of the loop on these decision discussions. I'd like to really understand
what mailing-list, group, or team meeting that we're not part of so we can
avoid this after-the-fact discussion about how we got here.

> +1 on packages explicitly declaring a dependency.

I'll repeat that these sorts of changes are a lot easier to do if we know it's
coming. We never missed any of the ubuntu-devel emails around python2/3
transitions, or ssl changes, or rebuilds of the archive etc ... I'd also
like to point out that this additional dependency is only needed when changes
to packages subdivide portions of the package in ways that existing packages
don't know about. Cloud-init clearly depended on cloud-guest-utils which
clearly depended on util-linux. I don't think anyone anticipated that fdisk
and gdisk would bet pulled out into subpackages... what's next? dmesg? more?
mkfs ?

> Is this being worked for cloud-utils?

Scott has put up the change in a paste and we'll get this this pushed.

https://code.launchpad.net/~smoser/cloud-utils/+git/cloud-utils/+merge/383431
Merge proposal to upstream cloud-utils ^

This bug was fixed in the package cloud-utils - 0.31-8-g9619a1ea-0ubuntu1

---------------
cloud-utils (0.31-8-g9619a1ea-0ubuntu1) groovy; urgency=medium

  * New upstream snapshot.
    - cloud-image-utils: Add depends on fdisk, drop e2fsprogs
      [Scott Moser] (LP: #1876139)

 -- Ryan Harper <email address hidden> Tue, 05 May 2020 16:12:40 -0500

This is now fixed, thank you

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3665