F8test2 iso mounted and exported via nfs, e.g:
nfs:192.168.0.1:/mnt (side note - virt-install / virt-manager nfs URI syntax is wrong - should really be nfs://192.168.0.1:/mnt)
Snooping the NFS traffic shows the install successfully mounting the distro dvd iso, and failing to find a /Fedora directory there. Sure 'nuff, that's a difference between F8test1 and earlier releases of fedora and F8test2.
Mike
On Wed, 19 Sep 2007 09:47:06 -0700 Mike Carney mc-al34luc@sbcglobal.net wrote:
F8test2 iso mounted and exported via nfs, e.g:
nfs:192.168.0.1:/mnt (side note - virt-install / virt-manager nfs URI syntax is wrong - should really be nfs://192.168.0.1:/mnt)
Snooping the NFS traffic shows the install successfully mounting the distro dvd iso, and failing to find a /Fedora directory there. Sure 'nuff, that's a difference between F8test1 and earlier releases of fedora and F8test2.
You're stating two different (and incompatible things) here. First that you've loopmounted the iso and exported the contents, second that your install /also/ mounted the iso, which it couldn't have unless you pointed to a nfs directory which just had the .iso file sitting there.
Which is it?
Jesse Keating wrote:
On Wed, 19 Sep 2007 09:47:06 -0700 Mike Carney mc-al34luc@sbcglobal.net wrote:
F8test2 iso mounted and exported via nfs, e.g:
nfs:192.168.0.1:/mnt (side note - virt-install / virt-manager nfs URI syntax is wrong - should really be nfs://192.168.0.1:/mnt)
Snooping the NFS traffic shows the install successfully mounting the distro dvd iso, and failing to find a /Fedora directory there. Sure 'nuff, that's a difference between F8test1 and earlier releases of fedora and F8test2.
You're stating two different (and incompatible things) here. First that you've loopmounted the iso and exported the contents, second that your install /also/ mounted the iso, which it couldn't have unless you pointed to a nfs directory which just had the .iso file sitting there.
Which is it?
No I'm not. Seems clear and concise to me. But I'll restate it for you. The iso is loop mounted on a nfs server, which virt-install/virt-manager is told about through using nfs:192.168.0.1:/mnt as an argument. Previous versions of the distro had a Fedora directory at the root of the dvd iso. f8test2 does not, therefore, the install fails.
On Wed, 19 Sep 2007 11:47:07 -0700 Mike Carney mc-al34luc@sbcglobal.net wrote:
No I'm not. Seems clear and concise to me. But I'll restate it for you. The iso is loop mounted on a nfs server, which virt-install/virt-manager is told about through using nfs:192.168.0.1:/mnt as an argument. Previous versions of the distro had a Fedora directory at the root of the dvd iso. f8test2 does not, therefore, the install fails.
Yes, but you said that sniffing nfs showed you the installer mounting the iso? As in loopback mounting the iso, or that it mounted the nfs directory where the iso was pre-mounted?
This may be a regression due to making the package directory more generic (s/Fedora/Packages/), but loopback mounted NFS installs are not nearly tested as much as exploaded tree NFS, or unmounted isos in a NFS directory method. If you don't loopback mount the iso and instead just nfs share the directory that has the .iso file in it, does your install proceed?
Jesse Keating wrote:
On Wed, 19 Sep 2007 11:47:07 -0700 Mike Carney mc-al34luc@sbcglobal.net wrote:
No I'm not. Seems clear and concise to me. But I'll restate it for you. The iso is loop mounted on a nfs server, which virt-install/virt-manager is told about through using nfs:192.168.0.1:/mnt as an argument. Previous versions of the distro had a Fedora directory at the root of the dvd iso. f8test2 does not, therefore, the install fails.
Yes, but you said that sniffing nfs showed you the installer mounting the iso? As in loopback mounting the iso, or that it mounted the nfs directory where the iso was pre-mounted?
The iso is loopback mounted on the nfs server, and the loopback mount point is exported via nfs to the dom0 machine (separate machine). This setup has worked from FC5 thru F8test1, and just stopped working in F8test2.
This may be a regression due to making the package directory more generic (s/Fedora/Packages/), but loopback mounted NFS installs are not nearly tested as much as exploaded tree NFS, or unmounted isos in a NFS directory method. If you don't loopback mount the iso and instead just nfs share the directory that has the .iso file in it, does your install proceed?
No, it fails. The installer is still looking for a /Fedora directory:
Portmap V2 GETPORT Reply (Call In 174) Port:614$ MOUNT V3 NULL Call (Reply In 178)$ MOUNT V3 NULL Reply (Call In 177)$ MOUNT V3 MNT Call (Reply In 180) /local/Downloads$ MOUNT V3 MNT Reply (Call In 179)$ TCP 934 > nfs [SYN] Seq=0 Len=0 MSS=1460 TSV=5125310 TSER=0 WS=4$ TCP nfs > 934 [SYN, ACK] Seq=0 Ack=1 Win=185344 Len=0 MSS=1460 TSV=529338364 TSER=5125310 WS=5$ TCP 934 > nfs [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=5125310 TSER=529338364$ NFS V3 NULL Call (Reply In 186)$ TCP nfs > 934 [ACK] Seq=1 Ack=45 Win=5792 Len=0 TSV=529338364 TSER=5125310$ NFS V3 NULL Reply (Call In 184)$ TCP 934 > nfs [ACK] Seq=45 Ack=29 Win=5840 Len=0 TSV=5125310 TSER=529338364$ NFSACL V3 NULL Call (Reply In 189)$ NFSACL V3 NULL Reply (Call In 188)$ NFS V3 FSINFO Call (Reply In 191), FH:0x00ed11e7$ NFS V3 FSINFO Reply (Call In 190)$ NFS V3 GETATTR Call (Reply In 193), FH:0x00ed11e7$ NFS V3 GETATTR Reply (Call In 192) Directory mode:0777 uid:0 gid:3$ NFS V3 FSINFO Call (Reply In 195), FH:0x00ed11e7$ NFS V3 FSINFO Reply (Call In 194)$ NFS V3 GETATTR Call (Reply In 197), FH:0x00ed11e7$ NFS V3 GETATTR Reply (Call In 196) Directory mode:0777 uid:0 gid:3$ NFS V3 ACCESS Call (Reply In 201), FH:0x00ed11e7$ NFS V3 ACCESS Reply (Call In 200)$ NFS V3 LOOKUP Call (Reply In 203), DH:0x00ed11e7/Fedora$ NFS V3 LOOKUP Reply (Call In 202) Error:NFS3ERR_NOENT
On Wed, 19 Sep 2007 13:19:17 -0700 Mike Carney mc-al34luc@sbcglobal.net wrote:
No, it fails. The installer is still looking for a /Fedora directory:
Now that I don't believe, as I tested this method a /lot/ before sending out the isos. Can you give me anaconda logs for this?
Jesse Keating wrote:
On Wed, 19 Sep 2007 13:19:17 -0700 Mike Carney mc-al34luc@sbcglobal.net wrote:
No, it fails. The installer is still looking for a /Fedora directory:
Now that I don't believe, as I tested this method a /lot/ before sending out the isos. Can you give me anaconda logs for this?
If folks are going to use the virt* tools to install f8test2 guests, something has to change.
I don't know what you tested, but dom0's running 7.90 and earlier will not be able to install 7.91 guests because 7.91 renamed the Fedora directory to Packages in the iso.
From python-virtinst-0.200.0-3.fc7:
/usr/lib/python2.5/site-packages/virtinst/DistroManager.py: # Fedora distro check class FedoraImageStore(RedHatImageStore): def isValidStore(self, fetcher, progresscb): if fetcher.hasFile("Fedora", progresscb): logging.debug("Detected a Fedora distro") return True return False
If you're going to change the layout of distro in the iso, you're going to either need to make a symbolic link from /Fedora to /Packages in the iso, release new versions of python-virtinst for earlier versions of Fedora and RHEL so that they recognize the new layout, or some other scheme in python-virtinst to reliably identify the Fedora distro.
Changing line 213 of
/usr/lib/python2.5/site-packages/virtinst/DistroManager.py
from
if fetcher.hasFile("Fedora", progresscb):
to
if fetcher.hasFile("Packages", progresscb):
And rerunning virt-install or virt-manager for a F8test2 guest now lets the installer start up.
Do I need to submit a bug?
Mike
On Fri, 21 Sep 2007 07:54:08 -0700 Mike Carney mc-al34luc@sbcglobal.net wrote:
If folks are going to use the virt* tools to install f8test2 guests, something has to change.
I don't know what you tested, but dom0's running 7.90 and earlier will not be able to install 7.91 guests because 7.91 renamed the Fedora directory to Packages in the iso.
From python-virtinst-0.200.0-3.fc7:
/usr/lib/python2.5/site-packages/virtinst/DistroManager.py: # Fedora distro check class FedoraImageStore(RedHatImageStore): def isValidStore(self, fetcher, progresscb): if fetcher.hasFile("Fedora", progresscb): logging.debug("Detected a Fedora distro") return True return False
If you're going to change the layout of distro in the iso, you're going to either need to make a symbolic link from /Fedora to /Packages in the iso, release new versions of python-virtinst for earlier versions of Fedora and RHEL so that they recognize the new layout, or some other scheme in python-virtinst to reliably identify the Fedora distro.
Changing line 213 of
/usr/lib/python2.5/site-packages/virtinst/DistroManager.py
from
if fetcher.hasFile("Fedora", progresscb):
to
if fetcher.hasFile("Packages", progresscb):
And rerunning virt-install or virt-manager for a F8test2 guest now lets the installer start up.
Do I need to submit a bug?
Eew, yea, this is a bug. File it against virt-inst. It should find a better way to figure out if it's Fedora or not.
Jesse Keating wrote:
On Fri, 21 Sep 2007 07:54:08 -0700 Mike Carney mc-al34luc@sbcglobal.net wrote:
If folks are going to use the virt* tools to install f8test2 guests, something has to change.
I don't know what you tested, but dom0's running 7.90 and earlier will not be able to install 7.91 guests because 7.91 renamed the Fedora directory to Packages in the iso.
From python-virtinst-0.200.0-3.fc7:
/usr/lib/python2.5/site-packages/virtinst/DistroManager.py: # Fedora distro check class FedoraImageStore(RedHatImageStore): def isValidStore(self, fetcher, progresscb): if fetcher.hasFile("Fedora", progresscb): logging.debug("Detected a Fedora distro") return True return False
If you're going to change the layout of distro in the iso, you're going to either need to make a symbolic link from /Fedora to /Packages in the iso, release new versions of python-virtinst for earlier versions of Fedora and RHEL so that they recognize the new layout, or some other scheme in python-virtinst to reliably identify the Fedora distro.
Changing line 213 of
/usr/lib/python2.5/site-packages/virtinst/DistroManager.py
from
if fetcher.hasFile("Fedora", progresscb):
to
if fetcher.hasFile("Packages", progresscb):
And rerunning virt-install or virt-manager for a F8test2 guest now lets the installer start up.
Do I need to submit a bug?
Eew, yea, this is a bug. File it against virt-inst. It should find a better way to figure out if it's Fedora or not.
It's 301001.