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 2074486

Summary: [util-linux] Command (wipefs -a) to erase all available signatures against read only rom return 0 with dmesg error
Product: Red Hat Enterprise Linux 9 Reporter: minl <minl>
Component: util-linuxAssignee: Karel Zak <kzak>
Status: CLOSED ERRATA QA Contact: minl <minl>
Severity: medium Docs Contact:
Priority: medium    
Version: 9.0CC: shshang, wshi, xiliang, yacao
Target Milestone: rcKeywords: Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: util-linux-2.37.4-8.el9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-11-15 11:23:24 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:
Attachments:
Description Flags
vm_dump_xml none

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