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.
In the case of the device that has zeroes for the first 4 kilobytes, you should see error messages from the kvdo instance resembling the following:
kernel: kvdo5:dmsetup: Could not create kernel physical layer. (VDO error 2081, message Could not load geometry block)
kernel: kvdo5:dmsetup: mapToSystemError: mapping internal status code 2081 (kvdo: VDO_BAD_MAGIC: kvdo: Bad magic number) to EIO
VDO status code 2066 corresponds to "VDO_CHECKSUM_MISMATCH", or "Incorrect checksum".
vdo-6.1.1.111-3.el7:
1)
# vdo start --name vdo
Starting VDO vdo
vdo: ERROR - Could not set up device mapper for vdo
vdo: ERROR - vdodumpconfig: allocateVDO failed for '/dev/disk/by-id/scsi-3600140550ade793f6124ab5b420f3c20' with VDO Status: Bad magic number
2)
# vdo start --name vdo
Starting VDO vdo
vdo: ERROR - Could not set up device mapper for vdo
vdo: ERROR - vdodumpconfig: allocateVDO failed for '/dev/disk/by-id/scsi-3600140550ade793f6124ab5b420f3c20' with VDO Status: Incorrect checksum
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, 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-2018:3094
Description of problem: When starting VDO and vdodumpconfig fails, there are times when the failure can be guessed and told to user. The main example (A) of this is when the device under VDO changes its name and another device takes its place. This can be reproduced by changing the device manually in /etc/vdoconf.yml: # vdo create --name vdo --device /dev/sdb Creating VDO vdo Starting VDO vdo Starting compression on VDO vdo VDO instance 224 volume is ready at /dev/mapper/vdo # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 10G 0 disk └─vdo 253:3 0 6G 0 vdo loop0 7:0 0 10G 0 loop # vdo stop --name vdo Stopping VDO vdo # nano /etc/vdoconf.yml # cat /etc/vdoconf.yml | grep device device: /dev/loop0 # vdo start --name vdo --verbose Starting VDO vdo dmsetup status vdo grep MemAvailable /proc/meminfo modprobe kvdo vdodumpconfig /dev/loop0 vdo: ERROR - Could not set up device mapper for vdo vdo: ERROR - vdodumpconfig: allocateVDO failed for '/dev/loop0' with Unknown error 2081 # hexdump -C /dev/loop0 -n 4K 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00001000 # hexdump -C /dev/sdb -n 4K 00000000 64 6d 76 64 6f 30 30 31 05 00 00 00 04 00 00 00 |dmvdo001........| 00000010 00 00 00 00 5d 00 00 00 00 00 00 00 09 01 02 00 |....]...........| 00000020 92 ca 3f d7 86 6f 05 00 5f 85 92 c8 1e b9 48 59 |..?..o.._.....HY| 00000030 b4 54 64 c3 70 6b 1a b1 00 00 00 00 01 00 00 00 |.Td.pk..........| 00000040 00 00 00 00 01 00 00 00 d8 5c 0a 00 00 00 00 00 |.........\......| 00000050 00 ff ff ff 00 00 00 00 00 54 13 b6 22 00 00 00 |.........T.."...| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00001000 The same 'Unknown error 2081' can be reproduced by corrupting the head of superblock: # dd if=/dev/zero of=/dev/sdb bs=16 count=1 1+0 records in 1+0 records out 16 bytes (16 B) copied, 0.0116175 s, 1.4 kB/s # hexdump -C /dev/sdb -n 4K 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000010 00 00 00 00 5d 00 00 00 00 00 00 00 09 01 02 00 |....]...........| 00000020 92 ca 3f d7 86 6f 05 00 5f 85 92 c8 1e b9 48 59 |..?..o.._.....HY| 00000030 b4 54 64 c3 70 6b 1a b1 00 00 00 00 01 00 00 00 |.Td.pk..........| 00000040 00 00 00 00 01 00 00 00 d8 5c 0a 00 00 00 00 00 |.........\......| 00000050 00 ff ff ff 00 00 00 00 00 54 13 b6 22 00 00 00 |.........T.."...| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00001000 # vdo start --name vdo --verbose Starting VDO vdo dmsetup status vdo grep MemAvailable /proc/meminfo modprobe kvdo vdodumpconfig /dev/sdb vdo: ERROR - Could not set up device mapper for vdo vdo: ERROR - vdodumpconfig: allocateVDO failed for '/dev/sdb' with Unknown error 2081 B) Another 'Unknown error', this time 2066 can be archieved by corrupting the rest of the superblock but leaving ID intact: # vdo create --name vdo --device /dev/sdb Creating VDO vdo Starting VDO vdo Starting compression on VDO vdo VDO instance 228 volume is ready at /dev/mapper/vdo # vdo stop --name vdo Stopping VDO vdo # dd if=/dev/zero of=/dev/sdb bs=16 count=1 seek=5 1+0 records in 1+0 records out 16 bytes (16 B) copied, 0.0275596 s, 0.6 kB/s # hexdump -C /dev/sdb -n 4K 00000000 64 6d 76 64 6f 30 30 31 05 00 00 00 04 00 00 00 |dmvdo001........| 00000010 00 00 00 00 5d 00 00 00 00 00 00 00 09 01 02 00 |....]...........| 00000020 f0 ce 23 08 87 6f 05 00 62 ac cc 72 15 ff 42 46 |..#..o..b..r..BF| 00000030 8e 37 da 2d f6 35 36 34 00 00 00 00 01 00 00 00 |.7.-.564........| 00000040 00 00 00 00 01 00 00 00 d8 5c 0a 00 00 00 00 00 |.........\......| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00001000 # vdo start --name vdo --verbose Starting VDO vdo dmsetup status vdo grep MemAvailable /proc/meminfo modprobe kvdo vdodumpconfig /dev/sdb vdo: ERROR - Could not set up device mapper for vdo vdo: ERROR - vdodumpconfig: allocateVDO failed for '/dev/sdb' with Unknown error 2066 Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: A) 1. vdo create --name vdo --device /dev/sdb 2. vdo stop --name vdo 3. force device change (reproducible by changing device in /etc/vdoconf.yml) or corrupt superblock ID (first 8 bytes) 4. vdo start --name vdo B) 1. vdo create --name vdo --device /dev/sdb 2. vdo stop --name vdo 3. dd if=/dev/zero of=/dev/sdb bs=16 count=1 seek=5 4. vdo start --name vdo Actual results: A) vdo: ERROR - Could not set up device mapper for vdo vdo: ERROR - vdodumpconfig: allocateVDO failed for '/dev/loop0' with Unknown error 2081 B) vdo: ERROR - Could not set up device mapper for vdo vdo: ERROR - vdodumpconfig: allocateVDO failed for '/dev/sdb' with Unknown error 2066 Expected results: A) vdo: ERROR - Could not find VDO singnature on device '/dev/loop0', did you device name change? B) vdo: ERROR - Superblock of device '/dev/sdb' is corrupted. (point to solution?) Additional info: