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 2074486 - [util-linux] Command (wipefs -a) to erase all available signatures against read only rom return 0 with dmesg error
Summary: [util-linux] Command (wipefs -a) to erase all available signatures against re...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: util-linux
Version: 9.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Karel Zak
QA Contact: minl
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-04-12 10:33 UTC by minl
Modified: 2022-11-15 13:22 UTC (History)
4 users (show)

Fixed In Version: util-linux-2.37.4-8.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-15 11:23:24 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+


Attachments (Terms of Use)
vm_dump_xml (9.37 KB, text/plain)
2022-04-12 10:33 UTC, minl
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-118642 0 None None None 2022-04-12 10:35:05 UTC
Red Hat Product Errata RHBA-2022:8404 0 None None None 2022-11-15 11:23:32 UTC

Description minl 2022-04-12 10:33:31 UTC
Created attachment 1871932 [details]
vm_dump_xml

Description of problem:
[util-linux] Command (wipefs -a) to erase all available signatures against read only rom return 0 with dmesg error

Version-Release number of selected component (if applicable):
Guest:
RHEL-9.0.0-20220410

# rpm -qf /usr/sbin/wipefs
util-linux-2.37.4-3.el9.x86_64

How reproducible:
100%

Steps to Reproduce:

1. Create a VM with iso data in read only cdrom:
 </disk>
    <disk type='network' device='cdrom'>
      <driver name='qemu' type='raw' error_policy='report' io='native'/>
      <source protocol='iscsi' name='iqn.2010-06.com.nutanix:vmdisk-ecb97311-9a3b-480e-8ad0-ebaed398c5c2/0'>
        <host name='127.0.0.1' port='3261'/>
      </source>
      <target dev='hdd' bus='ide'/>
      <readonly/>
      <boot order='1'/>
      <alias name='ide0-1-1'/>
      <address type='drive' controller='0' bus='1' target='0' unit='1'/>
    </disk>
Full dumpXML file will attach in bugzilla

