Manually Mounting the eXpress Share in an Altiris Linux Pre-Boot Environment
Filed under:
Deployment Solution
Automation, Deployment, Support, Troubleshooting, UNIX/Linux, Testing, Command Line
Submitted by SK on 5 March, 2008 - 12:05.
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.
(44 votes)
- Login or register to post comments
- 2538 reads
- Printer-friendly version
Manually Mounting the eXpress Share in an Altiris Linux Pre-Boot
well the Linux PE actually executes that command, I guess it will fail if it failed before. right?
--nelo
ASMBMOUNT
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.
You can verify this another way
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.
Mount already working
If you used a DS Job, then the mount has already been successful, which eliminates the need to run this test.
Possibly, possibly not
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.