1810878 – [RHEL-8]growpart fails to resize a root partition on LVM

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1810878 - [RHEL-8]growpart fails to resize a root partition on LVM

Summary: [RHEL-8]growpart fails to resize a root partition on LVM

Keywords:
Status:	CLOSED WONTFIX
Alias:	None
Product:	Red Hat Enterprise Linux 8
Classification:	Red Hat
Component:	cloud-utils-growpart
Sub Component:
Version:	8.2
Hardware:	x86_64
OS:	Linux
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Eduardo Otubo
QA Contact:	Huijuan Zhao
Docs Contact:	Jiri Herrmann
URL:
Whiteboard:
Depends On:	1787624
Blocks:
TreeView+	depends on / blocked

Reported:	2020-03-06 05:53 UTC by Yuxin Sun
Modified:	2022-07-29 07:44 UTC (History)
CC List:	12 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:	1787624
Environment:
Last Closed:	2022-04-06 07:27:51 UTC
Type:	Feature Request
Target Upstream Version:
Embargoed:
Dependent Products:

Attachments	(Terms of Use)

Comment 14 Eduardo Otubo 2020-12-02 15:18:59 UTC

First draft for possible fix: https://github.com/otubo/cloud-init/commits/1810878
Still under development, but the basic fix is that.

Comment 16 Eduardo Otubo 2020-12-03 10:15:22 UTC

I'd like to open a little discussion here regarding Scott's comments[0] on my draft patch: Do you think it's acceptable to *not* extend the rootfs (its Volume Group and Logical Volume), but only the Physical Volume it belongs? It's possible to have many other Logical Volumes under that Physical Volume and sometimes it's not obvious to cloud-init what exactly the user wants. Basically the fix would identify the Physical Volume the rootsfs belongs (and its original Block Device) and enlarge it to the max extent. Then the user can decide what to do with that extra space. I believe we just need to have it well documented (will also ping the document guys to update ours) and it would be a good fix.

I agree with Scott's comment and IMHO we can fix the issue like proposed (enlarge the Physical Volume, its Block Device and leave for the user to decide what to do next). I'm gonna set NEEDINFO on Huijuan, Yuxin and Ryan Kimbrell (which was the original reporter of the issue.)

Thanks!

[0] https://github.com/otubo/cloud-init/commit/6ffcee4ead7b107028af0ea9d24657931fcfee76#r44737362

Comment 17 Yuxin Sun 2020-12-07 11:56:59 UTC

Hi Eduardo,

It seems that the main concern of Scott is that customer may want to resize LVs other than rootlv. Can we consider to allow the customers to specify the LV name or path in cloud-init configuration file if they want to resize a different LV? IMO it will be more like the growpart design. I think just resize PV but leave LV there may make the customer feel a little confused. Especially that for RHEL-8 and future RHEL releases, Azure will only provide LVM images(and provision agent is cloud-init). I think it will be more convenient if cloud-init can support enlarging LV.

Thanks!

Comment 18 Huijuan Zhao 2020-12-07 12:06:44 UTC

Thanks Eduardo and Yuxin, Yuxin's suggestion makes sense to me

Comment 19 Eduardo Otubo 2020-12-07 12:46:11 UTC

