Driver feed 3.4 State/clarification
Hello,
I've been trying to get an XPS 13 working with the K2000 and have ended up being completely stumped at the moment. A quick summary of the setup:
Windows 7 Pro base image, sysprepped
Imaging flow ->
1)Switch driver letters to get the partitions laid in th correct places
2) BCD partition fix
3) Driver feed mid-task (from http://www.itninja.com/question/driver-feed-workaround-and-drivers)
4) Install driver feed (from above page)
As I understand it if I'm using those two tasks, I should have my drivers in \\kbox\drivers_postinstall\dell\windows_7_x64\Dell_System_XPS_L321X (via the Get Manufacturer vbs script)
However once the image finishes coming down, the mid-level get drivers task gets run but nothing is pulled down. I can't seem to figure out how to debug it because of how little feedback it gives.
I guess in a similar vein, I've tried running the task from peinst in the kbox environment and it does the same non-informative behavior. Is there a better way to test this out rather than waiting for the machine to reimage?
Let me know if I'm crazy or not, or if you need more information.
Thanks,
Edwin
Answers (3)
Edwin,
If using the driverfeed workaround, run the model_report.exe on the system in question. There is a difference with how the workaround does models compared to the built in tool. I'm working on a revision to match it, but not there yet.
Corey
Lead L3 Enterprise Solutions Engineer, K2000
If my response was helpful, please rate it!
Comments:
-
Hmm, they both reported the same Dell_System_XPS_L321X. I have a workaround for this at the moment. I ended up placing the drivers on a share, copying the sare as a midlevel task and running dpinst on the them once in Windows. It'll work for now. - eavalos 11 years ago
I think you are missing an "_" in \windows7_x64\. It should read \windows_7_x64\. We are a straight Lenovo shop, but this format works for my scripted installs. I would think they would still follow the same format. I have not yet tested this on system images.
Comments:
-
Ah thanks for pointing that out (right on the KBOX, wrong on my post) - eavalos 11 years ago
I had the same issue trying to get drivers to work on my XPS 13 deployment, ended up writing a script that would manually run DISM on the driver location as a mid-level task instead of the driver feed task:
for /F "tokens=5" %%A in ('dir Y:\drivers\windows_7_x64\driverharvest\dell_system_xps_l321x\*.inf') DO dism /image:c:\ /add-driver /driver:Y:\drivers\windows_7_x64\driverharvest\dell_system_xps_l321x\%%A /forceunsigned
Works at the moment. Couldn't figure out for the life of me why the system names weren't matching up, would like to see this work with just the driver feed midlevel task.
Also, you can run the driver feed midlevel task with a /debug option and it will give you popups detailing the progress.
Comments:
-
The driverfeed mid task won't work in your situation because of the driverharvest folder. If you take that directory out of the sequence it should work. - cserrins 11 years ago
