Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

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 2093220

Summary:

Leapp inhibits an upgrade with both DOS extended part and LVM

Product:

Red Hat Enterprise Linux 8

Reporter:

Christophe Besson <cbesson>

Component:

leapp-repository

Assignee:

Petr Stodulka <pstodulk>

Status:

CLOSED ERRATA

QA Contact:

Filip Suba <fsuba>

Severity:

medium

Docs Contact:

Priority:

medium

Version:

8.6

CC:

bfu, jshimkus, mmacura, prjagtap, pstodulk, virt-qe-z, wlootlxt123

Target Milestone:

Keywords:

OtherQA, Patch, Reproducer, Triaged, WorkAround

Target Release:

---

Flags:

pm-rhel: mirror+

Hardware:

All

OS:

Linux

Whiteboard:

Fixed In Version:

leapp-repository-0.17.0-1.el8

Doc Type:

If docs needed, set a value

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2022-11-08 09:46:44 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Bug Depends On:

Bug Blocks:

2099813, 2099814

Attachments:

Description	Flags
sosreport	none

Description Christophe Besson 2022-06-03 10:34:25 UTC

Description of problem:
Issue reproduced during an IPU to 9.0 with a RHEL 8.6 installed with DOS parts with an LVM VG behind the extended part (vda4). The upgrade is inhibited with "Inhibitor: VDO devices migration to LVM management".

I didn't check if it also applies to a 7.9->8.6 IPU.

Version-Release number of selected component (if applicable):
leapp-upgrade-el8toel9-0.16.0-6.el8_6

How reproducible:
Always

Steps to Reproduce:
1. Install a RHEL 8.6 (append inst.nopgt to the kernel cmdline for anaconda)
2. Create a custom partition layout with "Standard partitions", at least 5 in order to create an extended partition with one of them being an LVM VG.
3. Install vdo (to have the /usr/libexec/vdoprepareforlvm binary)
4. Run a leapp preupgrade

Actual results:
Upgrade has been inhibited due to the following problems:
    1. Inhibitor: VDO devices migration to LVM management

# head -n6 /var/log/leapp/leapp-report.txt 
Risk Factor: high (inhibitor)
Title: VDO devices migration to LVM management
Summary: Unexpected result checking device
unexpected error from 'vdoprepareforlvm' for vda4; result = 2
Remediation: [hint] Resolve the conditions leading to the reported failure and re-run the upgrade.
Key: f7c335398cc449f5d7baf4e73255d44c34ad2620

Additional info:
* vdoprepareforlvm returns 2 for an extended partition, which is not handled by leapp.

* Data from the reproducer

# echo p | fdisk /dev/vda

Welcome to fdisk (util-linux 2.32.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): Disk /dev/vda: 30 GiB, 32212254720 bytes, 62914560 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xffed4777

Device     Boot    Start      End  Sectors  Size Id Type
/dev/vda1  *        2048  1953791  1951744  953M 83 Linux
/dev/vda2        1953792 21483519 19529728  9.3G 83 Linux
/dev/vda3       21483520 25389055  3905536  1.9G 83 Linux
/dev/vda4       25389056 62914559 37525504 17.9G  5 Extended
/dev/vda5       25391104 29296639  3905536  1.9G 83 Linux
/dev/vda6       29298688 33204223  3905536  1.9G 83 Linux
/dev/vda7       33206272 37111807  3905536  1.9G 82 Linux swap / Solaris
/dev/vda8       37113856 41029631  3915776  1.9G 8e Linux LVM

# lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0           11:0    1 1024M  0 rom  
vda          253:0    0   30G  0 disk 
├─vda1       253:1    0  953M  0 part /boot
├─vda2       253:2    0  9.3G  0 part /
├─vda3       253:3    0  1.9G  0 part /app
├─vda4       253:4    0    1K  0 part 
├─vda5       253:5    0  1.9G  0 part /home
├─vda6       253:6    0  1.9G  0 part /opt
├─vda7       253:7    0  1.9G  0 part [SWAP]
└─vda8       253:8    0  1.9G  0 part 
  └─rhel-lvm 252:0    0  1.9G  0 lvm  /lvm

# /usr/libexec/vdoprepareforlvm --check /dev/vda1
# echo $?
255

# /usr/libexec/vdoprepareforlvm --check /dev/vda4
vdoprepareforlvm: Unexpected error accessing '/dev/vda4' : VDO Status: Out of range
# echo $?
2

* Workaround fixing the reproducer

--- /usr/share/leapp-repository/repositories/system_upgrade/el8toel9/actors/vdoconversionscanner/libraries/vdoconversionscanner.py.orig	2022-06-03 06:18:49.038857967 -0400
+++ /usr/share/leapp-repository/repositories/system_upgrade/el8toel9/actors/vdoconversionscanner/libraries/vdoconversionscanner.py	2022-06-03 06:19:09.756216245 -0400
@@ -60,7 +60,7 @@
 
             device = '/dev/{0}'.format(lsblk.name)
             result = _check_vdo_pre_conversion(device)
-            if result not in (255, 0, 1):
+            if result not in (255, 0, 1, 2):
                 failure = ('unexpected error from \'vdoprepareforlvm\' for {0}; '
                            'result = {1}'.format(lsblk.name, result))
                 undetermined_conversion_devices.append(
@@ -69,7 +69,7 @@
                                                            failure=failure))
                 continue
 
-            if result == 255:
+            if result in (255, 2):
                 # Not a vdo.
                 continue

Comment 1 Christophe Besson 2022-06-03 10:57:15 UTC

I just noticed removing the vdo package does not trigger this issue anymore (that can be done only if VDO is not used for sure).

    # dnf remove vdo
    # leapp answer --section check_vdo.no_vdo_devices=True

Comment 2 Christophe Besson 2022-07-13 13:19:04 UTC

Adding a customer case with the very same symptoms.
But it's not caused by the same partition layout.

One of the disk causing the issue had the below partition layout:

Disk /dev/sdd: 1.7 TiB, 1858174650368 bytes, 3629247364 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: XXX

Device     Start        End    Sectors  Size Type
/dev/sdd1     34 3629247330 3629247297  1.7T Microsoft basic data

Comment 3 Petr Stodulka 2022-07-15 10:39:05 UTC

@jshimkus Hi Joe, could you take look at it when you are here?

Comment 4 Joe Shimkus 2022-07-15 15:46:49 UTC

I set up a similar configuration:

# fdisk -l /dev/sdb
Disk /dev/sdb: 30 GiB, 32212254720 bytes, 62914560 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xac357c11

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sdb1           2048  1953791  1951744  953M 83 Linux
/dev/sdb2        1953792 21483519 19529728  9.3G 83 Linux
/dev/sdb3       21483520 25389055  3905536  1.9G 83 Linux
/dev/sdb4       25389056 62914559 37525504 17.9G  5 Extended
/dev/sdb5       25391104 29296639  3905536  1.9G 83 Linux
/dev/sdb6       29298688 33204223  3905536  1.9G 83 Linux
/dev/sdb7       33206272 37111807  3905536  1.9G 83 Linux
/dev/sdb8       37113856 41029631  3915776  1.9G 83 Linux

And got the same error:

# ./vdoprepareforlvm --check /dev/sdb4
vdoprepareforlvm: Unexpected error accessing '/dev/sdb4' : VDO Status: Out of range

The origin, from vdoprepareforlvm's perspective, is that BLKGETSIZE64 returns 1024:

