Video Screencast Help

Altiris Imaging

Created: 11 Jun 2009 • Updated: 21 May 2010 | 5 comments
This issue has been solved. See solution.

Hi Guys,

This is my first post so please bear with me.

I've recently been imaging Lenovo Thinkpad laptops using Altiris Deployment and had some hiccups but eventually got through them, one which I noticed I kept getting and "error 41 during script execution" when trying to image newly acquired laptops.

Basically we have a new Dell Latitude E6400 (as we've just switched vendor to Dell) and I need to get imaging working on these laptops.

Can someone help me with the following log,
The first task in the deployment job is to push an altiris image to the machine, this works with success, its the next part which is a script that our consultant has wrote for us which has always worked.
I know there has been no change to the script, but still, I'm having issues.

Here is the script,

/mnt/ds/RDeploy/Linux/firm -recurse copy /mnt/ds/Drivers/%#*"SELECT LTRIM(RTRIM(manuf)) FROM computer where computer_id=%ID%"%%#*"SELECT LEFT(prod_name,4) FROM computer where computer_id=%ID%"%/Drivers "PROD:/Drivers"

Basically from what I can see, is that the script is sent to the PC and query's the MANUFACTURE ID & Model Number/Product Name, the PC reports what the MANUFACTUR IS (Dell/Lenovo) and also Model Number/Product Name and looks for a folder with both of these strings together as a folder name under a folder located on the DS - EG. "\\ALTIRISDS\EXPRESS\DRIVERS\LENOVO2746" From there it copies that folder to the local C:\drivers folder on the laptop, the laptop then restarts and runs through the setup of XP

I have setup a folder called DELL INC.LATITUDE within the DRIVERS folder on the DS share, and still I get this error 41.
However what is even weirder is if I remove the folder completely, I will receive error 46 during script execution.

I've checked permissions, case sensitive, anything I can think of...

I've copied log entry as per below.

Error description:
The file could not be opened.

Possible causes:
A file that was expected to exist does not exist.
You do not have permission for this operation on the file or directory.

Possible resolutions:
Make sure the file exists and is accessible.
If the missing file is part of this program, reinstall the program.
Fix the permissions on the file or directory.

==================== Technical details ====================

Logfile = created Thu Jun 11 08:38:02 2009
Build = firm 6.9 (9020)
Cmdline = /mnt/ds/RDeploy/Linux/firm -recurse copy /mnt/ds/Drivers/Dell Inc.Lati/Drivers PROD:/Drivers

Status = 41 (0x29)
Source file = imglib/fs/native/nativefs.cpp
Line number = 806 (0x326)
Stack trace = 0x80b559d 0x80b5899 0x804f81d 0x8053ba3 0x804b50d &Known=0x811d780
Path = /mnt/ds/Drivers/Dell
Imaging library revision = 9020 (linux-x86-release build, Fri Oct 10 23:50:32 2008)

Any help would be great!
I'm so stuck and I'm sure it's something quite simple.
Let me know if you need more info...

Thanks guys =]

Comments 5 CommentsJump to latest comment

bhawver's picture

Can you shorten the path (maybe conform to the old 8.3 naming convention of your folders).  This might be the reason.  Also avoid using spaces in folder names.

The other thing I can suggest for testing purposes is to make that folder empty (or just put a text file in it) and see if you get errors.  I have a feeling though it is probably because of the way it is named. 

Brian Hawver
Systems Engineer
Yaskawa America, Inc.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

Brandon's picture

Error description:
The file could not be opened.

Possible causes:
A file that was expected to exist does not exist.
==================== Technical details ====================

Logfile = created Thu Jun 11 08:38:02 2009
Build = firm 6.9 (9020)
Cmdline = /mnt/ds/RDeploy/Linux/firm -recurse copy /mnt/ds/Drivers/Dell Inc.Lati/Drivers PROD:/Drivers

I am guessing you went from a Manufacturer that previously only had 4 important chars in the product name to one that has more (all useless). Change your folder to just Dell Inc.Lati and it will work. That script seems a bit excessive to me. There may have been a reason to validate to that level, but otherwise I don't see why it is trimming and taking only 4 chars. I'd probably remove the whole LEFT(prod_name,4) thing and just have prod_name, then use full names. I don't work with Lenovo or DELL so there may be more to the prod_names with those models than I know about.

If you wanted to do this right, you would not use the Mauf + prod_name combo, and instead just use model_num. If you were to get another DELL model, they would likely return the same thing, so how would you tell it to use different drivers?

I'd use this:
/mnt/ds/RDeploy/Linux/firm -recurse copy /mnt/ds/Drivers/%#!computer@model_num%/Drivers "PROD:/Drivers"

then rename all your folders to use the model num, not the manf+prod... Lenovo may set their models numbers stupid, which could be the reason the consultant did it this way. If not, I'd change your script if you want your next Dell Lati to work.

adudley's picture

Hey guys thanks for your feedback!

I've changed the script to the following

/mnt/ds/RDeploy/Linux/firm -recurse copy /mnt/ds/Drivers/%#!computer@model_num%/Drivers "PROD:/Drivers"

and created a folder called "0H635N" which is the model number on the Dell Latitude in the Drivers folder on the DS, and now the script runs perfectly =]
I have seen alot of other people with similar issue, might be a good idea to advertise this fix?

Anyway, thanks alot guys! Great help for my first post!


ianatkin's picture

 For some, model_num might not be so intuitive. I've often found prod_name to be more useful as many vendors (Lenovo being the exception) putting something useful here.

Below is a screenshot of what the drivers folder can look like of you use the product name

imagebrowser image

As an aside, I strongly recommend using this technique to handle driver deployments rather than have a database do it. This provides a driver isolation between models, so updating one driver only affects the model you are updating.

This can also be seen as a down side of course... ;-)

Kind Regards,

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which assist you most in resolving your problem, and give a thumbs up to useful articles and downloads

Brandon's picture

Consider it advertised.

I agree that model_num isn't as pretty or obvious, but IMO it's more unique. It's like a Guid is to a computer name. To be nice I always create an emtpy folder with the product name within the model_num folder. I know with HP's the product name can change depending on when the order was made, so you can have two product names for one model. This may be better on the newer models.