Custom smart bootable iso issue in DRM 3.4.9.1169

Hi,

Could you check if the issue persist if you remove R730 or any 13G server out from the list. Only add 14G and above. Or try just adding a few server eg: R760 and R750 to test the export. 

Same issue with R760s

Hi,

You mentioned you do this quarterly, meaning you have not used DRM recently? Or it's only had issues with Smart bootable ISO only recently on updated 3.4.9 version? Just to confirm, you only selected repository for Linux bundles only right (I did notice only 1 file .BIN)? What is the current plug-in version? 

I used DRM recently with all last 3 versions (3.4.9, 3.4.8, 3.4.7) to resolve my issue but it is not creating smart bootable iso, there is same issue with all versions  

Yes right, selected repository for Linux bundles

Hi,

Based on the details you've shared about the Smart Bootable ISO failures in Dell Repository Manager (DRM) across multiple server models and DRM versions (3.4.9/3.4.8/3.4.7), here's a structured troubleshooting plan:

Critical First Step: Verify Plugin Version

 Navigate to:
DRM → Help → About → Check Plugin Version
(Please share this detail, as it’s essential for diagnosis)

 Action Plan:

1. Update/Validate Plugins

   • Go to Tools → Manage Plugins → Ensure latest server plugins for R760/R750 exist
   • Download new plugins from Dell’s Plugin Portal if outdated

2. Test with Minimal Configuration

   • Create a new repository with only:
     • 1 server model (e.g., R760)
     • 1 OS bundle (Linux/Windows)
   • Re-download the bundle to rule out corruption

3. Check Logs for Errors
   Location: C:\Users\[YourUser]\AppData\Roaming\Dell\DELLRepositoryManager\Logs
   Focus on:

   • ExportService.log
   • SmartBootableISO.log
     (Look for "failed to generate", "missing component", or "unsupported platform")

4. Environment Checks

   • Free up >20GB free space on export drive
   • Ensure .NET Framework 4.8 is installed
   • Run DRM as Administrator (right-click → "Run as administrator")

Workarounds:

• Manual ISO Creation:
  1. Export as Classic (non-Smart) ISO
  2. Use Rufus or Ventoy to make it bootable
• Alternative Tool: Try Dell OS Deployment Pack

 If Issue Persists:

• Full DRM Reset:
  1. Uninstall via Control Panel
  2. Delete residual folders:
     • C:\Program Files\Dell\DELLRepositoryManager
     • C:\Users\[YourUser]\AppData\Roaming\Dell\DELLRepositoryManager
  3. Reinstall latest DRM
• Contact Dell Support: Share logs + plugin version via Enterprise Support Portal

💡 Pro Tip:

Split 13G (R730) and 14G+ (R760/R750) servers into separate repositories to avoid compatibility conflicts.

Let me know your plugin version or any error codes from logs—I’ll help decode them!

Experiencing this exact same issue, have been troubleshooting it for the past couple of days without a solution.

I have reinstalled DRM, updated and verified the plugins. (running version 954)

Tried making a repository for just R640, this did not work either.

It fails creating at 5% with only this showing up in the logs, no clear reason for failing:

2026-01-20T11:24:56 : Downloading 1 files

2026-01-20T11:24:58 : Copied from store: FOLDER13981536M/1/invcol_LN64_K4KWG_25_12_00_37_A00.BIN

Here are a few steps and considerations to help you troubleshoot further:

