Bug 702511

Please change to vt2 and attach all the /tmp/*log files to this bug (as individual files).

Created attachment 497391 [details]
Tar.gz file of all logs under /tmp

I am attaching all logs under /tmp.

Created attachment 497392 [details]
anaconda.log

Created attachment 497393 [details]
ifcfg.log

Created attachment 497394 [details]
program.log

Created attachment 497395 [details]
storage.log

Created attachment 497397 [details]
X.log

Attached logs as individual files as requested

Reporter,

can you please also attach /tmp/syslog and the exact error message you are seeing?

Thank you.

Ah, sorry I can see you already posted the error screenshot. Then just /tmp/syslog please.

Also,

I prepared this special updates image for you:
http://akozumpl.fedorapeople.org/bz702511.img

It should tell us more about how the cd-finding operation fails. Can you see some fails in /mnt/source from tty2, right after the error dialog?

Thank you again.

Created attachment 497862 [details]
sylog

Can you please provide instructions as how to use the bz702511.img. I initially thought this was a updated initrd.img. Turns out it is something different with following .
./ak.py
./libassuan.so.0
./anaconda
./pyanaconda
./ltmain.sh
./autogen.sh
./ui
./data
./utils
./libassuan.so.0.0.0
./scripts
./tests
I am not sure where to plug this in.

http://fedoraproject.org/wiki/Anaconda/Updates

Thanks for the link.

I renamed bz702511.img to updates.img and put it under /images. I rebuilt the ISO and tried the install, but same original problem.

I did a little digging and found out the function call "dev.format.mount()" called from _mountInstallCD(self) in pyanaconda/yuminstall.py fails and causes the message "Please insert Fedora disc to continue".

The workaround is to put an early return as shown below. This lets the install continue and finish sucessfully. 

/usr/lib64/python2.7/site-packages/pyanaconda/yuminstall.py in function def _mountInstallCD(self):
    def _mountInstallCD(self):
        if os.access("%s/.discinfo" % self.tree, os.R_OK):
            f = open("%s/.discinfo" % self.tree)
            self._timestamp = f.readline().strip()
            f.close()

        dev = self.anaconda.storage.devicetree.getDeviceByName(self.anaconda.mediaDevice)
        dev.format.mountpoint = self.tree

        return  <======RETURN HERE

        # See if there's any media mounted on self.tree before continuing.
        # This saves a useless eject and insert if the user has already put
        # the disc in the drive.
        if not self.anaconda.storage.fsset.mountpoints.has_key(self.tree):
            try:
                dev.format.mount() <======== This is reason of failure. This causes installer to keep showing Change Disc.

(In reply to comment #16)
> I did a little digging and found out the function call "dev.format.mount()"
> called from _mountInstallCD(self) in pyanaconda/yuminstall.py fails and causes
> the message "Please insert Fedora disc to continue".

Yes, we need to find out where exactly this fails. The workaround would break other cases unfortunately.

So please, use the new updates image:

http://akozumpl.fedorapeople.org/bz702511.img

(You can use it directly by appending updates=http://akozumpl.fedorapeople.org/bz702511.img to the syslinux prompt when your system boots, just press <tab> to get to see the prompt.)

Get to the point where you see the failure and attach all the log files to this bugzilla.

Also, please check if there are files in /mnt/source and attach the output of 'mount'.

Thank you and embrace for a few more rounds of this if we are to find and fix the error.

Created attachment 498809 [details]
05132011.anaconda.log

Created attachment 498810 [details]
05132011.ifcfg.log

Created attachment 498811 [details]
05132011.program.log

Created attachment 498812 [details]
05132011.storage.log

Created attachment 498813 [details]
05132011.syslog

Created attachment 498814 [details]
05132011.X.log

Sorry it took me a while to work on this, I followed your instructions and saw the same failure. I have attached the log files as requested.

Here is the additional information you requested.

The "mount" output
rootfs on / type rootfs (rw,relatime)
/proc on /proc type proc (rw,relatime)
/dev on /dev type tmpfs (rw,relatime,seclabel)
/dev/pts on /dev/pts type devpts (rw,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
/sys on /sys type sysfs (rw,relatime,seclabel)
none on /tmp type tmpfs (rw,relatime,seclabel,size=256000k)
/dev/sr1 on /mnt/source type iso9660 (ro,relatime)
/selinux on /selinux type selinuxfs (rw,relatime)
/dev/mapper/VolGroup-lv_root on /mnt/sysimage type ext4 (rw,relatime,seclabel,barrier=1,data=ordered)
/dev/sdc1 on /mnt/sysimage/boot type ext4 (rw,relatime,seclabel,barrier=1,data=ordered)
/dev on /mnt/sysimage/dev type tmpfs (rw,relatime,seclabel)
/dev/devpts on /mnt/sysimage/dev/pts type devpts (rw,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
/dev/tmpfs on /mnt/sysimage/dev/shm type tmpfs (rw,relatime,rootcontext=system_u:object_r:tmpfs_t:s0,seclabel)
/dev/mapper/VolGroup-lv_home on /mnt/sysimage/home type ext4 (rw,relatime,seclabel,barrier=1,data=ordered)
/dev/proc on /mnt/sysimage/proc type proc (rw,relatime)
/dev/usbfs on /mnt/sysimage/proc/bus/usb type usbfs (rw,relatime)
/dev/selinuxfs on /mnt/sysimage/selinux type selinuxfs (rw,relatime)
/dev/sysfs on /mnt/sysimage/sys type sysfs (rw,relatime,seclabel)

The "ls /mnt/source" output
EFI
GPL
Packages
RPM-GPG-KEY-fedora
RPM-GPG-KEY-fedora-15-SPARC
RPM-GPG-KEY-fedora-15-primary
RPM-GPG-KEY-fedora-i386
RPM-GPG-KEY-fedora-sparc
RPM-GPG-KEY-fedora-sparc64
RPM-GPG-KEY-fedora-x86_64
TRANS.TBL
images
isolinux
repodata


The "df" output is
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev                   4096776         0   4096776   0% /dev
none                    256000      5832    250168   3% /tmp
/dev/sr1               3583208   3583208         0 100% /mnt/source
/dev/mapper/VolGroup-lv_root
                      36445800    180128  34414280   1% /mnt/sysimage
/dev/sdc1               495844     10512    459732   3% /mnt/sysimage/boot
/dev                   4096776         0   4096776   0% /mnt/sysimage/dev
/dev/tmpfs             4096776         0   4096776   0% /mnt/sysimage/dev/shm
/dev/mapper/VolGroup-lv_home
                      29802564    176064  28112620   1% /mnt/sysimage/home


(In reply to comment #17)
> (In reply to comment #16)
> > I did a little digging and found out the function call "dev.format.mount()"
> > called from _mountInstallCD(self) in pyanaconda/yuminstall.py fails and causes
> > the message "Please insert Fedora disc to continue".
> 
> Yes, we need to find out where exactly this fails. The workaround would break
> other cases unfortunately.
> 
> So please, use the new updates image:
> 
> http://akozumpl.fedorapeople.org/bz702511.img
> 
> (You can use it directly by appending
> updates=http://akozumpl.fedorapeople.org/bz702511.img to the syslinux prompt
> when your system boots, just press <tab> to get to see the prompt.)
> 
> Get to the point where you see the failure and attach all the log files to this
> bugzilla.
> 
> Also, please check if there are files in /mnt/source and attach the output of
> 'mount'.
> 
> Thank you and embrace for a few more rounds of this if we are to find and fix
> the error.

Ah, thanks.

I think I know what's going on: the drive can be mounted by 'mount' yet Anaconda is not unable to recognize your media because the drive does not correctly report ID_FS_TYPE.

To confirm this, can you please attach the output of 'udevadm info --export-db' to this BZ?

Created attachment 499200 [details]
output of udevadm_info_export_db

Output of udevadm_info_export_db attached.

Thanks for the analysis. I have attached the command output you requested.

Reassigning.

Kernel team,

it looks like 'Virtual CD IPMI' CD drive the reporter is using will not correctly expose ID_FS_TYPE in udev database. See comment 27, the field is missing entirely even when the disk is mounted.

This device appears as an ordinary USB cdrom. What does udev look for in order to assign ID_FS_TYPE??

BTW does the install work if you pick some other method of installation, then go back and choose local cdrom?

what is the output in the anaconda shell (alt-f2 or so) of:

# /lib/udev/cdrom_id --debug /dev/sr0

Created attachment 499749 [details]
Output of /lib/udev/cdrom_id --debug /dev/sr0

Output of command /lib/udev/cdrom_id --debug /dev/sr0

Created attachment 499750 [details]
/lib/udev/cdrom_id --debug /dev/sr1

Output of command /lib/udev/cdrom_id --debug /dev/sr1

I have attached outputs of "/lib/udev/cdrom_id --debug" for both /dev/sr0 and /dev/sr1. 

In my case the Virtual CD is detected as /dev/sr1 and mounted under /mnt/source. For more details please see the "df" output attached previously.

(In reply to comment #33)
> I have attached outputs of "/lib/udev/cdrom_id --debug" for both /dev/sr0 and
> /dev/sr1. 
> 
> In my case the Virtual CD is detected as /dev/sr1 and mounted under
> /mnt/source. For more details please see the "df" output attached previously.

So it was already mounted by anaconda?
Can you umount it before doing 
# /lib/udev/cdrom_id --debug /dev/sr1

Created attachment 500133 [details]
/lib/udev/cdrom_id --debug /dev/sr1 (after umount /mnt/source)

Here is the output from /lib/udev/cdrom_id --debug /dev/sr1, after unmounting /mnt/source

Created attachment 500135 [details]
/lib/udev/cdrom_id --debug /dev/sr1 (after mount /mnt/source)

/lib/udev/cdrom_id --debug /dev/sr1 ouput after I mounted /dev/sr1 back again. 
i.e.
1) umount /mnt/source
2) /lib/udev/cdrom_id --debug /dev/sr1 > sr1_umounted 2>&1 (previous attachement)
3) mount /dev/sr1 /mnt/source
4) /lib/udev/cdrom_id --debug /dev/sr1 > sr1_mounted 2>&1

Your implementation of the virtual CDROM is totally bogus. That software has to be really fixed. No ways we can workaround that buggy thing...

We really should add a workaround for anaconda for those really buggy implementations!

This is unfortunate, we generally try to avoid workarounds in Anaconda if the proper fix should be done on lower levels. I made an updates image for you that you can try, please confirm it helps:

http://akozumpl.fedorapeople.org/bz702511-fix.img

I will send the patch for review but it is entirely possible that the reviewers won't approve it.

Here is the patch:

https://www.redhat.com/archives/anaconda-devel-list/2011-May/msg00202.html

Thanks, the updated image made the install finish sucessfully.

The patch has been rejected: https://www.redhat.com/archives/anaconda-devel-list/2011-May/msg00203.html, there's nothing more I can do. Perhaps try raising a bug against kernel to fix your device driver.