OSDeploy / OSD

OSD Shared Functions
MIT License
149 stars 61 forks source link

Driverpack / SATA Controller issues #103

Closed sultanberisa closed 8 months ago

sultanberisa commented 9 months ago

We have a few specific models (Lenovo P53, P73 and X280) which BSOD when getting imaged using OSDCloud with the error "INACCESSIBLE_BOOT_DEVICE". I found that the issue is that the storage controller driver that is being applied from the driverpack seems to be incompatible with AHCI, because when we change SATA mode/controller to RST in BIOS it boots fine. Is there any way to tell OSDCloud to "ignore" / not download driverpacks either globally on a specific ISO or for a specific model? We are still testing and troubleshooting the issue to 100% confirm but it's quite difficult to troubleshoot when the driverpack gets downloaded and installed always no matter what as you can imagine 😄

Any ideas here?

gwblok commented 9 months ago

You can pass variables to OSDCloud to skip using a driver pack, or you can pick a specific one from that catalog and pass that in, or just have it pull all drivers from MS Updates.

What I've been doing is having the driver pack I want already on the USB flash drive expanded, then DISM that in after OSDCloud completes. You can look at my sample script that I "wrap" OSDCloud with for details: https://github.com/gwblok/garytown/blob/master/Dev/CloudScripts/SettingOSDCloudVarsSample.ps1

Checkout the functions: Test-DISMFromOSDCloudUSB Start-DISMFromOSDCloudUSB

I can't help with Lenovo specific issues, I have no experience with them, but the process should work similar to how I'm doing it with HP devices.

sultanberisa commented 9 months ago

You can pass variables to OSDCloud to skip using a driver pack, or you can pick a specific one from that catalog and pass that in, or just have it pull all drivers from MS Updates.

What I've been doing is having the driver pack I want already on the USB flash drive expanded, then DISM that in after OSDCloud completes. You can look at my sample script that I "wrap" OSDCloud with for details: https://github.com/gwblok/garytown/blob/master/Dev/CloudScripts/SettingOSDCloudVarsSample.ps1

Checkout the functions: Test-DISMFromOSDCloudUSB Start-DISMFromOSDCloudUSB

I can't help with Lenovo specific issues, I have no experience with them, but the process should work similar to how I'm doing it with HP devices.

Quick question. After some testing I've not managed to get osdcloud to listen to the variables, seems as if even though i set them they get overwritten or just simply get ignored... However i noticed i am not writing the variables to the console. Is that necessary in order for the changes to get done?

gwblok commented 9 months ago

Quick question. After some testing I've not managed to get osdcloud to listen to the variables, seems as if even though i set them they get overwritten or just simply get ignored... However i noticed i am not writing the variables to the console. Is that necessary in order for the changes to get done?

No, I only write them out during test to easily confirm what variables I've set before trigging OSDCloud.

You're setting the variables and calling OSDCloud all from the same session, right? (same script)

oingobo commented 9 months ago

We're seeing the same problem with Lenovo Yoga Gen 3 and Lenovo Yoga gen 4. Build process is dead in the water and the machines are bricked.

gwblok commented 9 months ago

For now, I want you to try this: Start OSDCloudUSB when it gets to the powershell prompt, type iex (irm test.garytown.com)

Feel free to look at the script here: https://github.com/gwblok/garytown/edit/master/Dev/CloudScripts/test.ps1

That will run OSDCloud, Windows 11 23H2 and DISM in the driver packs you have on your Flash Drive already expanded. For this to work, place the drivers for your devices in this folder structure: OSDCLoudUSB:\OSDCloud\DriverPacks\DISM\$ComputerManufacturer\$ComputerProduct

$ComputerProduct = (Get-MyComputerProduct) $ComputerManufacturer = (Get-MyComputerManufacturer -Brief)

Example: OSDCLoudUSB:\OSDCloud\DriverPacks\DISM\Lenovo\10MQ

after OSDCloud completes, that function [ Start-DISMFromOSDCloudUSB] will search the OSDCloudUSB drive for matching folder for that model, then DISM in any drivers.

If that works, I'd suggest for now, modifying your process to use drivers you've put onto your flash drives.

I've done several tests with this on HP hardware, works great.

Otherwise, if you need to modify BIOS settings and set it to RST, you could incorporate modification of the BIOS settings before OSDCloud starts.

Looking forward to hearing your test results.

gwblok commented 8 months ago

@sultanberisa , @oingobo , any updates? have to tried any of the suggestions I provided?

sultanberisa commented 8 months ago

@sultanberisa , @oingobo , any updates? have to tried any of the suggestions I provided?

Hey, sorry for late reply. We found a solution to this before reading your post. Our solution was the following:

   #P53 P73 X280 Fix
    if (($(Get-WmiObject -Class Win32_ComputerSystemProduct).Vendor -imatch "Lenovo") -and ($(Get-WmiObject -Class Win32_ComputerSystemProduct).Version -imatch "X280|P53|P73|L480|X390|T590")) {
        $Global:OSDCloud.DriverPackName = "None"
        $Global:StartOSDCloudGUI = @{
            DriverPackName = "None"
        }
    }

We attempted beforehand to add drivers using edit-osdcloudwinpe, with the driver pack itself, aswell as doing a manual clean install with AHCI and exporting the drivers, then adding them using edit-osdcloudwinpe. We were still getting bsods. Also attempted to inject the drivers manually. No matter what we were doing, it was causing a BSOD. seems like the driverpack was simply "broken" or missing some component for AHCI support. We saw that it may have been possible to modify BIOS to RST programmatically but we found it an easier solution to simply tell osdcloud to not download the driverpacks.

gwblok commented 8 months ago

Closing issue. Workarounds have been found. Driver Pack Catalogs used in OSDCloud are built based on the available vendor catalogs. If there are issues in the vendor catalogs at the time we're running the sync, they will hopefully be resolved the next sync.