Unable to Install any Firmware Updates

I experienced a similar issue and was able to work around it by deselecting anything that was green (already deployed).  Not sure why this worked, but I suspect that the logic in the Beta OME is not handling the alrerady deployed software as we would expect.

I have a customer who is having similar issues trying to get updates to execute from an HTTP source where whenever he tries to do this the task fails with:

'The package downloaded coundn’t be validated. Invalid package task. Execution has completed'

He has come back as follows:

'I have made a small discovery as to why it won’t install patches from the catalog.

It looks like it’s munging the path incorrectly and converting ‘/‘ in to ‘\’ which aren’t valid in a url.

As a result when using http with a catalog path of:

/PAS/dell/one/SUU/full/Catalog.xml

I see an http GET request :

/\PAS\dell\ome/SUU\full/FolderXXXXXXX/1/

Which the apache webserver responds with a 404 as it doesn’t have that file.

When fixing the GET request and posting by hand from another server (obviously I can’t change the appliance code) I get the requested files'

Any comments? Could this be fixed please?

When using an offline / custom repository created with the Dell Repository Manager.

I can confirm a couple of workarounds / bodges to get this working.

Either:

If you had the apache mod_rewrite module available you can add the following to your virtual server definition to rewrite all the forward slash characters to backslash characters.

RewriteEngine On
RewriteCond %{REQUEST_URI} (.*)\\(.*)
RewriteRule .* %1/%2 [R=301]

This will convert the request from

GET /\PAS\dell\ome\SUU\full/FolderXXXXXXX/1/ HTTP/1.1
 

to

GET /PAS/dell/ome/SUU/full/FolderXXXXXXX/1/ HTTP/1.1
 

which will then work as expected.

OR

Add the following to your apache virtual server config (assuming you can use mod_alias, which is almost always available):

Alias /SUU /path/to/catalog/

This basically leaves your path to the catalog containing only the final "/" before the Catalog.xml file which gets stripped when using it to generate the resulting file path.  Therefore there's no longer other "/" characters to get munged incorrectly and your requests will be successful.

Your catalog path will then become "SUU/Catalog.xml"

This will mean generate the successful request:

GET /SUU/FolderXXXXXXX/1/ HTTP/1.1
 

Hope this helps others.

Please can someone from Dell raise this as a formal bug so it gets fixed rather than needing to do this work around.

It's 2019 Mar now and clearly this issue is still not resovled. Dell... **bleep**?

I have a customer who is having similar issues trying to get updates to execute from an HTTP source where whenever he tries to do this the task fails with:

'The package downloaded coundn’t be validated. Invalid package task. Execution has completed'

He has come back as follows:

'I have made a small discovery as to why it won’t install patches from the catalog.

 

It looks like it’s munging the path incorrectly and converting ‘/‘ in to ‘\’ which aren’t valid in a url.

 

As a result when using http with a catalog path of:

/PAS/dell/one/SUU/full/Catalog.xml

 

I see an http GET request :

/\PAS\dell\ome/SUU\full/FolderXXXXXXX/1/

 

Which the apache webserver responds with a 404 as it doesn’t have that file.

 

When fixing the GET request and posting by hand from another server (obviously I can’t change the appliance code) I get the requested files'

Any comments? Could this be fixed please?


 

Just want to confirm that we are seeing the same issue.

Dell, are we working on fixing this? We can open cases if that helps you!

---

 

Dell, are we working on fixing this? We can open cases if that helps you!

---

That almost sounds like a threat :-P

From what I see the community is (obviously) best effort. You should open cases. Otherwise you don't get heard. It's like people writing in forums that their domestic animal is currently gasping for air, well you should be at the vet and not in the forum...

You can open cases using TechDirect if you don't prefer hanging on the phone all day spelling and respelling names, phone numbers, service tags and email addresses. Just use one of your service tags having an OME license attached to the server.

Depending on the team it is assigned to, this actually helps! I've had good experiences with technicians from the UK, and an engineer (senior guy) from Germany. The case assigned to the French guys was the worst.

We are getting the exact same issue when trying to update from an internal repo using HTTP

The package downloaded couldn't be validated. Invalid Package.
Task Failed. Completed With Errors.

Did anyone find any solution?

Ran into the same issue this week trying to use an internal http-server creating custom catalogs...

Things I did:

1) changed the "Catalog File Path" in OME / Catalog Management to exclude leading "/" - so my path is now: DRM_REPO\Q12020/Q1_2020_EX_MNOX_1.03_Catalog.xml

2) checked Apache access log on the HTTP-server and the get-request from OME looks for firmware file in a "\\DRM_REPO\FOLDER05695846M\firmware_x.x.x.EXE" but that "FOLDERxxx" did not exist in my repository so obvious I will get a 404 in the access log and firmware update fails in OME.

3) Re-created my repository using DELL DRM and selected a new folder to export my repo to (I create the original repo on my computer, then export the repo and select a new folder, for some reason now the folder names are created. The repo-folder consists of 1400 sub-folders and 1052 files). Copied the repo-folder(s) to the HTTP-server and created a new Catalog in OME.

(in C:\ProgramData\Dell\drm\store\ the "DRM Store" is built with these FOLDER-names, so I guess it depends how you use the DRM GUI, it behaves wrong in some scenarios?!?)

4) now the update works - checking the idrac / update log the firmware has landed in the update queue!

So - go and check the Apache log - it can give you clues how to solve the failing updates!

/Mats

It's an old thread here but one I found with the same issue on the latest version 3.8.3 build 8. After trying many other "things", I resolved it by deleting the baselines from the catalog, deleting the catalog, and building a new catalog and then a new baseline. Worked the first time after the rebuild.