-
Bug
-
Resolution: Duplicate
-
Normal
-
None
-
rhel-9.5
-
None
-
No
-
Moderate
-
rhel-storage-management
-
ssg_platform_storage
-
None
-
False
-
False
-
-
None
-
None
-
None
-
None
-
Unspecified
-
Unspecified
-
Unspecified
-
-
x86_64
-
None
What were you trying to do that didn't work?
Customer is trying to install RHEL 9.5 OS onto DELL R660 Server.
While performing the installation the system fails with a crash (see video attached) when they clear the old partition in the anaconda menu and then clear old partition and click auto-partitioning and then remove /home partition.
Customer had also tried wiping the earlier installation completed and then retried installation but he again observed that when he removed /home partition form auto partitioning they again faced the issue.
We have the anaconda logs and what we see is that there is space computation is showing negative space.
The anaconda process crashes with the following python trace after the system computed the free space to be "-4 MiB"
This free space value cannot be negative and hence it crashes.
~~~
DEBUG:blivet:rhel_mbldbd91 size is 74 GiB
DEBUG:blivet:vg rhel_mbldbd91 has -4 MiB free
WARNING:dasbus.server.handler:The call org.fedoraproject.Anaconda.Modules.Storage.DeviceTree.Scheduler.GetContainerFreeSpace has failed with an exception:
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/dasbus/server/handler.py", line 423, in _method_callback
self._handle_method_result(
File "/usr/lib/python3.9/site-packages/dasbus/server/handler.py", line 465, in _handle_method_result
self._server.set_call_reply(
File "/usr/lib/python3.9/site-packages/dasbus/server/handler.py", line 136, in set_call_reply
reply_value = get_variant(out_type, (out_value, ))
File "/usr/lib/python3.9/site-packages/dasbus/typing.py", line 124, in get_variant
return Variant(type_string, value)
File "/usr/lib/python3.9/site-packages/gi/overrides/GLib.py", line 189, in _new_
v = creator._create(format_string, value)
File "/usr/lib/python3.9/site-packages/gi/overrides/GLib.py", line 150, in _create
builder.add_value(self._create(dup, i))
File "/usr/lib/python3.9/site-packages/gi/overrides/GLib.py", line 118, in _create
return self._LEAF_CONSTRUCTORS[format](value)
OverflowError: -4194304 not in range 0 to 18446744073709551615
~~~
Since we could not reproduce this issue over other system or Virtual machine, we had asked customer to also check with DELL support and they had the following finding,
~~~
The system was shipped with the H965i fPERC (PERC12) controller and two 480GB SSD Drives that are 512e drives
The PERC12 now features an advanced engine that significantly enhances its performance when processing data. It is essential to note that a 4K base unit sector size is required for optimal performance.
Additionally, all PERC12 Virtual Disks (VDs) will be created with a 4k block size, regardless of the sector size of the individual drives that comprise the VD.
In contrast to older PERC controllers, the current generation uses 4k block sizes for virtual drives that do not necessarily match the physical drive sector size. This is a deliberate design choice and cannot be altered by the user.
If the drive is in passthrough mode (non-RAID), it will remain unchanged. In the case of a 512b drive, it will pass through as 512b.
~~~
So it seems the RAID Virtual Drive created uses 4K block size independent of what the underlying blocksize of the original disk is. As per DELL, these are new controller improvement and improves the performance.
Customer teste by doing a pass-through the disk, meaning installing without RAID, we were able to get the installation working. However when configured RAID, your system faces this issue.
Customer say that here he anaconda process seems to not properly handle disk using 4K sector blocks instead of 512b sector blocks.
Later on after discussing this issue internally with rhn-support-rmetrich , he suspected this is happening because because the LVM VG is configured to expand automatically in the Volume group policy. So when customer remove /home, the reconfiguration of the volume group size computation fails. So we suggested to then set the volume group policy as "As large as possible" after
~~~
Volume Group -> Modify
Size Policy -> As large as possible
~~~~
With this workaround the system installation completed without crashing.
So it seems that the crash indeed happens when recomputing the size of the VG.
What is the impact of this issue to you?
Os installation fails when re-configuring partitioning in the anaconda installer due to which customer was not able to perform installation on this hardware.
Please provide the package NVR for which the bug is seen:
RHEL 9.5 Installer ISO
How reproducible is this bug?:
Everytime
Steps to reproduce
- Configure a DELL R660 system with H965i fPERC (PERC12) controller RAID which will get created with 4K block size
- Boot the system into Anaconda installer and select "Custom partitioning" and then click on "Click here to create partition automatically"
- Once you see the automatic partition created, remove "/home" partition and we will see that anaconda crashed in a few seconds.
Expected results
Anaconda should not crash when removing/adding partitions.
Actual results
Currently anaconda crashes when re-configuring the volume group size when we add/remove partitions.
- duplicates
-
RHEL-39981 OverflowError: -12582912 not in range 0 to 18446744073709551615; vg rhel_sheep-2 has -12 MiB free
-
- Planning
-