2. Command (wipefs -a) to erase all available signatures against read only rom return 0 with dmesg error:
# lsblk  
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda      8:0    0   10G  0 disk
|-sda1   8:1    0    1M  0 part
|-sda2   8:2    0  200M  0 part /boot/efi
|-sda3   8:3    0  500M  0 part /boot
`-sda4   8:4    0  9.3G  0 part /
sr0     11:0    1 1024M  0 rom  
sr1     11:1    1  380K  0 rom  

# wipefs /dev/sr1
DEVICE OFFSET TYPE    UUID                   LABEL
sr1    0x8001 iso9660 2022-04-12-12-35-39-00 config-2

wipefs -a /dev/sr1
/dev/sr1: 5 bytes were erased at offset 0x00008001 (iso9660): 43 44 30 30 31

# echo $?
0

[root@minl-9 ~]# dmesg -T | grep error
[Tue Apr 12 01:16:43 2022] critical target error, dev sr1, sector 64 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
[Tue Apr 12 01:16:43 2022] Buffer I/O error on dev sr1, logical block 8, lost async page write

Actual Results:
Command "wipefs -a /dev/sr1" return 0

Expected Results:
Command "wipefs -a /dev/sr1" should return 1

Additional info:
RHEL-8.6.0-20220409.0 has no such issue:
# rpm -qf /usr/sbin/wipefs
util-linux-2.32.1-35.el8.x86_64

# wipefs /dev/sr1
DEVICE OFFSET TYPE    UUID                   LABEL
sr1    0x8001 iso9660 2022-04-12-10-20-44-00 config-2

# wipefs -a /dev/sr1
wipefs: error: /dev/sr1: probing initialization failed: Read-only file system

# echo $?
1

Comment 1 Karel Zak 2022-04-13 08:45:21 UTC
Sounds like wipefs is able to open the device for write and the write() call is successful. 

Can you confirm this? For example by "strace -o log wipefs -a /dev/sr1".

If yes, then wipefs has no way how to report the issue.

Comment 2 Wei Shi 2022-04-13 09:18:16 UTC
Hi Karel,
  It's introduced by this patch https://github.com/util-linux/util-linux/commit/39f5af25982d8b0244000e92a9d0e0e6557d0e17
  and the return value of the cmd is 0, but the data is not changed actually if we check with "wipefs -J /dev/sr1" before and after we run "wipefs -a /dev/sr1"

Comment 4 minl 2022-04-13 09:53:02 UTC
(In reply to Karel Zak from comment #1)
> Sounds like wipefs is able to open the device for write and the write() call
> is successful. 
> 
> Can you confirm this? For example by "strace -o log wipefs -a /dev/sr1".
> 
> If yes, then wipefs has no way how to report the issue.

Hi Karel:

I saw an "(Input/output error)" in following section in strace log and the whole log was attached:

lseek(3, 32769, SEEK_SET)               = 32769
write(3, "\0\0\0\0\0", 5)               = 5
fsync(3)                                = -1 EIO (Input/output error)
newfstatat(1, "", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}, AT_EMPTY_PATH) = 0
write(1, "/dev/sr1: 5 bytes were erased at"..., 77) = 77
lseek(3, 32768, SEEK_SET)               = 32768

Comment 5 Karel Zak 2022-04-19 07:22:08 UTC
Thanks for debugging. You're right, libblkid as well as wipefs do not check fsync() and close() return value. That's a mistake for O_NONBLOCK.

Comment 6 Karel Zak 2022-04-19 07:54:23 UTC
Minl and Wei Shi, can you guys try the latest upstream in your environment? (git clone https://github.com/util-linux/util-linux)

I have improved the code to check fsync() and close() return code:
https://github.com/util-linux/util-linux/commit/133a0d70f637b4f4e4337811e452153b04f2bdcf

but I'm not able to reproduce your issue on my workstation, so it would be nice to have confirmation from you ;-) Thanks!

Comment 7 Wei Shi 2022-04-19 09:06:01 UTC
Karel,
  My test result is PASS, btw I modified the patch a little bit in order to backport to v2.37.4
  http://pastebin.test.redhat.com/1045610

====== original util-linux-2.37.4-3.el9.x86_64 ======
# wipefs -J /dev/sr1 
{
   "signatures": [
      {
         "device": "sr1",
         "offset": "0x8001",
         "type": "iso9660",
         "uuid": "2022-04-19-16-07-37-00",
         "label": "config-2"
      }
   ]
}
# wipefs -a /dev/sr1 
/dev/sr1: 5 bytes were erased at offset 0x00008001 (iso9660): 43 44 30 30 31
# echo $?
0
# wipefs -J /dev/sr1 
{
   "signatures": [
      {
         "device": "sr1",
         "offset": "0x8001",
         "type": "iso9660",
         "uuid": "2022-04-19-16-07-37-00",
         "label": "config-2"
      }
   ]
}

====== After patched ======
# wipefs -J /dev/sr1 
{
   "signatures": [
      {
         "device": "sr1",
         "offset": "0x8001",
         "type": "iso9660",
         "uuid": "2022-04-19-16-07-37-00",
         "label": "config-2"
      }
   ]
}
# wipefs -a /dev/sr1 
wipefs: /dev/sr1: failed to erase iso9660 magic string at offset 0x00008001: Input/output error
# echo $?
1
# wipefs -J /dev/sr1 
{
   "signatures": [
      {
         "device": "sr1",
         "offset": "0x8001",
         "type": "iso9660",
         "uuid": "2022-04-19-16-07-37-00",
         "label": "config-2"
      }
   ]
}

Comment 8 Karel Zak 2022-04-20 07:57:23 UTC
(In reply to Wei Shi from comment #7)
>   My test result is PASS, btw I modified the patch a little bit in order to
> backport to v2.37.4  http://pastebin.test.redhat.com/1045610

Thanks for your feedback!

Comment 9 minl 2022-08-25 04:13:52 UTC
[root@minl-9 ~]# rpm -qf /usr/sbin/wipefs 
util-linux-2.37.4-8.el9.x86_64
[root@minl-9 ~]# 
[root@minl-9 ~]# wipefs -J /dev/sr1
{
   "signatures": [
      {
         "device": "sr1",
         "offset": "0x8001",
         "type": "iso9660",
         "uuid": "2022-08-18-17-58-53-00",
         "label": "config-2"
      }
   ]
}
[root@minl-9 ~]# 
[root@minl-9 ~]# wipefs -a /dev/sr1
wipefs: /dev/sr1: failed to erase iso9660 magic string at offset 0x00008001: Input/output error
[root@minl-9 ~]# 
[root@minl-9 ~]# echo $?
1
[root@minl-9 ~]# 
[root@minl-9 ~]# wipefs -J /dev/sr1
{
   "signatures": [
      {
         "device": "sr1",
         "offset": "0x8001",
         "type": "iso9660",
         "uuid": "2022-08-18-17-58-53-00",
         "label": "config-2"
      }
   ]
}

Comment 13 minl 2022-08-29 01:58:04 UTC
# cat /etc/redhat-release 
Red Hat Enterprise Linux release 9.1 Beta (Plow)
# rpm -qf /usr/sbin/wipefs 
util-linux-2.37.4-8.el9.x86_64
# wipefs -a /dev/sr1
wipefs: /dev/sr1: failed to erase iso9660 magic string at offset 0x00008001: Input/output error
# echo $?
1

Comment 15 errata-xmlrpc 2022-11-15 11:23:24 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 (util-linux 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:8404


Note You need to log in before you can comment on or make changes to this bug.