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 1845368 - [virtio-win-msi] The repair function doesn't work well
Summary: [virtio-win-msi] The repair function doesn't work well
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: virtio-win
Version: 9.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 9.0
Assignee: Vadim Rozenfeld
QA Contact: xiagao
URL:
Whiteboard:
Depends On:
Blocks: 1897024 1934486
TreeView+ depends on / blocked
 
Reported: 2020-06-09 03:16 UTC by xiagao
Modified: 2023-11-07 09:30 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1934486 (view as bug list)
Environment:
Last Closed: 2023-11-07 08:29:32 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
guest tool repair log (55.55 KB, application/gzip)
2020-06-09 03:16 UTC, xiagao 		no flags Details
SetupAPI Device Installation Log (3.01 MB, text/plain)
2020-06-15 07:38 UTC, xiagao 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHEL-2429 0 None None None 2023-09-06 21:10:47 UTC
Red Hat Product Errata RHBA-2023:6388 0 None None None 2023-11-07 08:30:07 UTC

Description xiagao 2020-06-09 03:16:59 UTC 
Created attachment 1696224 [details]
guest tool repair log

Description of problem:
Virtio-win-guest-tools' repair function couldn't install the uninstalled driver.


Steps to Reproduce:
1.boot up win2019 guest with virtio device.

2.install drivers via Virtio-win-guest-tools.exe

3.uninstall rng and balloon driver
right click "My computers"-->"properties"--->"device manager"---->choose
"Virtio Balloon Driver"---> right-click "Uninstall" ---->choose "Delete the driver software for this device"--->Uninstall the driver.

4.open Virtio-win-guest-tools.exe and click repair button

5.reboot guest

6.check if rng and baloon driver is installed

Actual results:
repair function can not install rng/balloon driver
all logs are in attachment.

Expected results:
repair function can install the uninstalled driver.

Additional info:
1.qemu command line
/usr/libexec/qemu-kvm -name $1 -enable-kvm -m 6G -smp 8,maxcpus=12,cores=4,threads=1,sockets=3 -rtc base=localtime,driftfix=none -boot order=cd,menu=on -monitor stdio -qmp tcp:0:1235,server,nowait -M q35 \

-cpu 'EPYC',hv_stimer,hv_synic,hv_vpindex,hv_reset,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv-tlbflush,+kvm_pv_unhalt \
-cdrom /home/kvm_autotest_root/iso/windows/virtio-win.iso.el8 \

-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x3 \
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x3.0x1 \
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x3.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x3.0x3 \
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x3.0x4 \
-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x3.0x5 \
-device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x3.0x6 \
-device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x3.0x7 \
-device pcie-root-port,port=0x18,chassis=9,id=pci.9,bus=pcie.0,multifunction=on,addr=0x4 \

-drive file=$1,if=none,id=drive_system_disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop \
-device ide-drive,bus=ide.0,unit=0,drive=drive_system_disk,id=ide0-0-0 \


-blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/home/data-disk2.qcow2,node-name=system_file \
-blockdev driver=qcow2,node-name=drive_blk_disk,file=system_file \
-object iothread,id=thread0 -device virtio-blk-pci,iothread=thread0,drive=drive_blk_disk,id=virtio-disk0,serial=GAGENT_TEST,bus=pci.1 \

-netdev tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0,vhost=on,queues=4 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:52:11:36:4d:0d,bus=pci.2,mq=on,vectors=10 \


-device virtio-serial-pci,id=virtio-serial1,max_ports=31,bus=pci.3  \
-chardev socket,id=channel1,host=127.0.0.1,port=2222,server,nowait  -device virtserialport,bus=virtio-serial1.0,chardev=channel1,name=com.redhat.rhevm.vdsm1,id=port1 \
-chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait  -device virtserialport,bus=virtio-serial1.0,chardev=channel2,name=org.qemu.guest_agent.0,id=port2 \

-blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/home/data-disk1.qcow2,node-name=data_file \
-blockdev driver=qcow2,node-name=drive_data_disk,file=data_file \
-device virtio-scsi-pci,id=scsi0,num_queues=4,bus=pci.4 -device scsi-hd,bus=scsi0.0,drive=drive_data_disk,id=scsi-disk0 \