274	    if (ioctl(layer->fd, BLKGETSIZE64, &bytes) < 0) {
(gdb) n
280	    deviceBlocks = bytes / VDO_BLOCK_SIZE;
(gdb) p bytes
$12 = 1024

which, when converted to deviceBlocks becomes 0 which results in vdo i/o requests to the device being out of range.

You can also see the 1024 in lsblk output:

# lsblk
NAME                      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                         8:0    0  256G  0 disk 
├─sda1                      8:1    0    1G  0 part /boot
└─sda2                      8:2    0  255G  0 part 
  ├─rhel_rhel86--min-root 253:0    0   70G  0 lvm  /
  ├─rhel_rhel86--min-swap 253:1    0    2G  0 lvm  [SWAP]
  └─rhel_rhel86--min-home 253:2    0  183G  0 lvm  /home
sdb                         8:16   0   30G  0 disk 
├─sdb1                      8:17   0  953M  0 part 
├─sdb2                      8:18   0  9.3G  0 part 
├─sdb3                      8:19   0  1.9G  0 part 
├─sdb4                      8:20   0    1K  0 part 
├─sdb5                      8:21   0  1.9G  0 part 
├─sdb6                      8:22   0  1.9G  0 part 
├─sdb7                      8:23   0  1.9G  0 part 
└─sdb8                      8:24   0  1.9G  0 part 
sr0                        11:0    1 71.3M  0 rom

Comment 5 Joe Shimkus 2022-07-15 15:52:42 UTC

This implies that the previously discussed check for "too small a device" would also work around this.

Comment 6 Petr Stodulka 2022-07-18 10:53:18 UTC

Thanks for the check. So it should be covered in future by the following PR:
  https://github.com/oamg/leapp-repository/pull/919

Comment 7 Petr Stodulka 2022-07-26 15:37:20 UTC

*** Bug 2090830 has been marked as a duplicate of this bug. ***

Comment 8 Petr Stodulka 2022-08-19 14:16:13 UTC

The PR has been merged in upstream.

Comment 11 Filip Suba 2022-08-29 12:28:44 UTC

Verified with leapp-repository-0.17.0-1.el8.

# lsblk
NAME                      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                         8:0    0   30G  0 disk
├─sda1                      8:1    0   10G  0 part
└─sda2                      8:2    0    1K  0 part
dasda                      94:0    0 38.2G  0 disk
├─dasda1                   94:1    0    1G  0 part /boot
└─dasda2                   94:2    0 37.2G  0 part

Disk /dev/sda: 30 GiB, 32212254720 bytes, 62914560 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 8388608 bytes
Disklabel type: dos
Disk identifier: 0x3e042cc6

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sda1          16384 20987903 20971520   10G 83 Linux
/dev/sda2       20987904 58513408 37525505 17.9G  5 Extended

INFO     PID: 40012 leapp.workflow.FactsCollection: Executing actor vdo_conversion_scanner
DEBUG    PID: 42634 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has started: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/sda']
DEBUG    PID: 42634 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has finished: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/sda']
DEBUG    PID: 42634 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has started: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/sda1']
DEBUG    PID: 42634 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has finished: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/sda1']
DEBUG    PID: 42634 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has started: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/dasda']
DEBUG    PID: 42634 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has finished: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/dasda']
DEBUG    PID: 42634 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has started: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/dasda1']
DEBUG    PID: 42634 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has finished: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/dasda1']
DEBUG    PID: 42634 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has started: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/dasda2']
DEBUG    PID: 42634 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has finished: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/dasda2']
INFO     PID: 40012 leapp.workflow.Checks: Executing actor check_vdo

The same configuration with leapp-repository-0.16.0-9.el8
============================================================
                     UPGRADE INHIBITED              
============================================================

Upgrade has been inhibited due to the following problems:
    1. Inhibitor: VDO devices migration to LVM management

INFO     PID: 45696 leapp.workflow.FactsCollection: Executing actor vdo_conversion_scanner
DEBUG    PID: 47928 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has started: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/sda']
DEBUG    PID: 47928 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has finished: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/sda']
DEBUG    PID: 47928 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has started: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/sda1']
DEBUG    PID: 47928 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has finished: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/sda1']
DEBUG    PID: 47928 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has started: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/sda2']
DEBUG    PID: 47928 leapp.workflow.FactsCollection.vdo_conversion_scanner: vdoprepareforlvm: Unexpected error accessing '/dev/sda2' : VDO Status: Out of range
DEBUG    PID: 47928 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has finished: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/sda2']
DEBUG    PID: 47928 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has started: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/dasda']
DEBUG    PID: 47928 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has finished: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/dasda']
DEBUG    PID: 47928 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has started: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/dasda1']
DEBUG    PID: 47928 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has finished: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/dasda1']
DEBUG    PID: 47928 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has started: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/dasda2']
DEBUG    PID: 47928 leapp.workflow.FactsCollection.vdo_conversion_scanner: External command has finished: ['/usr/libexec/vdoprepareforlvm', '--check', '/dev/dasda2']
INFO     PID: 45696 leapp.workflow.Checks: Executing actor check_vdo

Comment 12 IBM Bug Proxy 2022-10-20 08:51:56 UTC

Created attachment 1919208 [details]
sosreport

Comment 14 errata-xmlrpc 2022-11-08 09:46:44 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (leapp-repository bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7590