Problem Description
rocm uninstall presents itself as removing what ROCm CLI put on the machine, but it leaves behind the two largest things ROCm CLI causes to be downloaded: the uv package cache and the model cache. A user who uninstalls to reclaim space can be left with tens of gigabytes still gone.
build_uninstall_plan (apps/rocm/src/main.rs:14877) removes binaries plus exactly three directories — the config, data, and cache dirs (apps/rocm/src/main.rs:14908-14924). Neither shared cache is inside any of them:
uv cache. uv_command_env() (crates/rocm-core/src/uv.rs:63-68) sets only UV_HTTP_TIMEOUT, never UV_CACHE_DIR, so every uv invocation writes to uv's default location under the user's home cache. (The companion issue on hardlink dedup proposes moving this inside the data directory, which would also bring it under uninstall's reach.)
- Model cache. Nothing in the product sets
HF_HOME — the only occurrences are a dash demo fixture, the end-to-end harness, and a standalone script. hf_cache_roots_from (engines/lemonade/src/lib.rs:1975-1994) only reads the environment for discovery and otherwise falls back to the shared default, so weights land outside anything ROCm CLI manages, reports, or removes.
The per-runtime pip cache is inside the runtime root and is surfaced by examine, so it is the one cache that uninstall does cover today.
Steps to Reproduce
- Install the SDK and serve a model, so both caches are populated.
- Run
rocm uninstall.
- The
uv cache and the downloaded model weights are still on disk, and nothing in the output mentions them.
Suggested Fix
At minimum, report them. The uninstall review already has a "Please review:" section — naming these paths and their sizes, and stating plainly that they are not being removed, would stop the command from implying a clean slate it does not deliver.
Beyond reporting, the two caches deserve different treatment:
- The
uv cache is shared with any other uv project on the machine and ROCm CLI never claimed it, so deleting it by default would slow down unrelated work. Removing it should be opt-in — or it should be relocated inside the data directory, after which it is covered for free.
- Model weights are large, slow to re-download, sometimes gated behind a token, and may include files the user fetched themselves. These should be reported with their location, not deleted.
Additional Information
Found while investigating unbounded disk growth.
Problem Description
rocm uninstallpresents itself as removing what ROCm CLI put on the machine, but it leaves behind the two largest things ROCm CLI causes to be downloaded: theuvpackage cache and the model cache. A user who uninstalls to reclaim space can be left with tens of gigabytes still gone.build_uninstall_plan(apps/rocm/src/main.rs:14877) removes binaries plus exactly three directories — the config, data, and cache dirs (apps/rocm/src/main.rs:14908-14924). Neither shared cache is inside any of them:uvcache.uv_command_env()(crates/rocm-core/src/uv.rs:63-68) sets onlyUV_HTTP_TIMEOUT, neverUV_CACHE_DIR, so everyuvinvocation writes touv's default location under the user's home cache. (The companion issue on hardlink dedup proposes moving this inside the data directory, which would also bring it under uninstall's reach.)HF_HOME— the only occurrences are a dash demo fixture, the end-to-end harness, and a standalone script.hf_cache_roots_from(engines/lemonade/src/lib.rs:1975-1994) only reads the environment for discovery and otherwise falls back to the shared default, so weights land outside anything ROCm CLI manages, reports, or removes.The per-runtime pip cache is inside the runtime root and is surfaced by
examine, so it is the one cache that uninstall does cover today.Steps to Reproduce
rocm uninstall.uvcache and the downloaded model weights are still on disk, and nothing in the output mentions them.Suggested Fix
At minimum, report them. The uninstall review already has a "Please review:" section — naming these paths and their sizes, and stating plainly that they are not being removed, would stop the command from implying a clean slate it does not deliver.
Beyond reporting, the two caches deserve different treatment:
uvcache is shared with any otheruvproject on the machine and ROCm CLI never claimed it, so deleting it by default would slow down unrelated work. Removing it should be opt-in — or it should be relocated inside the data directory, after which it is covered for free.Additional Information
Found while investigating unbounded disk growth.