-object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0,bus=pci.5 \
-device virtio-balloon-pci,id=balloon0,bus=pci.6 \
-device pvpanic,id=pvpanic0,ioport=0x0505 \

-device virtio-keyboard-pci,id=kbd0,serial=virtio-keyboard,bus=pci.7 -device virtio-mouse-pci,id=mouse0,serial=virtio-mouse,bus=pci.8 -device virtio-tablet-pci,id=tablet0,serial=virtio-tablet,bus=pci.9 \


-spice id=on,disable-ticketing,port=5912 -vga qxl \\
Comment 1 Vadim Rozenfeld 2020-06-14 08:51:43 UTC 
Can yo please upload the SetupAPI.dev.log from this VM?
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/setupapi-device-installation-log-entries

Thanks,
Vadim.
Comment 2 xiagao 2020-06-15 07:38:40 UTC 
Created attachment 1697326 [details]
SetupAPI Device Installation Log
Comment 4 Peixiu Hou 2021-01-06 10:46:11 UTC 
Hit same issue on REHL8.3.1, repair function also can not install pvpanic/vioscsi driver.
And also found a interesting thing for netkvm and viostor, it will repair to previous installed driver version, but after uninstalled driver again, repair function cannot install the driver.
steps:
1. Both netkvm and viostor installed virtio-win-1.9.14-4 and then upgraded to virtio-win-1.9.15-0 with virtio-win-guest-tools.exe.
2. For netkvm, uninstalled 191 build, tried to repair, installed 189 build, then uninstalled netkvm 189 driver, tried to repair, cannot install netkvm driver as well.
3. For viostor, uninstalled 191 build, tried to repair, installed 184 build, then uninstalled viostor 184 driver, tried to repair, cannot install viostor driver as well.

Used versions:
Guest os: Windows 2016
kernel-4.18.0-240.10.1.el8_3.x86_64
qemu-kvm-5.1.0-17.module+el8.3.1+9213+7ace09c3.x86_64
seabios-bin-1.14.0-1.module+el8.3.0+7638+07cf13d2.noarch
virtio-win-1.9.15-0.el8

