-
Bug
-
Resolution: Done
-
Critical
-
None
-
rhel-9.3.0
-
None
-
Critical
-
sst_image_builder
-
ssg_front_door
-
None
-
False
-
-
None
-
None
-
Approved Exception
-
None
-
None
-
Bug Fix
-
-
Done
-
-
Unspecified
-
None
Description of problem:
Image Builder is responsible for creating all RHEL cloud images. In the case of /boot, it firstly creates a 500 MiB, and then runs `mkfs.xfs -m uuid=3e199562-8a95-43c5-b90b-1cdebb99a29c -L boot`. This process is the same for both 9.2 and 9.3 images.
However, we found a difference in the available space on the /boot partition on 9.2 and 9.3.
9.2:
[admin@vm ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 495M 156M 340M 32% /boot
[admin@vm ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 10G 0 disk
├─sda3 8:3 0 500M 0 part /boot
9.3:
[admin@vm ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 436M 170M 267M 39% /boot
[admin@vm ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 10G 0 disk
├─sda3 8:3 0 500M 0 part /boot
See that /boot on 9.2 is 495M big, but on 9.3 it's 436M.
I investigated more and discovered this:
9.2:
$ rpm -q xfsprogs
xfsprogs-5.14.2-1.el9.x86_64
$ truncate -s 500M /tmp/file
$ mkfs.xfs /tmp/file
meta-data=/tmp/file isize=512 agcount=4, agsize=32000 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1 bigtime=1 inobtcount=1
data = bsize=4096 blocks=128000, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=1368, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
$ sudo mkdir /mnt/xfs
$ sudo mount /tmp/file /mnt/xfs
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda3 495M 437M 59M 89% /boot
9.3 (well, actually CentOS Stream 9):
$ rpm -q xfsprogs
xfsprogs-5.19.0-4.el9.x86_64
$ truncate -s 500M /tmp/file
$ mkfs.xfs /tmp/file
meta-data=/tmp/file isize=512 agcount=4, agsize=32000 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1 bigtime=1 inobtcount=1 nrext64=0
data = bsize=4096 blocks=128000, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=16384, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
$ sudo mkdir /mnt/xfs
$ sudo mount /tmp/file /mnt/xfs
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda3 495M 401M 95M 81% /boot
See that mkfs.xfs reports a different number of blocks in the log section. 9.2 shows 1368, whereas 9.3 shows 16384.
((16384 - 1368)*4096 B) to MiB is 58.6 MiB, which is equal to the size difference between those two df -h calls.
I'm not sure if this is an expected change, thus reporting a bug. Note that customers might see this as a bug, because we usually don't change partitioning during a major release lifecycle. I think this leaves us with the following options:
1) The change is reverted in xfsprogs
2) Image Builder passes the right arguments to mkfs.xfs to revert the log size change.
3) We make the partition bigger.
- is cloned by
-
RHEL-14442 9.3.z: xfsprogs 5.19 changed the log size, making /boot too small
- Closed
- external trackers
- links to