Manually Mounting the eXpress Share in an Altiris Linux Pre-Boot Environment
Created: 05 Mar 2008 | Updated: 05 Mar 2008 | 5 comments
A Linux pre-boot environment has been created (PXE, Automation BootDisk, Network BootDisk, etc), however, when it runs it fails to mount to the DS. How can the mount process be tested from the "/#" prompt?
Run the following command:
"mount -t cifs -o username=[username],workgroup=[workgroup/domain],password=[password] //[dsname/IP/FQDN]/express /mnt/ds"
If this action is successful, the "/#" prompt will return, otherwise an error or usage screen will be returned.
To check the mount, type "mount" which will display all mounted devices, directories, etc.
"cd mnt/ds" will provide access to the DS mount point.
Typing "ls" will provide a directory listing of the DS mount point.
Blog Entry Filed Under:
The Endpoint Management Community Blog is the perfect place to share short, timely insights including product tips, news and other information relevant to the Endpoint Management community. Any authenticated Connect member can contribute to this blog.
Comments 5 Comments • Jump to latest comment
well the Linux PE actually executes that command, I guess it will fail if it failed before. right?
--nelo
LinuxPE uses ASMBMOUNT which requires the *.pwl file that contains the account details.
If it either fails to find this file (BDC bug with an account that has a hyphen as its prefix for instance), or, if the account is incorrect, it will leave you at the /# prompt, which will allow you to try a manual mount with that account for easy diagnosing.
If you're doing this inside an Altiris job, I suggest you do it as a separate task. After mounting the drive, you can run:
mount | grep /mnt/ds
and then let Altiris see the return code from grep. An error code of zero will mean that the text was found (therefore the mount was successful) or error code 1 will mean that the mount didn't run.
This is more stable than checking the returncode from "mount" directly, because a situation may occur where the share is already mounted. In that case, the mount command would produce an error, but it would be safe to continue with the job.
If you used a DS Job, then the mount has already been successful, which eliminates the need to run this test.
If you're talking specifically about a LinuxPE job, I would agree. It's a freshly booted system in a reasonably known state.
But, if you're deploying a job to a Production-level Linux machine running adlagent, it may have been running for months or years. You can't make an assumption about the status of any mounts.
And you can deploy jobs via the agent without having the DS mounted anywhere.
Would you like to reply?
Login or Register to post your comment.