Best Regards~
Peixiu
Comment 5 lijin 2021-01-06 10:49:19 UTC 
(In reply to Peixiu Hou from comment #4)
> Hit same issue on REHL8.3.1, repair function also can not install
> pvpanic/vioscsi driver.
> And also found a interesting thing for netkvm and viostor, it will repair to
> previous installed driver version, but after uninstalled driver again,
> repair function cannot install the driver.

what's you guest os? if it's win10+, please make sure windows update is disabled, else guest will get drivers from windows update automatically.
Comment 6 Peixiu Hou 2021-01-06 10:54:06 UTC 
(In reply to lijin from comment #5)
> (In reply to Peixiu Hou from comment #4)
> > Hit same issue on REHL8.3.1, repair function also can not install
> > pvpanic/vioscsi driver.
> > And also found a interesting thing for netkvm and viostor, it will repair to
> > previous installed driver version, but after uninstalled driver again,
> > repair function cannot install the driver.
> 
> what's you guest os? if it's win10+, please make sure windows update is
> disabled, else guest will get drivers from windows update automatically.

I used Win2016, I updated on used versions part and yes, I checked the windows update, the service is disabled.
Comment 7 lijin 2021-01-06 11:04:20 UTC 
(In reply to Peixiu Hou from comment #6)
> (In reply to lijin from comment #5)
> > (In reply to Peixiu Hou from comment #4)
> > > Hit same issue on REHL8.3.1, repair function also can not install
> > > pvpanic/vioscsi driver.
> > > And also found a interesting thing for netkvm and viostor, it will repair to
> > > previous installed driver version, but after uninstalled driver again,
> > > repair function cannot install the driver.
> > 
> > what's you guest os? if it's win10+, please make sure windows update is
> > disabled, else guest will get drivers from windows update automatically.
> 
> I used Win2016, I updated on used versions part and yes, I checked the
> windows update, the service is disabled.

Then it sounds like step1 upgrade does not uninstall previous driver, it keep both.
So when you do step2, it install previous one.
Comment 8 Yu Wang 2021-01-07 02:52:07 UTC 
Hit same issue with virtio-net/virtio-blk/pvpanic ... all the virtio device.

Version:
Guest:win10-32/win10-64
virtio-win-1.9.14-4.el8.iso
virtio-win-1.9.15-0.el8.iso
kernel-4.18.0-240.10.1.el8_3.x86_64
qemu-kvm-5.1.0-17.module+el8.3.1+9213+7ace09c3.x86_64
seabios-1.14.0-1.module+el8.3.0+7638+07cf13d2.x86_64

Thanks
Yu Wang
Comment 9 menli@redhat.com 2021-01-07 03:14:37 UTC 
Hit same issue with all the virtio device.

Version:
Guest:win8.1/win2019
virtio-win-1.9.15-0.el8.iso
kernel-4.18.0-240.10.1.el8_3.x86_64
qemu-kvm-5.1.0-17.module+el8.3.1+9213+7ace09c3.x86_64
seabios-1.14.0-1.module+el8.3.0+7638+07cf13d2.x86_64
Comment 10 dehanmeng 2021-01-09 07:59:42 UTC 
Hit same issue with all the virtio device.

Version:
Guest:win2012/win2012r2
virtio-win-1.9.15-0.el8.iso
kernel-4.18.0-240.10.1.el8_3.x86_64
qemu-kvm-5.1.0-17.module+el8.3.1+9213+7ace09c3.x86_64
seabios-1.14.0-1.module+el8.3.0+7638+07cf13d2.x86_64
Comment 20 Vadim Rozenfeld 2021-03-16 06:23:17 UTC 
After evaluation this issue, it looks as the problem can not be solved with existing 
WiX/WixDifxAppExtension.dll toolchain because they are not support Repair/Modification 
scenario. 
Interesting thing is that Windows Installed by itself knows how to handles this situation.
Right-click -> Repair on virtio-win MSI with the following system reboot can solve the problem 
in most of the cases.

Moving this problem to 8.5

Vadim.
Comment 21 Peixiu Hou 2021-03-19 07:26:37 UTC 
Hit the same issue with virtio-win-1.9.16-2.el8.iso, tested with all the virtio devices on RHLE8.4.0 host.

Used versions:
guest os: Win10-32/64, Win2012, Win2012-r2
kernel-4.18.0-298.el8.x86_64
qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64
seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch
virtio-win-1.9.16-2.el8.iso

Thanks~
Peixiu
Comment 22 xiagao 2021-03-19 08:02:46 UTC 
(In reply to Peixiu Hou from comment #21)
> Hit the same issue with virtio-win-1.9.16-2.el8.iso, tested with all the
> virtio devices on RHLE8.4.0 host.
> 
> Used versions:
> guest os: Win10-32/64, Win2012, Win2012-r2
> kernel-4.18.0-298.el8.x86_64
> qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64
> seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch
> virtio-win-1.9.16-2.el8.iso
> 
> Thanks~
> Peixiu

The same with win2019 and win8.1-32/64 guest.
Comment 23 dehanmeng 2021-03-22 00:12:08 UTC 
(In reply to Peixiu Hou from comment #21)
> Hit the same issue with virtio-win-1.9.16-2.el8.iso, tested with all the
> virtio devices on RHLE8.4.0 host.
> 
> Used versions:
> guest os: Win10-32/64, Win2012, Win2012-r2
> kernel-4.18.0-298.el8.x86_64
> qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64
> seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch
> virtio-win-1.9.16-2.el8.iso
> 
> Thanks~
> Peixiu

The same with win8.1-64/win2016-64 guests.
Comment 24 dehanmeng 2021-03-22 03:05:13 UTC 
(In reply to dehanmeng from comment #23)
> (In reply to Peixiu Hou from comment #21)
> > Hit the same issue with virtio-win-1.9.16-2.el8.iso, tested with all the
> > virtio devices on RHLE8.4.0 host.
> > 
> > Used versions:
> > guest os: Win10-32/64, Win2012, Win2012-r2
> > kernel-4.18.0-298.el8.x86_64
> > qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64
> > seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch
> > virtio-win-1.9.16-2.el8.iso
> > 
> > Thanks~
> > Peixiu
> 
> The same with win2016-64/win8-32/64 guests
Comment 27 menli@redhat.com 2021-07-06 06:13:01 UTC 
hit the same issue when run virtio-win-1.9.17-1.el8_4 acceptance test.

version:
qemu-kvm-5.2.0-16.module+el8.4.0+11536+725e25d9.2.x86_64
kernel-4.18.0-305.el8.x86_64
seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch
virtio-win-1.9.17-1.el8_4.iso
Comment 29 leidwang@redhat.com 2021-07-13 10:00:24 UTC 
Hit the same issue when run virtio-win-1.9.17-2.el8_4 acceptance test.

Version:
kernel-4.18.0-305.el8.x86_64
qemu-kvm-5.2.0-16.module+el8.4.0+11721+c8bbc1be.3.x86_64
seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch
virtio-win-1.9.17-2.el8_4.iso
Comment 30 leidwang@redhat.com 2021-07-15 10:09:03 UTC 
Hit the same issue when run virtio-win-1.9.17-3.el8_4 acceptance test.

Version:
kernel-4.18.0-305.el8.x86_64
qemu-kvm-5.2.0-16.module+el8.4.0+11721+c8bbc1be.3.x86_64
seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch
virtio-win-1.9.17-3.el8_4.iso
Comment 31 dehanmeng 2021-08-06 03:59:04 UTC 
Hi the same issue when run virtio-win-1.9.17-4.el8_4 acceptance test.

Version:
qemu-kvm-5.2.0-16.module+el8.4.0+11923+e8b883e4.4.x86_64
kernel-modules-4.18.0-305.el8.x86_64
seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch
virtio-win-1.9.17-4.el8_4

1.  140.140-Host_RHEL.m8.u4.product_av.qcow2.virtio_blk.up.virtio_net.Guest.Win2012.x86_64.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair.q35
2.  145-Host_RHEL.m8.u4.product_av.qcow2.virtio_blk.up.virtio_net.Guest.Win2016.x86_64.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair.q35
3.  209-Host_RHEL.m8.u4.product_av.qcow2.virtio_scsi.up.virtio_net.Guest.Win2019.x86_64.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair.q35
4.  214-Host_RHEL.m8.u4.product_av.qcow2.virtio_scsi.up.virtio_net.Guest.Win8.i386.1.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair.q35
5.  219-Host_RHEL.m8.u4.product_av.qcow2.virtio_scsi.up.virtio_net.Guest.Win8.x86_64.1.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair.q35
6.  209-Host_RHEL.m8.u4.product_av.qcow2.virtio_blk.up.virtio_net.Guest.Win10.i386.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair.q35
7.  214-Host_RHEL.m8.u4.product_av.qcow2.virtio_blk.up.virtio_net.Guest.Win10.x86_64.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair.q35
8.  219-Host_RHEL.m8.u4.product_av.qcow2.virtio_blk.up.virtio_net.Guest.Win2012.x86_64.r2.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair.q35
Comment 33 ChenNana 2021-08-25 03:11:06 UTC 
hit the same issue when run virtio-win-1.9.15-4.el9 acceptance testing.

version:
kernel-5.14.0-0.rc4.35.el9.x86_64
qemu-kvm-6.0.0-10.el9.x86_64
virtio-win-1.9.15-4.el9
seabios-bin-1.14.0-6.el9.noarch
Comment 34 ChenNana 2021-09-08 06:02:58 UTC 
hit the same issue when run virtio-win-1.9.18-2.el8 acceptance testing 

version:
kernel-4.18.0-338.el8.x86_64
qemu-kvm-6.0.0-29.module+el8.5.0+12386+43574bac.x86_64
seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch
virtio-win-1.9.18-2.el8
Comment 35 ChenNana 2021-09-14 08:26:24 UTC 
hit the same issue when run virtio-win-1.9.19-1.el8 acceptance testing 

version:
kernel-4.18.0-339.el8.x86_64
qemu-kvm-6.0.0-29.module+el8.5.0+12386+43574bac.x86_64
seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch
virtio-win-1.9.19-1.el8
Comment 36 ChenNana 2021-10-12 05:53:14 UTC 
hit the same issue when run virtio-win-1.9.19-4.el9 acceptance test

version:
kernel-5.14.0-5.el9.x86_64
qemu-kvm-6.0.0-13.el9_b.5.x86_64
seabios-bin-1.14.0-6.el9.noarch
virtio-win-1.9.19-4.el9

1.Win2012.x86_64.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair  
2.Win2016.x86_64.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair 
3.Win2019.x86_64.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair 
4.Win8.i386.1.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair  
5.Win8.x86_64.1.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair
Comment 37 ChenNana 2021-10-19 02:19:58 UTC 
hit the same issue when run virtio-win-1.9.19-5.el9 acceptance testing 

version:
kernel-5.14.0-6.el9.x86_64
qemu-kvm-6.0.0-13.el9_b.5.x86_64
seabios-bin-1.14.0-6.el9.noarch
virtio-win-1.9.19-5.el9
Comment 38 xiagao 2021-10-25 02:24:15 UTC 
Hi Vadim,
As the ITR is set, could you set DTM, so qe can set ITM accordingly.

Thanks.
Xiaoling
Comment 39 Vadim Rozenfeld 2021-11-01 01:40:36 UTC 
(In reply to xiagao from comment #38)
> Hi Vadim,
> As the ITR is set, could you set DTM, so qe can set ITM accordingly.
> 
> Thanks.
> Xiaoling

Moved to 25.
Best,
Vadim.
Comment 40 xiagao 2021-11-04 01:45:45 UTC 
(In reply to Vadim Rozenfeld from comment #39)
> (In reply to xiagao from comment #38)
> > Hi Vadim,
> > As the ITR is set, could you set DTM, so qe can set ITM accordingly.
> > 
> > Thanks.
> > Xiaoling
> 
> Moved to 25.
> Best,
> Vadim.

Hello Vadim,
On RHEL8.6.0 Code freeze time is 2022-02-28 which DTM is 26, and you set DTM to 25, it's risky for QE to verify within 1 week.
So could you move the date a little bit forward,such as 23.

Thanks,
Xiaoling
Comment 41 ChenNana 2021-12-16 10:26:34 UTC 
hit the same issue when run virtio-win-1.9.20-1.el8_4 acceptance testing 

kernel-4.18.0-305.el8.x86_64
qemu-kvm-5.2.0-16.module+el8.4.0+13460+2e130eec.13.x86_64
seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch
virtio-win-1.9.20-1.el8_4
Comment 55 RHEL Program Management 2023-02-24 07:27:41 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Comment 58 xiagao 2023-06-19 01:20:11 UTC 
hello Vadim, the DTM expired, could you pls re-set them? Thanks.
Comment 59 Vadim Rozenfeld 2023-06-19 02:10:25 UTC 
(In reply to xiagao from comment #58)
> hello Vadim, the DTM expired, could you pls re-set them? Thanks.

updated.
All the best,
Vadim.
Comment 61 xiagao 2023-07-28 08:38:22 UTC 
Hi Vadim, could you help reset the 'Current Deadline:'? Thank you.
Comment 63 Vadim Rozenfeld 2023-08-13 05:41:13 UTC 
https://github.com/virtio-win/virtio-win-guest-tools-installer/pull/51
Comment 64 xiagao 2023-08-21 04:05:41 UTC 
Hi Vadim, Would you prefer to defer this repair bug to RHEL.9.3.z?
Comment 65 Vadim Rozenfeld 2023-08-21 04:56:56 UTC 
(In reply to xiagao from comment #64)
> Hi Vadim, Would you prefer to defer this repair bug to RHEL.9.3.z?

We can postpone it to 9.3.z in general since repair from the bundle doesn't work.
But if msi repair repair works I would like to release this feature in 9.3.0 and 
fix the bundle in 9.3.z

Best,
Vadim.
Comment 66 xiagao 2023-08-21 05:01:37 UTC 
(In reply to Vadim Rozenfeld from comment #65)
> (In reply to xiagao from comment #64)
> > Hi Vadim, Would you prefer to defer this repair bug to RHEL.9.3.z?
> 
> We can postpone it to 9.3.z in general since repair from the bundle doesn't
> work.
> But if msi repair repair works I would like to release this feature in 9.3.0
> and 
> fix the bundle in 9.3.z
> 
> Best,
> Vadim.

Thanks Vadim.
Then I will set this bug to verified. And open another one in Jira to track the bundle doesn't work issue.
Comment 73 errata-xmlrpc 2023-11-07 08:29:32 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 (virtio-win 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-2023:6388
Note You need to log in before you can comment on or make changes to this bug.