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: ---   
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