1. Check Network and Storage Access
The log mentions "Copied from store," which might indicate a network share or local repository issue. Ensure that the storage location (whether local or network) has sufficient permissions and free space.
If you’re using a network path, try mapping the drive or using a UNC path with proper credentials.
2. Corrupted File or Repository
Even though you created a repository for just the R640, the specific file invcol_LN64_K4KWG_25_12_00_37_A00.BIN might be corrupt in the source. Try manually downloading that file from Dell's support site and replacing it in your repository.
Alternatively, try creating a new repository from scratch (with a different name/location) to rule out repository corruption.
3. DRM Version and Compatibility
You mentioned running version 954. Check if there’s a newer version of DRM available, as this might include fixes for known issues.
Also, ensure that your OS (Windows/Linux) and Java (if applicable) are up to date and compatible with DRM 954.
4. Antivirus or Firewall Interference
Sometimes security software can interfere with file operations. Temporarily disable your antivirus/firewall and see if the process completes. If it does, add an exception for DRM and its repository folders.
5. Check for Hidden Logs
DRM might have more detailed logs elsewhere. Look in:
%ProgramData%\Dell\DELL Repository Manager\Logs (on Windows)
Or the installation directory for additional log files.
Enable debug or verbose logging in DRM if possible (check settings or command-line options).
6. Test with a Different File or Component
If possible, try creating a repository with a different component (e.g., a different firmware or driver) to see if the issue is isolated to that specific BIN file or more widespread.

@Dell-Martin S​ Sorry i wasn't fully clear.

Im using DRM Version: 3.4.9.1169

Dell Bootable ISO Plug-in version 954

Not being able to make a bootable USB has only been a problem when using Enterprise Servers Catalog 25.12.22 and every Catalog released since then.
When i revert back to a catalog before this date im able to create the bootable iso without issue.

This also does not seem to be related to which systems i select, or components i select.

I have tried making a bootable ISO for different seperate systems, for the full catalog, changing export locations, all with the same result.

The only differences between successfully creating a Bootable ISO and it failing appears to be the Catalog i select.

thx for letting us this point know please update us fwhen you test the other points too

@Dell-Martin S​ I checked the following points as well.
Check Network and Storage Access: i assured i have full permission and sufficient space. (hence why using catalogs before a certain date works flawless)

Corrupted File or Repository: I've recreated multiple repositories with different names and locations, all with the same issue. When i use Enterprise Servers Catalog 25.12.22 or any newer version it fails. When i use a catalog before this date it succeeds.

DRM Version and Compatibility: Im using the latest available version of DRM, newest version of the Smart bootable iso plug-in, using an up to date version of windows 11 and finally updated my Java version to the latest one.

Antivirus or Firewall Interference: This does not appear to be the issue, im still able to create a bootable iso using previous catalog versions.

Check for Hidden Logs: I've managed to find log files in ProgramData\Dell\drm\log but these have the same information im able to find in DRM itself. Information like this: 

2026-01-20T14:36:04 : Downloading 1 files

2026-01-20T14:36:05 : Copied from store: FOLDER13981536M/1/invcol_LN64_K4KWG_25_12_00_37_A00.BIN

Test with a Different File or Component: I've tried this as well, when i use Enterprise Servers Catalog 25.12.22 or above it does not matter which system or component i select. I've tried this with R630, R640, R650, R760. All without success.

I mainly notice that no matter which components, or system i select it's always the same file that shows up in the logs: invcol_LN64_K4KWG_25_12_00_37_A00.BIN

Satdev,

I believe the underlying issue is there is something non-Linux being introduced.

A Smart Bootable ISO can only be created with Linux based bundles. So just to confirm, I would rebuild the repository using only Linux DUP bundles, so inside DRM:

Create a new repository
Select only Linux OS bundles
De-select Windows, ESXi, and any other OS bundles
Ensure bundles appear as .BIN Linux DUPs

This should produce a valid Smart Bootable ISO.

Let me know if this helps.

@DELL-Chris H ​ Im running into the same issue Satdev is experiencing. Creating a Bootable ISO still works when i use any catalog before Enterprise Servers Catalog 25.12.22
When i use a this specific catalog or version released at a later date creating the Bootable ISO fails.
In both cases i indeed select Linux as the operating system like this:

I just finished looking into the issue, and it looks like there is indeed currently an issue with the newer catalogs, and it is in the works to resolve it. In the meantime I am suggesting that you use an older catalog, at least Dec 15th or earlier.