(In reply to Yuxin Sun from comment #17)
> Hi Eduardo,
> 
> It seems that the main concern of Scott is that customer may want to resize
> LVs other than rootlv. Can we consider to allow the customers to specify the
> LV name or path in cloud-init configuration file if they want to resize a
> different LV? IMO it will be more like the growpart design. I think just
> resize PV but leave LV there may make the customer feel a little confused.
> Especially that for RHEL-8 and future RHEL releases, Azure will only provide
> LVM images(and provision agent is cloud-init). I think it will be more
> convenient if cloud-init can support enlarging LV.
> 
> Thanks!

Right now the configuration allows the following:

growpart:
    mode: auto
    devices: ["/"]
    ignore_growroot_disabled: false

And the key "devices" is a list of devices that the user would like to resize. What I understand from your comment is that if the user has LVM and wants to resize  *only one* partition, than it should be defined there and automatically resized; otherwise it would fail. I think it makes sense. I'll propose and discuss this upstream. Thanks for the insight!

Comment 20 Yuxin Sun 2020-12-07 13:51:05 UTC

(In reply to Eduardo Otubo from comment #19)
> (In reply to Yuxin Sun from comment #17)
> > Hi Eduardo,
> > 
> > It seems that the main concern of Scott is that customer may want to resize
> > LVs other than rootlv. Can we consider to allow the customers to specify the
> > LV name or path in cloud-init configuration file if they want to resize a
> > different LV? IMO it will be more like the growpart design. I think just
> > resize PV but leave LV there may make the customer feel a little confused.
> > Especially that for RHEL-8 and future RHEL releases, Azure will only provide
> > LVM images(and provision agent is cloud-init). I think it will be more
> > convenient if cloud-init can support enlarging LV.
> > 
> > Thanks!
> 
> Right now the configuration allows the following:
> 
> growpart:
>     mode: auto
>     devices: ["/"]
>     ignore_growroot_disabled: false
> 
> And the key "devices" is a list of devices that the user would like to
> resize. What I understand from your comment is that if the user has LVM and
> wants to resize  *only one* partition, than it should be defined there and
> automatically resized; otherwise it would fail. I think it makes sense. I'll
> propose and discuss this upstream. Thanks for the insight!

Thanks Eduardo! Yes I think *only one* partition is acceptable for now. If customers want more complex configurations they can just disable the growpart and do it themselves. And if there's customer case for such scenario, we can consider to support it later.

And to clarify, with your patch in, the "devices" will support LVM path. And what is the default value if the os disk is LVM parted and no "devices" parameter is set? Thanks!

Comment 21 Eduardo Otubo 2020-12-07 16:57:15 UTC

(In reply to Yuxin Sun from comment #20)
> (In reply to Eduardo Otubo from comment #19)
> > (In reply to Yuxin Sun from comment #17)
> > > Hi Eduardo,
> > > 
> > > It seems that the main concern of Scott is that customer may want to resize
> > > LVs other than rootlv. Can we consider to allow the customers to specify the
> > > LV name or path in cloud-init configuration file if they want to resize a
> > > different LV? IMO it will be more like the growpart design. I think just
> > > resize PV but leave LV there may make the customer feel a little confused.
> > > Especially that for RHEL-8 and future RHEL releases, Azure will only provide
> > > LVM images(and provision agent is cloud-init). I think it will be more
> > > convenient if cloud-init can support enlarging LV.
> > > 
> > > Thanks!
> > 
> > Right now the configuration allows the following:
> > 
> > growpart:
> >     mode: auto
> >     devices: ["/"]
> >     ignore_growroot_disabled: false
> > 
> > And the key "devices" is a list of devices that the user would like to
> > resize. What I understand from your comment is that if the user has LVM and
> > wants to resize  *only one* partition, than it should be defined there and
> > automatically resized; otherwise it would fail. I think it makes sense. I'll
> > propose and discuss this upstream. Thanks for the insight!
> 
> Thanks Eduardo! Yes I think *only one* partition is acceptable for now. If
> customers want more complex configurations they can just disable the
> growpart and do it themselves. And if there's customer case for such
> scenario, we can consider to support it later.
> 
> And to clarify, with your patch in, the "devices" will support LVM path. And
> what is the default value if the os disk is LVM parted and no "devices"
> parameter is set? Thanks!

The default behavior is that no disk or device is touched, hence the partition remains the same.

Comment 23 Eduardo Otubo 2020-12-07 16:58:29 UTC

Pull request opened:
https://github.com/canonical/cloud-init/pull/714

Comment 52 Eduardo Otubo 2022-01-26 11:09:35 UTC

Resetting ITM and DTM as this still requires a lot some work and I don't believe I'll be able to complete for RHEL-9/8.6. Putting back on the backlog.

Comment 61 RHEL Program Management 2022-04-06 07:27:51 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Note You need to log in before you can comment on or make changes to this bug.