Does anyone know how I can get a DGX Spark OS ISO File?
Download the install media here: DGX Spark for AI Developers - Get Started | NVIDIA Developer
Follow the re-flashing guide here: System Recovery â DGX Spark User Guide
I want to enable full disk LUKS, doesnât let me do that in the system recovery
Is there a way I can do a full disk encryption?
Disk encryption is done via the UEFI Bios Menu. From the Main Menu âselectâ the Security Tab. Once in the Security tab use the down arrow and look for TCG Storage Security Configuration. You will see the internal Disk. Highlight the disk and âselectâ enter. You will see several options to secure the disk - setting the Admin Password will encrypt the drive.
You will need to register an enterprise account, then download the :DGXOS-7.2.3-2025-10-04-06-28-28-arm64.iso(see link below). Select Advanced options and encrypt root file system for DGX Spark.
We use Clevis and the integrated TPM.
#install needed packages
apt-get -y install clevis clevis-tpm2 clevis-luks clevis-initramfs initramfs-tools tss2 tpm2-tools
#Take ownership of TPM
tpm2_clear
#proceed
echo -n Enter LUKS password:
read -s LUKSKEY
echo ââ
#If you want some security behind your tpm
#This will set up the clevis key on the luks slot after the one you have already set up (which is slot 0).
#You can list these with cryptsetup luksDump /dev/nvme0n1p3
#The pcr_idâs show how secure you want your tpm2 setup to be, or you can test by omitting this part completely.
#See PCR choices below.
clevis luks bind -d /dev/nvme0n1p3 tpm2 â{âpcr_bankâ:âsha256â, âpcr_idsâ:â1,7â}â <<< â$LUKSKEYâ
update-initramfs -u -k all
#check
clevis luks list -d /dev/nvme0n1p3
#delete example; -s is one of the slots reported by the previous command
#clevis luks unbind -d /dev/nvme0n1p3 -s 1 tpm2
https://enterprise-support.nvidia.com/s/announcement/a4zVv000000DqDh/nvidia-dgx-os-72-release
Is this the simple answer to encryption at rest?
I wonder if a NVidia employee can write a guide explicitly for enabling encryption at rest, and for assuring us that our IP wonât be at risk if the unit is stolen. In this guide perhaps you could help us understand exactly how the setting affects security and how it works. Also can you confirm if entering the admin password will reset the device or not (and we lose our work)?
At the risk of being too demanding, I wonder if you can you comment if sdahlâs response is correct or incorrect or simply a different approach?
PCR Choices
Each PCR bank contains a hash for a different system component. Itâs basically a setting of how much trust the TPM should have about the system.
Copying from the man of systemd-cryptenroll
| PCR | name | Explanation |
|---|---|---|
| 0 | platform-code | Core system firmware executable code; changes on firmware updates |
| 1 | platform-config | Core system firmware data/host platform configuration; typically contains serial and model numbers, changes on basic hardware/CPU/RAM replacements |
| 2 | external-code | Extended or pluggable executable code; includes option ROMs on pluggable hardware |
| 3 | external-config | Extended or pluggable firmware data; includes information about pluggable hardware |
| 4 | boot-loader-code | Boot loader and additional drivers, PE binaries invoked by the boot loader; changes on boot loader updates. sd-stub(7) measures system extension images read from the ESP here too (see systemd-sysext(8) ). |
| 5 | boot-loader-config | GPT/Partition table; changes when the partitions are added, modified, or removed |
| 7 | secure-boot-policy | Secure Boot state; changes when UEFI SecureBoot mode is enabled/disabled, or firmware certificates (PK, KEK, db, dbx, âŚ) changes. |
| 9 | kernel-initrd | The Linux kernel measures all initrds it receives into this PCR. |
| 10 | ima | The IMA project measures its runtime state into this PCR. |
| 11 | kernel-boot | systemd-stub(7) measures the ELF kernel image, embedded initrd and other payload of the PE image it is placed in into this PCR. systemd-pcrphase.service(8) measures boot phase strings into this PCR at various milestones of the boot process. |
| 12 | kernel-config | systemd-boot(7) measures the kernel command line into this PCR. systemd-stub(7) measures any manually specified kernel command line (i.e. a kernel command line that overrides the one embedded in the unified PE image) and loaded credentials into this PCR. |
| 13 | sysexts | systemd-stub(7) measures any systemd-sysext(8) images it passes to the booted kernel into this PCR. |
| 14 | shim-policy | The shim project measures its âMOKâ certificates and hashes into this PCR. |
| 15 | system-identity | systemd-cryptsetup(8) optionally measures the volume key of activated LUKS volumes into this PCR. systemd-pcrmachine.service(8) measures the machine-id(5) into this PCR. systemd-pcrfs@.service(8) measures mount points, file system UUIDs, labels, partition UUIDs of the root and /var/ filesystems into this PCR. |
| 16 | debug | Debug |
| 23 | application-support | Application Support |
The PCRâs you select is a balance between security and annoyance. The more PCR banks used, the more likely an auto-unlock will fail.
Banks 1 and 7 are commonly chosen, and is what Windows bitlocker uses. Using only these prevents breaking auto-unlock by allowing most of the firmware and the bootloader to be updated (as long as the bootloader is signed by a UEFI key). If either the UEFI verification key changes, UEFI verification is disabled, or major hardware components are swapped, then the TPM will refuse to decrypt the LUKS container. This is a good balance between security and convince.
A more extreme configuration is to also require bank 4, to ensure that downgrading the bootloader to a buggy version will also not boot.
If concerns about security or IP, using TPM unlock lowers the bar, but you can use more PCRâs to to limit conditions on default unlock. Of course the 1st is changing the default passphrase - sudo cryptsetup luksChangeKey /dev/nvme0n1p3
ASUS posted iso image for their dgx spark version ASUS Ascent GX10ď˝Desktop AI supercomputerď˝ASUS Canada
Thank you! I was looking for this. I got the 1TB drive so that I could upgrade to 2TB and was going to lean on that as a failsafe (along with Veeam image backups to a USB-C connected SSD) but of course an SSD sitting on a shelf is not going to be super-reliable in avoiding bit rot. I could have also image the disk but having a fresh install ISO is much better.
@dkostakoff have you actually put this on a usb stick and tried to boot it? Iâve tried using ubuntuâs âDisksâ app and ubuntuâs âStartup Disk Creatorâ app and neither produces a viable result. My GX10 doesnât recognize the result as either bootable or a valid recovery image.
For whatever reason, ASUS has the ISO and the respective md5sum file in a compressed tar archive, which they then pack into the ZIP file posted for download.
If you didnât extract the ~9GB ISO file completely out of the archive, and just tried to âburnâ the ZIP or the tar.gz file to a USB key, that likely wonât produce a bootable USB.
For installation via ventoy, I tried to create iso from nvidiaâs official recovery image but their kernel is not included iso9660 support, so I just made img format.
Iâm using GX10 too and installed & works well now.
I created bootable usb drive through balenaEtcher on my Mac and it works.
But you should know, when boot usb loaded, no way to cancel DGX OS reinstallation.
So in order to answer your question I wiped my dgx spark đ
@dkostakoff Thanks, I was wondering about that. Just to be clear: if you use the full iso image, not the recovery image, when it boots it doesnât give you any options and immediately starts wiping the SSD and installs a virgin system? So thereâs no way to even crudely check it out without wiping out the system? So unless you are installing a new system, you should probably use the recovery image/process instead of the iso. Did you happen to check what it said under âOS Recovery Drive Validationâ for the USB with the ISO image?
@FlossingEnthusiast Thanks, I was aware of that. Seems rather strange.