Deployment Solution

Group,

Total newbie, but here it goes.

I have created a network boot CD with the correct NIC drivers and I can manually mount the express mount point.  But I have to change what is created in Altiris from:

mkdir -p "/mnt/ds"
asmbmount -b -d EPECAD -f /altdeplo.pwl //server/eXpress /mnt/ds

to:

mkdir /mnt/ds
asmbmount -b -d EPECAD -f /altdeplo.pwl //server/express /mnt/ds

Otherwise the mount fails.  Once I run those commands manually I'm good to write and read from the express share.  So then I use the same parameters, by editing mounts.local on an Automation boot disk and it still fails because it cannot mount express.   I know I have connectivity because I can connect to the server manually using the network boot CD.   I have tested the credentials as well mounting from a windows box.  I can write to the express share when I mount it manually. 

Does anyone have any insight?

Much thanks,
Dave

Group,

So I realized the mount point should be named express so I changed that in the config...  

So using the automation disk I created, before it reboots I'm able to run mounts.local and it mounts the express share properly.   I looked at /proc/mounts and it has the correct user info in there, but the the share doesn't get mounted before rc.agent is run.   Can someone give me an idea of what I'm missing here. 


Also, how do you get the automation disk to stop rebooting so you can troubleshoot it?

Thanks,
Dave

I'm pretty sure that the mount point should be /mnt/ds and should not be called express (not that you can't have a mount point called express, but in general, most scripts look for /mnt/ds).  The reason it is rebooting would either because the agent doesn't see the DS server or there are no jobs scheduled for the client.  To test this theory, if the machine is showing up in the console, execute a "Wait" job.  This will keep the machine from rebooting if it is indeed checking in. 

So what I'm trying to figure out is why does the boot disk creator put in bad syntax for the mount to begin with and why when the info is corrected does it still not mount the share no matter what it is called at boot time?  If I kill the agent off, manually mount the shares and rerun the agent it still reboots even when a WAIT has been instructed.  I have IP connectivity to the server and can communicate to it on port 402 both UDP and TCP.  

So on a whim I decided to boot to another totally different computer.  When it booted the agent came up and said to wait.   Then I rebooted the machine and it goes in the cycle I'm stuck in of rebooting.   It does not mount the DS share properly, but at least I know the first time it communicates with the server.  From there?

TIA,
Dave

Once the WAIT command has been executed, the next time you reboot it won't have anything to do and will go back on the reboot cycle.

In regards to the boot disk creator, I'm not sure why it would give you a problem (unless there is a problem with the PWL file it is using).  You can modify these in the boot disk creator to manually map everything via a script, but be careful on placing passwords in the scripts.  I am manually mounting mine as mine is based on what subnet the person is coming in from (as you can see below, I use variables).  These commands are placed in the rc.local file and then I comment out the mount commands in the mounts.local.

asmbmount -b -d DOMAIN -f /serverad.pwl //$LOCAL_SERVER_NAME/$LOCAL_SERVER_SHARE /mnt/ds 

But if I want to image the machine deployment console reboots it.  From there it doesn't mount the share so it fails then reboots...   and reboots... and reboots...  

So to test that theory I deleted the machine, booted to my automation CD.   Waited for the agent to tell me to wait.  From the deployment console I right clicked the computer and chose quick image and chose OK.  This forced the computer to reboot.  Once the machine rebooted I killed the agent.  Manually ran /etc/mounts.local.  Verified it mounted the share by cd /mnt/ds and did an ls.   After that I ran ./etc/rc.agent   It sat for a few seconds then rebooted, rebooted rebooted...  I'm so lost...

TIA,
Dave

thanks...

Did you try editing the rc.local as I mentioned above?  Also, you'll want to make sure that it's not the PWL file causing the problem with an invalid password (try to keep the password under 8 characters...I've seen that be an issue as well). 

quick disk image assumes some things.

1. to boot into production to capture settings of the computer (if capturing) or it will try to use what the default automation envoriment is set to.
2. always use default automation

I would create a job to capture or deploy and set the automation enviroment to Linux.