I have been working on a CD/DVD based scripted installation for our ESX DR deployment and have run into an annoying issue: The build CD/DVD will not eject after the install is complete. Observing the install shows that there appears to be a mount that cannot be unmounted. Specifically it states the following:
unmount: cannot unmount /mnt/sysimage/var/log: Device or resource busy
unmount: cannot unmount /mnt/sysimage: Device or resource busy
I assume that this may be my problem. Otherwise the build executes with no issues. The only drawback is that I have to remove the CD/DVD from the drive before the system reboots otherwise it will boot to the install and not ESX. I have at least removed the timeout so that it doesn't automatically boot into the default install sequence. Below is an example of my cfg file for the Kickstart process.
Regards,
RC
-
accepteula
keyboard us
auth --enablemd5 --enableshadow
clearpart --firstdisk --overwritevmfs
install cdrom
rootpw iscrypted---
timezone --utc 'America/New_York'
network --addvmportgroup=false --device=vmnic0 --bootproto=static --ip=x.x.x.x --netmask=x.x.x.x --gateway=x.x.x.x --nameserver=x.x.x.x --hostname=myesxserver.domain.com
part '/boot' --fstype=ext3 --size=1100 --onfirstdisk
part 'none' --fstype=vmkcore --size=110 --onfirstdisk
part 'Local-Storage1' --fstype=vmfs3 --size=47605 --grow --onfirstdisk
virtualdisk 'esxconsole' --size=46605 --onvmfs='Local-Storage1'
part 'swap' --fstype=swap --size=1600 --maxsize=1600 --grow --onvirtualdisk='esxconsole'
part '/var/log' --fstype=ext3 --size=20000 --maxsize=20000 --grow --onvirtualdisk='esxconsole'
part '/' --fstype=ext3 --size=20000 --maxsize=20000 --grow --onvirtualdisk='esxconsole'
part '/tmp' --fstype=ext3 --size=5000 --maxsize=5000 --grow --onvirtualdisk='esxconsole'
reboot
%post --interpreter=bash
#----
#| NTP configuration |
#----
#Backup ntpd.conf and step-tickers file
mv /etc/ntpd.conf /etc/ntpd.conf.bak
mv /etc/ntpd/step-tickers /etc/ntpd/step-tickers.bak
#Add Servers to step-tickers
echo "x.x.x.x" > /etc/ntp/step-tickers
echo "x.x.x.x" >> /etc/ntp/step-tickers
#create ntp.conf
echo "restrict 127.0.0.1" > /etc/ntp.conf
echo "restrict default kod nomodify notrap" >> /etc/ntp.conf
echo "server x.x.x.x" >> /etc/ntp.conf
echo "server x.x.x.x" >> /etc/ntp.conf
echo "driftfile /var/lib/ntp/drift" >> /etc/ntp.conf
#Service restart
service ntpd restart
#Make ntp start at boot time
chkconfig --level 345 ntpd on
#Sync hardware clock
hwclock --systohc
#----
#Create the Virtual Machine Network vSwitch |
#| vSwitch1 creation and NIC assignments |
#----
#Create vSwitch1
/usr/sbin/esxcfg-vswitch -a vSwitch1
/usr/sbin/esxcfg-vswitch -L vmnic1 vSwitch1
#Create Virtual Machine port groups on vSwitch1
/usr/sbin/esxcfg-vswitch -A "XXXX" vSwitch1
/usr/sbin/esxcfg-vswitch -A "XXXX" vSwitch1
/usr/sbin/esxcfg-vswitch -A "XXXX" vSwitch1
/usr/sbin/esxcfg-vswitch -A "XXXX" vSwitch1
/usr/sbin/esxcfg-vswitch -A "Local" vSwitch1
#Set VLAN ID on Virtual Machine port groups
/usr/sbin/esxcfg-vswitch -p "XXXX" -v 100 vSwitch1
/usr/sbin/esxcfg-vswitch -p "XXXX" -v 200 vSwitch1
/usr/sbin/esxcfg-vswitch -p "XXXX" -v 300 vSwitch1
/usr/sbin/esxcfg-vswitch -p "XXXX" -v 400 vSwitch1
#Restart vmware mgmt service
service mgmt-vmware restart
#----
#| Firewall Configuration |
#----
echo "Now configuring firewall..."
#Open for SSH client
esxcfg-firewall -e sshClient
#Open for SSH Server
esxcfg-firewall -e sshServer
#Open for ntp out
esxcfg-firewall -e ntpClient
#Restart firewall to enable changes
#----
#| Enable Root SSH Access |
#----
/bin/cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sed -e 's/PermitRootLogin no/PermitRootLogin yes/' /etc/ssh/sshd_config > /etc/ssh/sshd_config.new
mv -f /etc/ssh/sshd_config.new /etc/ssh/sshd_config
#=====Copy Backup Exec System Recovery and ERD ISOs to local /vmimages/tools-isoimages folder
mount /mnt/cdrom
cp /mnt/cdrom/BESR85_AllWin_English_SrdOnly.iso /vmimages/tools-isoimages
cp /mnt/cdrom/ERD.iso /vmimages/tools-isoimages
umount /mnt/cdrom
End of script..................
Message was edited by: RCHSN
Message was edited by: RCHSN
Message was edited by: RCHSN - Fixed issue of formatting post section comments using '#'
Its strange !! eject has to work by default after reboot, until we specify the optional switch --noeject (http://www.vmware.com/pdf/vsphere4/r40_u1/vsp_40_u1_esx_vc_installation_guide.pdf).
Can you check the command 'eject' is working fine on 4.0 on your particular hardware?
:+: VCP3, VCP4, RHCE, EMCPA.
There does not appear to be an eject command availble from the console. Typing "eject" as a test from the service console displays the following:
-bash: eject: command not found
Easy solution, change the BIOS boot priority to Disk, when you start the kickstart script, force it boot from a CD.
The next time the machine reboots, it will revert to the disk. Piece of cake!
Believe me, no one appreciates a simple solution like me, but in the essence of recovery time and a "set it and forget it" goal, I really need the install media to eject so that my ESX server is up and running asap.
Any ideas as to why the following mounts are still in use during the end of the install?
unmount: cannot unmount /mnt/sysimage/var/log: Device or resource busy
unmount: cannot unmount /mnt/sysimage: Device or resource busy
This does not specifically answer your question but we switched from CD to URL and it's been great (it's wonderful):
url --url=http://a.b.c.d/esxcfg/cdrom/35u4
Ben
Thank you for the suggestion Ben. Unfortunatly one of my requirements is to have a build CD that is self contained and not dependant on any other resource. I used this method with 3.5 with no issues. Out of curiosity I did a test specifiying a web server for the kickstart file location but ended up with the same umount error. Do you think I'm on the right track with the umount error as the source of my eject issue?
Hi,
1. There actually still is an eject command (used by the reboot kickstart command); its in the busybox; try $busybox eject. I use the combination of reboot --noeject and a manual busybox eject command at the end of our install scripts
2. The /mnt/sysimage message are probably caused by a service that is logging to /var, in my case it was the ntpd service. So make sure u have stopped any services u have started in the post section before eject/reboot.
Hope this clears things up.
Cheerz,
HMar
I had to add a second %post section at the bottom of my scripts:
%post --interpreter=bash --nochroot --ignorefailure=true
umount /mnt/cdrom
umount /mnt/source
/usr/bin/eject
Please award points if helpful.
Good luck,
Warren
Believe me, no one appreciates a simple solution like me
So simple yet you overlook a very obvious fact. You have to be STANDING in front of the machine to put the CD drive in, then you have to initiate some command to start the process. you walk away, fine.
Every new computer has this little command it's called BOOT parameters, so you press F10 tell it to BOOT from CD this ONE time, then you continue as normal.
But you would rather find some complex script command to achieve the same thing, so while it could be more thorough it's certainly NOT simple.
Simple is basic, it's one extra key stroke. Is it really that much of a impetus, which you consider that depending on manufacturer you have to change the BOOT order anyway... I find that remarkably anti-productive.
I've been working on an ESXi 4.1 scripted install, and ran into the same non-ejection issue. But the fix is slightly different from what worked on ESX4.0 as I posted above. I added this as my post section in ESXi4.1:
%post --interpreter=busybox --unsupported --ignorefailure=true
eject /dev/cdrom
for f in `ls /dev/cdrom/mpx.*`
do
eject $f
done
reboot
In ESXi 4.1, they place multiple cdroms under /dev/cdrom. This block above enumerates that list, then ejects each one. I left the "eject /dev/cdrom" in case there is a scenario where it is defined as a single unit. Note, use back quotes around the ls command.
I think the real culprit is a typo in one of the weasel python scripts, tidy.py. In it, they seem to have left a trailing s off of a call to an ejectCdroms function in the cdutil.py module. Might be unrelated, and I've not had time to rebuild a ienviron.vgz to test this suspicion yet. Maybe some day I'll have time to try.
Warren
Hi Warren,
Unfortunately (or fortunately, depending on how you look at things) I have moved on to a different company and no longer have the time or resources to fully test your suggested fix. However I appreciate your informed and thoughtful response.
RC