Bug 1782636
| Summary: | virtio-win iso's volume label is virtio-win-1.9.1 which is not correct | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | xiagao | ||||||||
| Component: | virtio-win | Assignee: | Vadim Rozenfeld <vrozenfe> | ||||||||
| virtio-win sub component: | distribution | QA Contact: | xiagao | ||||||||
| Status: | CLOSED ERRATA | Docs Contact: | |||||||||
| Severity: | unspecified | ||||||||||
| Priority: | unspecified | CC: | ailan, crobinso, ddepaula, jen, kanderso, lijin, lmiksik, mxie, rjones, tyan, tzheng, vrozenfe, ymankad, zili | ||||||||
| Version: | 8.1 | Flags: | pm-rhel:
mirror+
|
||||||||
| Target Milestone: | rc | ||||||||||
| Target Release: | 8.0 | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2020-04-28 16:05:15 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: |
|
||||||||||
For the record: I've read somewhere that the labels in some filesystems are limited to 11 chars. This is not the case here (as it's showing around 15 chars). I checked the data in Linux and it shows 'virtio-win-1.9.10' as volume label. In a linux guest it also shows 'virtio-win-1.9.10' as CDROM, so the problem isn't the package or the iso. I believe this can be one of those two: 1 - This is an emulation problem (eg: a bug in qemu). 2 - This is a test problem (eg: the label is correct, but the window is small and got cut off) Xiagao: Can you try to check the label in the filesystem manager? Going into properties or something like that. In my old days of windows I remember using a tool like a file disk manager. We can check if the information is wrong there. I know the screenshot also shows the information in a terminal, but I'm not sure how much can we trust it. I just want to be sure that this is an actual bug before moving this to a developer. Created attachment 1644611 [details]
disk management
(In reply to Danilo Cesar de Paula from comment #1) > For the record: I've read somewhere that the labels in some filesystems are > limited to 11 chars. > This is not the case here (as it's showing around 15 chars). > > I checked the data in Linux and it shows 'virtio-win-1.9.10' as volume label. > In a linux guest it also shows 'virtio-win-1.9.10' as CDROM, so the problem > isn't the package or the iso. > > I believe this can be one of those two: > 1 - This is an emulation problem (eg: a bug in qemu). > 2 - This is a test problem (eg: the label is correct, but the window is > small and got cut off) I don't think it's the window's problem, if changing the view by list, it's still 1.9.1 > > Xiagao: Can you try to check the label in the filesystem manager? Going into > properties or something like that. In my old days of windows I remember > using a tool like a file disk manager. We can check if the information is > wrong there. Do you mean in the disk management, I created a screenshot in attachment. It's still 1.9.1 and no content got cut off. > I know the screenshot also shows the information in a terminal, but I'm not > sure how much can we trust it. I just want to be sure that this is an actual > bug before moving this to a developer. Since this is not a distribution problem, I will reassign to Amnon so he can evaluate an developer to investigate this further. Disabling Joliet (removing "-J" flag from
/usr/bin/mkisofs \
-m 'virtio-win*.vfd' \
-m vfddrivers \
-m %{qemu_ga_win_build} \
-o %{name}-%{version}.iso \
-r -J \
-input-charset iso8859-1 \
-V "%{name}-%{version}" .
in virtio-win.spec file ) seems to be fixing this problem.
Danilo, can you give it a try and see how it works?
Best,
Vadim.
Just for the record. Looks as Microsoft doesn't use Joliet either. [vrozenfe@huan tmp]$ isoinfo -d -i /images/isos/18362.448.191016-1855.19H1_RELEASE_SVC_PROD3_CLIENTMULTICOMBINED_UUP_A64FRE_EN-US.ISO CD-ROM is in ISO 9660 format System id: Volume id: CCSA_A64FRE_EN-US_DV5 Volume set id: CCSA_A64FRE_EN-US_DV5 Publisher id: MICROSOFT CORPORATION Data preparer id: MICROSOFT CORPORATION, ONE MICROSOFT WAY, REDMOND WA 98052, (425) 882-8080 Application id: OSCDIMG 2.56 (01/01/2005 TM) Copyright File id: Abstract File id: Bibliographic File id: Volume set size is: 1 Volume set sequence number is: 1 Logical block size is: 2048 Volume size is: 2631710 El Torito VD version 1 found, boot catalog is in sector 22 NO Joliet present <------------------------------------------- NO JOLIET !!!! NO Rock Ridge present Two thoughts: Disabling joliet seems to be a workaround for a bug we don't know where it is. The main feature of using joliet is to allow bigger filenames (afaik, I'm no windows expert). But we don't depend on it. It seems fine from my point of view, but I would like to see someone else input. @Cole, can you see any problem in doing this? I don't know enough to say whether it's okay to drop -J or not. My initial thought it is we couldn't do it without some testing: there's lots of projects that are consuming the file layout of the iso programmatically, and I don't know how -J may affect their usage or now. Can we make a new iso, without Joliet turned on, and let QE to do some preliminary testing? From my side, I'm going to try building an iso with oscdimg.exe and check if enabling Joliet has the same effect when using MS tools. Will the filenames be different for a Linux consumer? I see we've
still got the -r ("rational Rock Ridge") flag, so I suppose not.
Is there a new ISO image which I can ask Tingting to test?
Created attachment 1663427 [details] iso name in guest of draft iso It works with iso in comment 23. (In reply to xiagao from comment #24) > Created attachment 1663427 [details] > iso name in guest of draft iso > > It works with iso in comment 23. Do we have any formal iso evaluation procedure? Because not only Joliet was dropped in this case. I also changed iso level to 4 to keep the same letter cases as in the original iso. Best, Vadim. (In reply to Vadim Rozenfeld from comment #25) > (In reply to xiagao from comment #24) > > Created attachment 1663427 [details] > > iso name in guest of draft iso > > > > It works with iso in comment 23. > > Do we have any formal iso evaluation procedure? > Because not only Joliet was dropped in this case. > I also changed iso level to 4 to keep the same > letter cases as in the original iso. > > Best, > Vadim. @lijin I don't know if we have such a procedure, could you help to check? (In reply to Vadim Rozenfeld from comment #25) > (In reply to xiagao from comment #24) > > Created attachment 1663427 [details] > > iso name in guest of draft iso > > > > It works with iso in comment 23. > > Do we have any formal iso evaluation procedure? > Because not only Joliet was dropped in this case. > I also changed iso level to 4 to keep the same > letter cases as in the original iso. As far as I know, KVM QE does not have a formal procedure for that. I check two commands that we used in our automation scripts: 1. mkisofs -o %s -max-iso9660-filenames -relaxed-filenames -D --input-charset iso8859-1 %s % (self.path, self.mount) 2. mkisofs -o $ISO_CREATE_ROOT_PATH/$VIRTIO_WIN_ISO_NAME -input-charset iso8859-1 -J -R -V "Virtio-Win" $VIR_WIN_TGT_ISO_PATH (In reply to Vadim Rozenfeld from comment #25) > (In reply to xiagao from comment #24) > > Created attachment 1663427 [details] > > iso name in guest of draft iso > > > > It works with iso in comment 23. > > Do we have any formal iso evaluation procedure? Yes, the QE team test virt-v2v with the virtio-win ISO (from brew normally). I downloaded the ISO you provided, and did a couple of quick tests. Firstly I compared the filenames in virtio-win-1.9.10-3.el8.noarch with the filenames in your ISO (using virt-ls). The filenames are identical but there are some odd differences in apparent file sizes, eg: -- 0555 2728 /Balloon/2k16/amd64/balloon.inf -- 0555 962560 /Balloon/2k16/amd64/balloon.pdb -- 0555 50376 /Balloon/2k16/amd64/balloon.sys -- 0555 168648 /Balloon/2k16/amd64/blnsvr.exe -- 0555 6352896 /Balloon/2k16/amd64/blnsvr.pdb +- 0555 0 /Balloon/2k16/amd64/balloon.inf +- 0555 0 /Balloon/2k16/amd64/balloon.pdb +- 0555 0 /Balloon/2k16/amd64/balloon.sys +- 0555 0 /Balloon/2k16/amd64/blnsvr.exe +- 0555 0 /Balloon/2k16/amd64/blnsvr.pdb These seem to be real problems. Could there be a problem with the way that you created the ISO? For my second test I did a v2v conversion of a Windows guest using virt-v2v 1.40.2rhel=8,release=20.module+el8.2.0+5433+9e1420c8,libvirt and your ISO. The conversion actually worked, which is sort of expected (virt-v2v doesn't really care about what's in the files or if they are empty, since it only copies them into the guest image and modifies the Registry to pick them up at first boot). I suspect if I had a Windows guest that I could boot then it would have failed at that point, assuming those files really are empty. (In reply to Richard W.M. Jones from comment #28) > (In reply to Vadim Rozenfeld from comment #25) > > (In reply to xiagao from comment #24) > > > Created attachment 1663427 [details] > > > iso name in guest of draft iso > > > > > > It works with iso in comment 23. > > > > Do we have any formal iso evaluation procedure? > > Yes, the QE team test virt-v2v with the virtio-win ISO (from brew normally). > > I downloaded the ISO you provided, and did a couple of quick tests. Firstly > I compared the filenames in virtio-win-1.9.10-3.el8.noarch with the filenames > in your ISO (using virt-ls). The filenames are identical but there are some > odd differences in apparent file sizes, eg: > > -- 0555 2728 /Balloon/2k16/amd64/balloon.inf > -- 0555 962560 /Balloon/2k16/amd64/balloon.pdb > -- 0555 50376 /Balloon/2k16/amd64/balloon.sys > -- 0555 168648 /Balloon/2k16/amd64/blnsvr.exe > -- 0555 6352896 /Balloon/2k16/amd64/blnsvr.pdb > +- 0555 0 /Balloon/2k16/amd64/balloon.inf > +- 0555 0 /Balloon/2k16/amd64/balloon.pdb > +- 0555 0 /Balloon/2k16/amd64/balloon.sys > +- 0555 0 /Balloon/2k16/amd64/blnsvr.exe > +- 0555 0 /Balloon/2k16/amd64/blnsvr.pdb > > These seem to be real problems. Could there be a problem with the way > that you created the ISO? I think I know where the problem comes from. Will try to prepare a new iso image shortly. > > For my second test I did a v2v conversion of a Windows guest using > virt-v2v 1.40.2rhel=8,release=20.module+el8.2.0+5433+9e1420c8,libvirt > and your ISO. The conversion actually worked, which is sort of > expected (virt-v2v doesn't really care about what's in the files or > if they are empty, since it only copies them into the guest image > and modifies the Registry to pick them up at first boot). I suspect > if I had a Windows guest that I could boot then it would have failed > at that point, assuming those files really are empty. This one should be better http://people.redhat.com/vrozenfe/virtio-win-1.9.10.zip I tried to check the original and this new isos with diff -qr /mnt/iso/ /mnt/iso1/ where /home/share/bugs/1782636/usr/share/virtio-win/virtio-win-1.9.10.iso on /mnt/iso type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048) /home/share/bugs/1782636/usr/share/virtio-win-1.9.10.iso on /mnt/iso1 type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048) They seem to be equal, but I can be missing something. (In reply to Vadim Rozenfeld from comment #30) > This one should be better > http://people.redhat.com/vrozenfe/virtio-win-1.9.10.zip > > I tried to check the original and this new isos with > diff -qr /mnt/iso/ /mnt/iso1/ where > /home/share/bugs/1782636/usr/share/virtio-win/virtio-win-1.9.10.iso on > /mnt/iso type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048) > /home/share/bugs/1782636/usr/share/virtio-win-1.9.10.iso on /mnt/iso1 type > iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048) > > They seem to be equal, but I can be missing something. Is this iso suitable for testing from virt-v2v's side,if so QE will test it using virt-v2v. (In reply to tingting zheng from comment #31) > (In reply to Vadim Rozenfeld from comment #30) > > This one should be better > > http://people.redhat.com/vrozenfe/virtio-win-1.9.10.zip > > > > I tried to check the original and this new isos with > > diff -qr /mnt/iso/ /mnt/iso1/ where > > /home/share/bugs/1782636/usr/share/virtio-win/virtio-win-1.9.10.iso on > > /mnt/iso type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048) > > /home/share/bugs/1782636/usr/share/virtio-win-1.9.10.iso on /mnt/iso1 type > > iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048) > > > > They seem to be equal, but I can be missing something. > > Is this iso suitable for testing from virt-v2v's side,if so QE will test it > using virt-v2v. It should be on a par with the original iso from virtio-win-1.9.10-3.el8 package. So, in my understanding, it should be fine to try it for v2v. (In reply to Vadim Rozenfeld from comment #30) > This one should be better > http://people.redhat.com/vrozenfe/virtio-win-1.9.10.zip > > I tried to check the original and this new isos with > diff -qr /mnt/iso/ /mnt/iso1/ where > /home/share/bugs/1782636/usr/share/virtio-win/virtio-win-1.9.10.iso on > /mnt/iso type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048) > /home/share/bugs/1782636/usr/share/virtio-win-1.9.10.iso on /mnt/iso1 type > iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048) > > They seem to be equal, but I can be missing something. I test win2012 guest, it works and name shows virtio-win-1.9.10 . (In reply to Vadim Rozenfeld from comment #32) > (In reply to tingting zheng from comment #31) > > (In reply to Vadim Rozenfeld from comment #30) > > > This one should be better > > > http://people.redhat.com/vrozenfe/virtio-win-1.9.10.zip > > > > > > I tried to check the original and this new isos with > > > diff -qr /mnt/iso/ /mnt/iso1/ where > > > /home/share/bugs/1782636/usr/share/virtio-win/virtio-win-1.9.10.iso on > > > /mnt/iso type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048) > > > /home/share/bugs/1782636/usr/share/virtio-win-1.9.10.iso on /mnt/iso1 type > > > iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048) > > > > > > They seem to be equal, but I can be missing something. > > > > Is this iso suitable for testing from virt-v2v's side,if so QE will test it > > using virt-v2v. > > It should be on a par with the original iso from virtio-win-1.9.10-3.el8 > package. > So, in my understanding, it should be fine to try it for v2v. Got it,QE will test it and add test result later. I can reproduce bug with virtio-win-1.9.10-3.el8.noarch in win2019, win2016, win10 and win2012r2 guest, also can reproduce the bug in win2012 guest although xiagao said virtio-win version shows correct in win2012 guest in comment33, the reproduced steps are same with comment0. As rjones said in comment28, this bug won't affect v2v installs drivers from virtio-win for windows guest, so can't help to debug the bug from v2v side. (In reply to mxie from comment #35) > I can reproduce bug with virtio-win-1.9.10-3.el8.noarch in win2019, win2016, > win10 and win2012r2 guest, also can reproduce the bug in win2012 guest > although xiagao said virtio-win version shows correct in win2012 guest in > comment33, the reproduced steps are same with comment0. As rjones said in > comment28, this bug won't affect v2v installs drivers from virtio-win for > windows guest, so can't help to debug the bug from v2v side. Do you still have the same problem as Richard mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1782636#c28 even with the latest iso http://people.redhat.com/vrozenfe/virtio-win-1.9.10.zip I checked them, the original iso and the new one with "tree -du -h" and the both look absolutely the same in terms of layout and size while the latest on has no Joliet, which means that Windows can read long volume names [vrozenfe@panda iso1]$ isoinfo -d -i /home/share/bugs/1782636/usr/share/virtio-win/virtio-win-1.9.10.iso CD-ROM is in ISO 9660 format System id: LINUX Volume id: virtio-win-1.9.10 Volume set id: Publisher id: Data preparer id: Application id: GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM Copyright File id: Abstract File id: Bibliographic File id: Volume set size is: 1 Volume set sequence number is: 1 Logical block size is: 2048 Volume size is: 131255 Joliet with UCS level 3 found Rock Ridge signatures version 1 found [vrozenfe@panda iso1]$ isoinfo -d -i /home/share/bugs/1782636/usr/share/virtio-win-1.9.10.iso CD-ROM is in ISO 9660 format System id: LINUX Volume id: virtio-win-1.9.10 Volume set id: Publisher id: Data preparer id: Application id: GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM Copyright File id: Abstract File id: Bibliographic File id: Volume set size is: 1 Volume set sequence number is: 1 Logical block size is: 2048 Volume size is: 280207 CD-ROM uses ISO 9660:1999 relaxed format NO Joliet present Rock Ridge signatures version 1 found (In reply to Vadim Rozenfeld from comment #37) > (In reply to mxie from comment #35) > > I can reproduce bug with virtio-win-1.9.10-3.el8.noarch in win2019, win2016, > > win10 and win2012r2 guest, also can reproduce the bug in win2012 guest > > although xiagao said virtio-win version shows correct in win2012 guest in > > comment33, the reproduced steps are same with comment0. As rjones said in > > comment28, this bug won't affect v2v installs drivers from virtio-win for > > windows guest, so can't help to debug the bug from v2v side. > > Do you still have the same problem as Richard mentioned in > https://bugzilla.redhat.com/show_bug.cgi?id=1782636#c28 Hi Vadim I got same result with Richard if use virt-ls to compare the files between the virtio-win iso file you built in commnet23 and virtio-win iso file which is installed from brewweb, below is the steps to reproduce and detailed difference pls refer to http://pastebin.test.redhat.com/838671 # virt-ls -lR -d rhel8.2-baremetal /home/virtio-win > virtio-win-vadim-new.log # virt-ls -lR -d rhel8.2-baremetal /home/virtio-win > virtio-win-brew-new.log # diff virtio-win-brew-new.log virtio-win-vadim-new.log 1c1 < d 0755 4096 /home/virtio-win --- > d 0755 94 /home/virtio-win 5,11c5,11 < - 0555 1795952 /home/virtio-win/Balloon/2k12/amd64/WdfCoInstaller01011.dll < - 0444 9433 /home/virtio-win/Balloon/2k12/amd64/balloon.cat < - 0555 2894 /home/virtio-win/Balloon/2k12/amd64/balloon.inf < - 0555 1167360 /home/virtio-win/Balloon/2k12/amd64/balloon.pdb < - 0555 49864 /home/virtio-win/Balloon/2k12/amd64/balloon.sys < - 0555 168136 /home/virtio-win/Balloon/2k12/amd64/blnsvr.exe < - 0555 6320128 /home/virtio-win/Balloon/2k12/amd64/blnsvr.pdb --- > - 0555 0 /home/virtio-win/Balloon/2k12/amd64/WdfCoInstaller01011.dll > - 0444 0 /home/virtio-win/Balloon/2k12/amd64/balloon.cat > - 0555 0 /home/virtio-win/Balloon/2k12/amd64/balloon.inf > - 0555 0 /home/virtio-win/Balloon/2k12/amd64/balloon.pdb > - 0555 0 /home/virtio-win/Balloon/2k12/amd64/balloon.sys > - 0555 0 /home/virtio-win/Balloon/2k12/amd64/blnsvr.exe > - 0555 0 /home/virtio-win/Balloon/2k12/amd64/blnsvr.pdb 14,20c14,20 ..... But I slightly doubt above result because I didn't see any difference when use command 'ls -l' to compare their files, for example, compare the files in Balloon/2k12/amd64 # ls -l virtio-win-vadim/Balloon/2k12/amd64 total 9304 -r--r--r--. 1 root root 9433 Feb 23 23:49 balloon.cat -r-xr-xr-x. 1 root root 2894 Feb 23 23:49 balloon.inf -r-xr-xr-x. 1 root root 1167360 Feb 23 23:49 balloon.pdb -r-xr-xr-x. 1 root root 49864 Feb 23 23:49 balloon.sys -r-xr-xr-x. 1 root root 168136 Feb 23 23:49 blnsvr.exe -r-xr-xr-x. 1 root root 6320128 Feb 23 23:49 blnsvr.pdb -r-xr-xr-x. 1 root root 1795952 Feb 23 23:49 WdfCoInstaller01011.dll [root@bootp-73-225-155 home]# ls -l virtio-win-brew/Balloon/2k12/amd64 total 9304 -r--r--r--. 1 root root 9433 Feb 23 23:55 balloon.cat -r-xr-xr-x. 1 root root 2894 Feb 23 23:55 balloon.inf -r-xr-xr-x. 1 root root 1167360 Feb 23 23:55 balloon.pdb -r-xr-xr-x. 1 root root 49864 Feb 23 23:55 balloon.sys -r-xr-xr-x. 1 root root 168136 Feb 23 23:55 blnsvr.exe -r-xr-xr-x. 1 root root 6320128 Feb 23 23:55 blnsvr.pdb -r-xr-xr-x. 1 root root 1795952 Feb 23 23:55 WdfCoInstaller01011.dll Besides, I use the virtio-win iso which is built in commnet23 as windows guest driver source during v2v conversion, v2v can installs drivers from the iso you built successfully. # export VIRTIO_WIN=/home/virtio-win-1.9.10.iso # virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA esx6.7-win2019-x86_64 -on esx6.7-win2019-x86_64-vadim --password-file /home/passwd Overall, the volume label of virtio-win iso file you built in comment23 shows correct in windows guest and v2v can install drivers from this iso successfully. New ISO seems to work fine for me: $ virt-ls -a virtio-win-1.9.10.iso -m /dev/sda -lR /Balloon/2k16/amd64/ d 0555 2048 /Balloon/2k16/amd64 - 0444 10411 /Balloon/2k16/amd64/balloon.cat - 0555 2728 /Balloon/2k16/amd64/balloon.inf - 0555 962560 /Balloon/2k16/amd64/balloon.pdb - 0555 50376 /Balloon/2k16/amd64/balloon.sys - 0555 168648 /Balloon/2k16/amd64/blnsvr.exe - 0555 6352896 /Balloon/2k16/amd64/blnsvr.pdb We can include this change in the regular virtio-win package that is going to be built next week (I assume). Most of the drivers are signed and ready. I believe we're only missing netkvm now. Meanwhile, is there a patch posted somewhere Vadim? (In reply to Danilo Cesar de Paula from comment #45) > We can include this change in the regular virtio-win package that is going > to be built next week (I assume). > Most of the drivers are signed and ready. I believe we're only missing > netkvm now. > > Meanwhile, is there a patch posted somewhere Vadim? Unfortunatly, I was not using the standard iso building procedure, but re-created the iso with the following command instead: genisoimage -V virtio-win-1.9.10 -r -input-charset iso8859-1 -iso-level 4 -o ../virtio-win-1.9.10.iso ./virtio-win as you can see, comparing with the scrip, which has the following part /usr/bin/mkisofs \ -m 'virtio-win*.vfd' \ -m vfddrivers \ -m %{qemu_ga_win_build} \ -o %{name}-%{version}.iso \ -r -J \ -input-charset iso8859-1 \ -V "%{name}-%{version}" . I just dropped off Joliet (-J) and added "-iso-level 4" parameter. IIUC the above changes should work with mkisofs as well. Vadim. Verify this bug with virtio-win-1.9.11-1.el8. virtio-win volume label is: virtio-win-1.9.11 @tingting Could you verify from v2v side? Thanks, Xiaoling (In reply to xiagao from comment #51) > Verify this bug with virtio-win-1.9.11-1.el8. > virtio-win volume label is: virtio-win-1.9.11 > > @tingting > Could you verify from v2v side? Sure, test result will be added later. > > Thanks, > Xiaoling The result is passed when test virtio-win-1.9.11-1.el8.noarch from v2v side, pls refer to below auto testing, all windows cases are passed. https://libvirt-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/v2v/view/RHEL-8.2/job/v2v-RHEL-8.2-runtest-x86_64-acceptance-ovirt/31/testReport/rhel/convert_vm_to_ovirt/ Change status to verified according to comment#51 and #53 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/RHEA-2020:1757 |
Created attachment 1644254 [details] virtio-win cdrom info on guest. Description of problem: as $summary Version-Release number of selected component (if applicable): virtio-win-1.9.10-0.el8.noarch How reproducible: 100% Steps to Reproduce: 1.install latest virtio-win-1.9.10-0.el8.noarch in rhel8 host 2.check iso file # rpm -ql virtio-win-1.9.10-0.el8.noarch /usr/share/virtio-win/virtio-win-1.9.10.iso /usr/share/virtio-win/virtio-win.iso ...... 3.boot win2019 guest with virtio-win-1.9.10.iso 4.check virtio-win volume Actual results: virtio-win volume label is: virtio-win-1.9.1 Expected results: virtio-win-1.9.10 Additional info: