Bug 810553

*** This bug has been marked as a duplicate of bug 787461 ***

I'm not sure why this was closed as a dupe. 787461 was really a different bug - it was about our old method of *attempting* to eject the optical medium screwing with the install - and it was closed long before this bug was reported, so even though a comment on 787461 claims eject was made to work again, this bug should have been taken as a report that it wasn't really working.

Anyway, I'm pretty sure I never once saw an optical install disk be ejected at the end of install in F18 testing, I just tested 17 and 18 in KVM VMs and the DVD doesn't get disconnected at the end of install, and it's mentioned in http://www.forums.fedoraforum.org/showpost.php?p=1629519&postcount=1 .

So I'm re-opening this, as far as I can tell it's still valid - we're not succeeding in ejecting optical install media at the end of install at present, but we still appear to be trying to (cf. pyanaconda/iutil.py ).

Two things seem to try and call dracut_eject in iutil.py - 'anaconda' itself and pyanaconda/installmethod.py . The code to do so in pyanaconda/installmethod.py looks pretty suspiciously hoary to me:

    def _ejectDevice():
        # Ejecting the CD/DVD for kickstart is handled at the end of anaconda
        if anaconda.ksdata:
            return None

        if anaconda.mediaDevice:
            return anaconda.storage.devicetree.getDeviceByName(anaconda.mediaDevice)

        # If we booted off the boot.iso instead of disc 1, eject that as well.
        if anaconda.stage2 and anaconda.stage2.startswith("cdrom://"):
            dev = anaconda.stage2[8:].split(':')[0]
            return anaconda.storage.devicetree.getDeviceByName(dev)

    dev = _ejectDevice()
    if dev:
        dracut_eject(dev.path)

disc 1? stage 2? cdrom:// ? hoo boy.

dracut_eject appears to try and log either success or failure when called:

log.info("Wrote dracut shutdown eject hook for %s" % (device,))
    except Exception, e:
        log.error("Error writing dracut shutdown eject hook for %s: %s" % (device, e))

after doing an F18 install from DVD and rebooting to the installed system, 'grep eject /var/log/anaconda/*' gives zero output, so it doesn't look like dracut_eject gets called at all.

I also have never seen eject or disconnect of a live or install disk in f17 and f18.
A workaround in VirtualBox is to hit machine / close / power off when the .iso or DVD trys to reboot after an install completes.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

I can confirm that this is a problem with both FC18 and FC19.  The eject flag for the reboot directive in the kickstart file seems to be ignored.

i.e. ks.cfg contains the following:
  reboot --eject
Yet the optical disc is not ejected after the reboot.

In my tests, I have done the following with isoconfig.

label linux
  menu label ^Install Fedora
  menu default
  kernel vmlinuz
  append initrd=initrd.img inst.stage2=cdrom:CDLABEL=<product name> ks=cdrom:
/dev/cdrom:/ks.cfg biosdevname=0

Do you mean "the optical disk is not ejected *before* the reboot"? We can't eject the drive *after* rebooting...

What actually happens with the optical drive at the end of the install? Is this an actual machine, or a VirtualBox system?

If it's a VirtualBox system: we do eject the virtual disc, but when the VirtualBox restarts it seems to re-insert the disc. You may need to remove/detach the optical drive from the guest after the install completes. See https://www.virtualbox.org/ticket/9858.

(In reply to Will Woods from comment #6)
> Do you mean "the optical disk is not ejected *before* the reboot"? We can't
> eject the drive *after* rebooting...

Yes - sorry for the misunderstanding.  I meant it is not ejected *after* processing the reboot command, but *before* the actual reboot completed.

> What actually happens with the optical drive at the end of the install? Is
> this an actual machine, or a VirtualBox system?

This is a VirtualBox system.
 
> If it's a VirtualBox system: we do eject the virtual disc, but when the
> VirtualBox restarts it seems to re-insert the disc. You may need to
> remove/detach the optical drive from the guest after the install completes.
> See https://www.virtualbox.org/ticket/9858.

I read this bug, and it should happen for all images.  However, I am creating FC16 images using the exact same process, and they always properly eject the disc after installation.  I only see the problem with FC18 and FC19.  

I haven't tried FC17, nor have I tried in a real system, but so far my VirtualBox testing seems to be conclusive - there is a problem ejecting the disc in FC18 and FC19 that is not present in FC16.

(In reply to Will Woods from comment #6)

> What actually happens with the optical drive at the end of the install? 

As far as I can tell, nothing happens.  Is there a way I can detect if it was ejected and re-inserted?  The timing window appears to be relatively short.