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 998710 - Add LVM support for /boot.
Summary: Add LVM support for /boot.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.0
Hardware: All
OS: All
medium
low
Target Milestone: rc
: 7.3
Assignee: Peter Rajnoha
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On: 760243 760258 1496229
Blocks: 1164947 794823 1008418 1205796 1243449 1298243 1411715 1469559
TreeView+ depends on / blocked
 
Reported: 2013-08-19 20:28 UTC by Alasdair Kergon
Modified: 2023-09-07 18:37 UTC (History)
33 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of: 872576
: 1243449 (view as bug list)
Environment:
Last Closed: 2017-07-26 14:42:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 39416 0 None None None 2016-12-02 14:08:22 UTC
Red Hat Knowledge Base (Solution) 2022923 0 None None None 2016-12-02 14:09:02 UTC

Description Alasdair Kergon 2013-08-19 20:28:32 UTC
Add LVM support for /boot.

LVM already added pvcreate --embeddingareasize and pvs -o +ea_start,ea_size to create an embedding area within a PV and reports it via pvs (the embedding area start is subject to alignment and it's calculated by LVM tools).

Grub can use this space that is specifically reserved for external tools to embed their data/metadata. The aim is to remove a need for partitions (also GPT's "boot" type partition) and also have a way to reserve a space that LVM will not touch at all and which can be exclusively used by external tools.

This bug covers the remaining work needed on the LVM/grub interface for full /boot support.

Comment 7 Mark Thacker 2016-11-30 21:10:28 UTC
Would like to see this as well. Also, would this be an enabler for other activities such as booting from a snapshot with a grub menu item?

Comment 8 Terry Bowling 2016-12-02 13:53:21 UTC
This would be a great feature allowing RHEL 7 to use only LVM and no old-school partitions.

This would provide much greater flexibility with disk imaging and our own RHEL cloud images which currently do not use lvm for /dev/sda.  So if I deploy a cloud image, I cannot easily resize the disk limiting my flexibility in use the cloud image as a gold image foundation for my deployments.

Comment 12 Mark Thacker 2017-02-01 19:09:57 UTC
Deferring to RHEL 7.5.

Comment 13 Bryn M. Reeves 2017-06-16 10:56:32 UTC
> This would provide much greater flexibility with disk imaging and our own RHEL 
> cloud images which currently do not use lvm for /dev/sda.  So if I deploy a 
> cloud image, I cannot easily resize the disk limiting my flexibility in use the 
> cloud image as a gold image foundation for my deployments.

I can understand the limitation here, in terms of conventional partitions not allowing straightforward resize, but it's not quite clear to me why being able to place /boot on LVM2 would fix it?

What's the restriction that prevents the cloud images from using LVM devices on sda in this scenario? (with a conventional partition for /boot as in a regular installation).

Comment 15 Jonathan Earl Brassow 2017-07-26 14:42:39 UTC
We would like to add more boot time features, like booting to a snapshot (or group of snapshots); but eliminating /boot is a tall order - especially with UEFI booting.  This may never happen and certainly won't happen in RHEL7.

Comment 16 Christoph Karl 2020-03-10 11:49:46 UTC
Currently I need two block devices to setup a VM.
One as a PV for LVM (without partioning for resize reasoning) and one only for /boot.
Would be a bit easier, if I only need one block device per VM.

Comment 17 Christian Horn 2020-03-11 00:09:26 UTC
(In reply to Christoph Karl from comment #16)
> Currently I need two block devices to setup a VM.
> One as a PV for LVM (without partioning for resize reasoning) and one only
> for /boot.
> Would be a bit easier, if I only need one block device per VM.

RHEL7 and 8 can still be installed with "everything on one partition", 
I think you are referring to that.

$ cat /proc/partitions 
major minor  #blocks  name

 253        0  150994944 vda
 253        1    8388608 vda1
  11        0    1048575 sr0

Comment 18 Christoph Karl 2020-03-11 07:27:09 UTC
Currently I have:
>lsblk                                                                                               
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT                                                    
vda           252:0    0    1G  0 disk 
└─vda1        252:1    0 1023M  0 part /boot
vdb           252:16   0   50G  0 disk 
├─rhel-root   253:0    0   40G  0 lvm  /
└─rhel-lvlogs 253:1    0    2G  0 lvm  /logs

Two block devices: vda und vdb.
The PV on vdb must be without partitioning so I can resize the PV.

I want to have:
>lsblk                                                                                               
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT                                                    
vda           252:0    0   50G  0 disk 
├─rhel-root   253:0    0   40G  0 lvm  /
└─rhel-lvlogs 253:1    0    2G  0 lvm  /logs

Only one block device: vda
Reasoning:
*) Only one block device per VM
*) I can online-resize any filesystem in this VM

Comment 19 Christoph Karl 2020-03-11 07:29:04 UTC
This would also be OK:
>lsblk                                                                                               
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT                                                    
vda           252:0    0   50G  0 disk 
├─rhel-root   253:0    0   40G  0 lvm  /
├─rhel-boot   253:1    0 1023M  0 lvm  /boot
└─rhel-lvlogs 253:2    0    2G  0 lvm  /logs

Comment 20 Christian Horn 2020-03-11 07:40:40 UTC
Both of the variants you aim at have /boot on LVM, which will for the time
being not become supported, the bugzilla state reflects this.

The next best thing for you might be:
- to have a single blockdevice into the guest
- to have /boot on a partition (which is not resizable in very
  flexible ways, so the size should be chosen carefully)
- to have a further partition, and inside LVM.
  In case you extend the blockdevice in the future, you can
  just add a further partition and use it to extend the VG.
  Alternatively, you can consider to extend the partition 
  and resize the existing PV.

$ lsblk
NAME                   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda                    252:0    0   72G  0 disk 
├─vda1                 252:1    0    1G  0 part /boot
└─vda2                 252:2    0   71G  0 part 
  └─rhel_rhel8u2b-root 253:0    0   45G  0 lvm  /

Comment 21 Christoph Karl 2020-03-11 08:02:36 UTC
AFAIK "adding further partitions" and "extending a partition" are not supported:
https://access.redhat.com/solutions/199573

I see this as a feature request not as a bug report.
Currently I stick to two block devices.

Comment 22 Christian Horn 2020-03-12 01:11:51 UTC
I think the bugzilla refers to resizing of a partition which is in use.

Following 2 variants should still be open:

- If really / of the guest should be resized (low chances this is
  required, I think), then one could boot a rescue system and
  do an offline resize of the partition.
- When the underlying blockdevice got enlarged, one could still
  add an additional partition, use pvcreate, extend an LVM volume
  and with this take usage of the additional space


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