Created attachment 990384 [details]
anaconda.ifcfg.log

Created attachment 990385 [details]
anaconda-ks.cfg

Created attachment 990386 [details]
anaconda.log

Created attachment 990387 [details]
anaconda.program.log

Created attachment 990388 [details]
anaconda.storage.log

Created attachment 990389 [details]
anaconda.xlog

Created attachment 990390 [details]
syslog

Yes, this is expected, actually anaconda ejects cdrom devices that were mounted during installation which includes DVD used for installation but apparently doesn't include the ISO customer is using for intial boot (See also bug 949919).

Given the ISO is not mounted and used by installer process it should be possible to just use "eject <DEVNAME>" command (or just "eject" which will use "/dev/cdrom") in %post section of kickstart.

According to a customer, ejecting the disk in a postinstall script does not work either.

Also this was reproduced on 7.4 on bare metal

Also Vmware

Joe, could you attach the installation logs? They are in /tmp/ during the installation or in /var/log/anaconda/ on installed system. Kickstart file would help as well.
Thanks

Attached

With a client who is experiencing this issue on VMWare.  Has a resolution been found? 

Just to clarify, "reboot --eject" in the kickstart does not work and neither does the "eject /dev/name" in the %post section.

Sorry for butting in, but did anyone try eject -i 0 (unlock the tray) before eject /dev/name in %post in case the tray was left locked by something?

(In reply to Shane Seymour from comment #35)
> Sorry for butting in, but did anyone try eject -i 0 (unlock the tray) before
> eject /dev/name in %post in case the tray was left locked by something?

Yes.  doing an `eject -i 0` allows the `reboot --eject` to work.  However, `reboot --eject` worked in the past without the tray unlock step.  Seems the behavior of `reboot --eject` has changed.

(In reply to Nate Revo from comment #38)
> 
> Seems the behavior of `reboot --eject` has changed.

I thought that the kernel will lock the tray when the DVD is open for data access (and unlock it when there are no more opens left). Is there any chance that it could still be open at the time you're attempting to do the eject? If it is then it won't be able to eject it.

drivers/cdrom/cdrom.c

1027 static
1028 int open_for_data(struct cdrom_device_info * cdi)
1029 {
...
1113         if (CDROM_CAN(CDC_LOCK) && (cdi->options & CDO_LOCK)) {
1114                         cdo->lock_door(cdi, 1);
1115                         cdinfo(CD_OPEN, "door locked.\n");
1116         }
1117         cdinfo(CD_OPEN, "device opened successfully.\n"); 
1118         return ret;
...

I'd suggest turning on debug output (cdrom.debug=1) from the cdrom driver to catch the tray being locked - if the driver is locking it and never unlocking it you'd see the above message without any message about unlocking it (I believe it should get unlocked when all closes have been done). I've no idea how verbose the output will be.

In a worst case situation test booting with cdrom.lockdoor=0 on the kernel command line to see if preventing the driver from locking the door sheds any light on the situation. That will show if something other than the kernel is locking the tray.

Created attachment 1402220 [details]
File installation_logs_no_options.tar

Supreet,
thanks for the logs. It looks like the customer doesn't use DVD as the installation source, but it's only used for booting.
Please, see comments 20 and 21 with a similar issue. RFE for ejecting DVD not used as the installation source is tracked separately in bug 1499792.

The original issue behind this BZ was `reboot --eject` not working in kickstart when you boot and install from optical media appears to have been addressed so I am closing this CURRENT RELEASE. 
Work will continue in BZ 1499792 which is an RFE for new functionality where `reboot --eject` will work when you boot but do not install from optical media.