Created attachment 436770 [details] logs under /tmp Description of problem: I added 'repo=nfsiso[:options]:<server>:/<path>' into boot command line to install packages from iso images. but it failed to retrieve the metadata Version-Release number of selected component (if applicable): anaconda 14.14 F14-alpha-tc2 How reproducible: 100% Steps to Reproduce: 1. Boot system with repo=nfsiso[:options]:<server>:/<path> 2. Proceed until repository step Expected results: it should be able to install packages from nfsiso directory.
Created attachment 436771 [details] The prompt screen
Does it work if you use nfs: instead of nfsiso: for the same style of installation?
(In reply to comment #2) > Does it work if you use nfs: instead of nfsiso: for the same style of > installation? It passed when using 'repo=nfs:<server>:/<path>/tree' but failed for pointing it to iso images directory.
There is a clause in the F14Beta criteria around ensuring that NFS installs work, but it is not specific to ISO-based NFS installs. Adding to F14Blocker per the following criteria [1]: "The installer must be able to use all supported local and remote package source options " [1] https://fedoraproject.org/wiki/Fedora_14_Final_Release_Criteria
When you hit this error, it looks like the directory holding the images is mounted, but none of the images themselves are mounted. Can you attach the output of the mount command to verify this?
Right, the images themselves were supposed to be mounted on /mnt/source like F13-ga does. F14-alpha-rc2: $mount rootfs on / type rootfs (rw,relatime) /proc on /proc type proc (rw,relatime) /dev on /dev type tmpfs (rw,seclabel,relatime) /dev/pts on /dev/pts type devpts (rw,seclabel,relatime,gid=5,mode=620,ptmxmode=000) /sys on /sys type sysfs (rw,seclabel,relatime) none on /tmp type tmpfs (rw,seclabel,relatime,size=256000k) /dev/sr0 on /mnt/stage2 type iso9660 (ro,relatime) /dev/loop0 on /mnt/runtime type squashfs (ro,relatime) /selinux on /selinux type selinuxfs (rw,relatime) /dev/mapper/VolGroup-lv_root on /mnt/sysimage type ext4 (rw,seclabel,relatime,barrier=1,data=ordered) /dev/sda1 on /mnt/sysimage/boot type ext4 (rw,seclabel,relatime,barrier=1,data=ordered) /dev on /mnt/sysimage/dev type tmpfs (rw,seclabel,relatime) /dev/devpts on /mnt/sysimage/dev/pts type devpts (rw,seclabel,relatime,gid=5,mode=620,ptmxmode=000) /dev/tmpfs on /mnt/sysimage/dev/shm type tmpfs (rw,seclabel,relatime) /dev/proc on /mnt/sysimage/proc type proc (rw,relatime) /dev/sysfs on /mnt/sysimage/sys type sysfs (rw,seclabel,relatime) nfs.englab.nay.redhat.com:/fedoratest/f14-alpha-rc2 on /mnt/isodir type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.66.78.201,mountvers=3,mountport=4003,mountproto=udp,addr=10.66.78.201) nfs.englab.nay.redhat.com:/fedoratest/f14-alpha-rc2 on /mnt/source type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.66.78.201,mountvers=3,mountport=4003,mountproto=udp,addr=10.66.78.201) Mount Output Differences between F14-alpha-rc2 and F13-ga: 18c18 < nfs.englab.nay.redhat.com:/fedoratest/f14-alpha-rc2 on /mnt/source type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.66.78.201,mountvers=3,mountport=4003,mountproto=udp,addr=10.66.78.201) --- > /dev/loop1 on /mnt/source type iso9660 (ro,relatime)
When I tested this case: https://fedoraproject.org/wiki/QA/TestCases/InstallSourceHardDrive the installer failed to retrieve the iso repo as well. Is it the same issue? The iso itself was not mounted as well.
Yes, I believe that issue has the same root cause. We were stomping on a struct in loader and always setting something that should only be set on URL installs.
*** Bug 627631 has been marked as a duplicate of this bug. ***
Reproduced in anaconda 14.17.1 of F14-beta-tc1
If I'm understanding correctly, this fix should be included in 14.17.1 (F-14-Beta-TC1) http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=1cfae1b5470609af96b629fb62c64c597354843f Setting back to ASSIGNED based on feedback from rhe. Apologies if I incorrectly assessed the version or git log.
My problem (Bug 627631) seems to be fixed in the latest f14 vmlinuz and initrd.img files dated 15/09/2010. It didn't work when I tried earlier in the week with the files dated 12/09/2010.
Tested with anaconda 14.17.4 of F14-beta, the installer still couldn't get repo info. And this time an error screen popped up saying "(16, device or resource busy)" as attached. Unlike before, the path provided at boot command was not mounted twice(see comment#6) but the iso itself was not mounted as well. Anaconda.log and mount info are attached.
Created attachment 449567 [details] Error screen of nfsiso repo using anaconda 14.17.4
Created attachment 449568 [details] anaconda.log
Created attachment 449569 [details] mount info
(In reply to comment #13) > Tested with anaconda 14.17.4 of F14-beta, the installer still couldn't get repo > info. And this time an error screen popped up saying "(16, device or resource > busy)" as attached. > > Unlike before, the path provided at boot command was not mounted twice(see > comment#6) but the iso itself was not mounted as well. Anaconda.log and mount > info are attached. I've also verified that this issue wouldn't happen if the nfs file directory only contain one iso. So this problem is possibly the same as Bug#627789
(In reply to comment #17) > (In reply to comment #13) > > Tested with anaconda 14.17.4 of F14-beta, the installer still couldn't get repo > > info. And this time an error screen popped up saying "(16, device or resource > > busy)" as attached. > > > > Unlike before, the path provided at boot command was not mounted twice(see > > comment#6) but the iso itself was not mounted as well. Anaconda.log and mount > > info are attached. > > I've also verified that this issue wouldn't happen if the nfs file directory > only contain one iso. So this problem is possibly the same as Bug#627789 Thanks for the investigation Hurry! I agree that the new problem you are seeing is bug#627789. If you've addressed that problem, and can no longer reproduce this issue, let's move this to VERIFIED. We can track the remaining issue of multiple ISO images in bug#627789.
(In reply to comment #18) > <skip> > Thanks for the investigation Hurry! I agree that the new problem you are > seeing is bug#627789. If you've addressed that problem, and can no longer > reproduce this issue, let's move this to VERIFIED. We can track the remaining > issue of multiple ISO images in bug#627789. Okay, move it to VERIFIED. Thanks, James.
this should be closed, we're well past 14.17-1 now.