EFI::UNEXPECTED_ERROR when blkid -p -s PART_ENTRY_NUMBER is empty

[BradLugo]

Hello Conversions team!

I'm running into an issue when calling convert2rhel analyze on a Rocky 8 system that's using mdadm. In particular, there seems to be a problem during the Check the firmware interface type (BIOS/UEFI):

[2024-04-03T06:46:53+0200] TASK - [Prepare: Check the firmware interface type (BIOS/UEFI)] ***********
UEFI detected.
[2024-04-03T06:46:53+0200] DEBUG - Calling command 'mokutil --sb-state'
[2024-04-03T06:46:53+0200] DEBUG - Calling command '/usr/sbin/efibootmgr -v'
[2024-04-03T06:46:53+0200] DEBUG - Bootloader setup:
Current boot: 0004
Boot order: 0000, 0003, 0004, 0005, 0006, 0001
Boot entries:
- 0000: Rocky Linux
- 0001: UEFI: Built-in EFI Shell
- 0003: UEFI: PXE IP4 P0 Intel(R) I210 Gigabit  Network Connection
- 0004: UEFI OS
- 0005: UEFI OS
- 0006: UEFI OS
[2024-04-03T06:46:53+0200] DEBUG - Calling command '/usr/sbin/grub2-probe --target=device /boot/efi/'
[2024-04-03T06:46:53+0200] DEBUG - Calling command '/usr/sbin/blkid -p -s PART_ENTRY_NUMBER /dev/md0'
ERROR - (ERROR) EFI::UNEXPECTED_ERROR - Unhandled exception caught
 Description: Unhandled exception was caught: invalid literal for int() with base 10: '\n'
Please file a bug at https://issues.redhat.com/ to have this fixed or a specific error message added.
Traceback: Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/convert2rhel/actions/__init__.py", line 572, in run
    action.run()
  File "/usr/lib/python3.6/site-packages/convert2rhel/actions/system_checks/efi.py", line 74, in run
    grub.get_device_number(grub.get_efi_partition())
  File "/usr/lib/python3.6/site-packages/convert2rhel/grub.py", line 178, in get_device_number
    return int(partition_number)
ValueError: invalid literal for int() with base 10: '\n'

 Diagnosis: N/A
 Remediations: N/A

EUS_SYSTEM_CHECK has succeeded

Admittedly, I didn't configure the software RAID myself, so maybe this is user error? Interested in any insight yall have. Also happy to help debug or submit a PR after figuring out what the problem is 🙂

[BradLugo]

This seems to be the cause (specifically the int(partition_number) toward the bottom):

convert2rhel/convert2rhel/grub.py

Lines 156 to 178 in 985cf34

	def get_device_number(device):
	"""Get the partition number of a particular device.
	This method will use `blkid` to determinate what is the partition number
	related to a particular device.
	:param device: The device to be analyzed.
	:type device: str
	:return: The device partition number.
	:rtype: int
	"""
	output, ecode = utils.run_subprocess(
	["/usr/sbin/blkid", "-p", "-s", "PART_ENTRY_NUMBER", device], print_output=False
	)
	if ecode:
	logger.debug("blkid output:\n-----\n%s\n-----" % output)
	raise BootloaderError("Unable to get information about the '%s' device" % device)
	# We are spliting the partition entry number, and we are just taking that
	# output as our desired partition number
	if not output:
	raise BootloaderError("The '%s' device has no PART_ENTRY_NUMBER" % device)
	partition_number = output.split("PART_ENTRY_NUMBER=")[-1].replace('"', "")
	return int(partition_number)

I'm not too familiar with these lower-level details (trying to get better 😄), but I'm also having a difficult time figuring out what we might use the partition entry number for since the caller doesn't give any hints (at least, not with my current understanding):

convert2rhel/convert2rhel/actions/system_checks/efi.py

Lines 70 to 83 in 985cf34

	# Get information about the bootloader. Currently, the data is not used, but it's
	# good to check that we can obtain all the required data before the PONR.
	try:
	efiboot_info = grub.EFIBootInfo()
	grub.get_device_number(grub.get_efi_partition())
	except grub.BootloaderError as e:
	self.set_result(
	level="ERROR",
	id="BOOTLOADER_ERROR",
	title="Bootloader error detected",
	description="An unknown bootloader error occurred, please look at the diagnosis for more information.",
	diagnosis=str(e),
	)
	return

[bocekm]

I'd say this is not resolved. With #1169 convert2rhel does not traceback but still provides just a more graceful error message. The problem seems to be that we can't handle RAID+UEFI. A similar issue has been reported under #1247. Let's continue tracking the problem there.