Can I delete CUDA on AMD?

Hi, thanks for creating this awesome os!
I installed the garuda linux KDE (ultimate edition, I think?) on my Laptop about a month ago, it doesn't have much disk space however, so I decided to explore what took the most space on my system. I found that while I was on AMD, the folder /opt/cuda was taking many gigabytes of space. I have not installed cuda myself and have not used it for anything, as I have a AMD processor with only integrated graphics.
Is CUDA used by the os for AMD as well, or something similar?
Can I safely delete this folder and if I can, what would be the best way?

Thanks in advance!

Some system info:
Host: 81X2 IdeaPad Flex 5 14ARE05
Kernel: 5.8.10-zen1-1-zen
Uptime: 18 mins
Packages: 2102 (pacman)
Shell: zsh 5.8
Resolution: 1920x1080
DE: Plasma 5.19.5
WM: KWin
WM Theme: WhiteSur-dark
Theme: WhiteSurDark [Plasma], Breeze [GTK3]
Icons: Tela-circle-dark [Plasma], Tela-circle-dark [GTK2/3]
Terminal: konsole
Terminal Font: Source Code Pro 10
CPU: AMD Ryzen 3 4300U with Radeon Graphics (4) @ 2.700GHz
GPU: AMD ATI 04:00.0 Renoir
Memory: 3550MiB / 7383MiB

I dont think we install cuda by default

So i doubt you might have installed it while installing blender as cuda is an opt dep ?

You can remove cuda with

sudo pacman -Rnsc cuda

Thanks, nothing crashed yet :smiley: .
However, while the folder is gone, no space was freed. Could this be caused by how the BRTFS filesystem works?

Press F5 in Dolphin file browser.

Thanks, but something else is going on... The old free-space amount is reported by dolphin, df . -h and the default terminal widget thing :thinking:

sudo btrfs filesystem usage /
df -h

Yep, still the same 1,53 GiB:

    Device size:                  76.99GiB
    Device allocated:             76.99GiB
    Device unallocated:            1.00MiB
    Device missing:                  0.00B
    Used:                         74.82GiB
    Free (estimated):              1.53GiB      (min: 1.53GiB)
    Data ratio:                       1.00
    Metadata ratio:                   1.00
    Global reserve:              180.66MiB      (used: 0.00B)
    Multiple profiles:                  no

Data,single: Size:73.97GiB, Used:72.44GiB (97.93%)
   /dev/nvme0n1p6         73.97GiB

Metadata,single: Size:3.01GiB, Used:2.38GiB (79.16%)
   /dev/nvme0n1p6          3.01GiB

System,single: Size:4.00MiB, Used:16.00KiB (0.39%)
   /dev/nvme0n1p6          4.00MiB

   /dev/nvme0n1p6          1.00MiB

Maybe, like everytime, KDE need a reboot :thinking:

Let's find out :slight_smile:

Nope, didn't change anything :thinking:

The hard drive is really quite full, can you part with things?
List of biggest 10 files

find ~/ -type f -print0 | xargs -0 du -s | sort -n | tail -25 | cut -f2 | xargs -I{} du -sh {}

In garuda welcome

Maintenance tab

Click on clear cache, clear pkg cache

In btrfs tab

Click defragment then click balance


Nothing too big, biggest was a random cache file at 1.2GiB, also found some yay cache files that I could get rid of. After those the sizes of the items in the list basically drop to max 100M.

If there was CUDA with 6 GB on it before, the allocation would have been 82 GB on a hard disk with 76 GB

I will try this as well

Maybe those files are still ghosting somewhere?

Clean it like @librewish said ähm, wrote :wink:

OK, so the window manager and KDE crashed mid defragmentation as the diskspace dropped suddenly to zero. I managed to find a partially covered terminal and delete the biggest files from there... Kwin restarted, but KDE remains dead. Can I restart it without logging out? The defragmentation failed as well as it had no space to work with. @SGS

Ok, I got kde working again properly. It seems that defragmenting eats space really fast, which is kinda problematic at the moment because it won't be able to run for very long before it has no room to do it thing anymore. I will be trying to clean up as much as I can before trying to run it.

If you have crashes happening your logs could be getting very large in size. Does Garuda cap the log size by default @librewish.

If not, limiting your log size is always a good space saving strategy.