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 1595129 - Provide better information when vdo cannot be started because of superblock (Unknown error 2081 and 2066)
Summary: Provide better information when vdo cannot be started because of superblock (...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: vdo
Version: 7.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Joe Shimkus
QA Contact: Jakub Krysl
URL:
Whiteboard:
Depends On:
Blocks: 1599761
TreeView+ depends on / blocked
 
Reported: 2018-06-26 08:15 UTC by Jakub Krysl
Modified: 2019-03-06 02:41 UTC (History)
5 users (show)

Fixed In Version: 6.1.1.106
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1599761 (view as bug list)
Environment:
Last Closed: 2018-10-30 09:39:49 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3094 0 None None None 2018-10-30 09:40:14 UTC

Description Jakub Krysl 2018-06-26 08:15:31 UTC 
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:
Comment 2 Bryan Gurney 2018-06-26 12:31:53 UTC 
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".
Comment 4 Jakub Krysl 2018-07-18 11:10:15 UTC 
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
Comment 6 errata-xmlrpc 2018-10-30 09:39:49 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, 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
Note You need to log in before you can comment on or make changes to this bug.