df- h reports
Filesystem Size Used Avail Use% Mounted on
efivarfs 256K 252K 0 100% /sys/firmware/efi/efivars
If I need to cull this directory is there any guidance?
I don’t think I can enlarge this partition as it is at the start of the disk… and was setup by the Garuda Installer…
Delete some of the old/unused ones from your BIOS. They can accumulate.
If present, for sure you should delete the dump files /sys/firmware/efi/efivars/dump-*.
And, please, always provide your garuda-inxi, as required in the topic template.
E.g. do you dual/multiple boot? If so, make sure to delete old unused bootloaders.
Thank you for jogging my memory!
Had a problem with debian12 and ran efibootmgr revealing 16 old entries (including old irrelevant windows bootloaders).
I have a dual boot with Garuda KDE lite on a 2TB nvme and ARCH LTS in a 3TB HDD (which I use for testing and maitenance/backups etc.)
This is the current list:
I am running in Boot0000*
Boot0003*, Boot0007*, Boot0008*,Boot0008*,Boot0014* all appear to point to the ARCH LTS drive.
I think Boot0008* is the only one I created. The others are automatic from the Dell OptiPlex 7040 bios.
Garuda is running beautifully and I really don’t want to run into boot issues as this is a preventative issue.
NOTE: The Garuda Grub does not properly boot the ARCH LTS so I do that via f12 at startup. This might fix that too?
Appreciate any assistance before I break a beautiful set up.
Filo: Apologies, I didn’t think the question warranted the inxi as the efivars issue is not causing any errors or problems, but might!.
I just thought it can’t be good to overflow that directory.
inxi -Fxxxza
System:
Kernel: 6.7.3-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
clocksource: tsc available: hpet,acpi_pm
parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
root=UUID=799058ae-c22b-4474-a408-c7b9c71279cd rw rootflags=subvol=@
quiet loglevel=3 ibt=off
Desktop: KDE Plasma v: 5.27.10 tk: Qt v: 5.15.12 wm: kwin_x11 vt: 2
dm: SDDM Distro: Garuda Linux base: Arch Linux
Machine:
Type: Desktop System: Dell product: OptiPlex 7040 v: N/A
serial: <superuser required> Chassis: type: 3 serial: <superuser required>
Mobo: Dell model: 0HD5W2 v: A00 serial: <superuser required> UEFI: Dell
v: 1.24.0 date: 07/14/2022
CPU:
Info: model: Intel Core i5-6500 bits: 64 type: MCP arch: Skylake-S
gen: core 6 level: v3 note: check built: 2015 process: Intel 14nm family: 6
model-id: 0x5E (94) stepping: 3 microcode: 0xF0
Topology: cpus: 1x cores: 4 smt: <unsupported> cache: L1: 256 KiB
desc: d-4x32 KiB; i-4x32 KiB L2: 1024 KiB desc: 4x256 KiB L3: 6 MiB
desc: 1x6 MiB
Speed (MHz): avg: 800 min/max: 800/3600 scaling: driver: intel_pstate
governor: powersave cores: 1: 800 2: 800 3: 800 4: 800 bogomips: 25599
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Vulnerabilities:
Type: gather_data_sampling status: Vulnerable: No microcode
Type: itlb_multihit status: KVM: VMX disabled
Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT
disabled
Type: mds mitigation: Clear CPU buffers; SMT disabled
Type: meltdown mitigation: PTI
Type: mmio_stale_data mitigation: Clear CPU buffers; SMT disabled
Type: retbleed mitigation: IBRS
Type: spec_rstack_overflow status: Not affected
Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via
prctl
Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
sanitization
Type: spectre_v2 mitigation: IBRS, IBPB: conditional, STIBP: disabled,
RSB filling, PBRSB-eIBRS: Not affected
Type: srbds mitigation: Microcode
Type: tsx_async_abort mitigation: TSX disabled
Graphics:
Device-1: Intel HD Graphics 530 vendor: Dell driver: i915 v: kernel
arch: Gen-9 process: Intel 14n built: 2015-16 ports:
active: HDMI-A-1,HDMI-A-3 empty: DP-1, DP-2, DP-3, HDMI-A-2
bus-ID: 00:02.0 chip-ID: 8086:1912 class-ID: 0300
Display: x11 server: X.org v: 1.21.1.11 compositor: kwin_x11 driver: X:
loaded: modesetting alternate: fbdev,intel,vesa dri: iris gpu: i915
display-ID: :0 note: <missing: xdpyinfo/xrandr>
Monitor-1: HDMI-A-1 model: Acer V227Q serial: <filter> built: 2021
res: 1920x1080 dpi: 102 gamma: 1.2 size: 476x268mm (18.74x10.55")
diag: 546mm (21.5") ratio: 16:9 modes: max: 1920x1080 min: 720x400
Monitor-2: HDMI-A-3 model: LG (GoldStar) 23MP75 built: 2014 res: 1920x1080
dpi: 96 gamma: 1.2 size: 510x290mm (20.08x11.42") diag: 587mm (23.1")
ratio: 16:9 modes: max: 1920x1080 min: 640x480
API: Vulkan v: 1.3.276 layers: 3 device: 0 type: integrated-gpu name: Intel
HD Graphics 530 (SKL GT2) driver: mesa intel v: 23.3.5-arch1.1
device-ID: 8086:1912 surfaces: xcb,xlib device: 1 type: cpu name: llvmpipe
(LLVM 16.0.6 256 bits) driver: mesa llvmpipe v: 23.3.5-arch1.1 (LLVM
16.0.6) device-ID: 10005:0000 surfaces: xcb,xlib
API: OpenGL Message: Unable to show GL data. glxinfo is missing.
Audio:
Device-1: Intel 100 Series/C230 Series Family HD Audio vendor: Dell
driver: snd_hda_intel v: kernel alternate: snd_soc_avs bus-ID: 00:1f.3
chip-ID: 8086:a170 class-ID: 0403
API: ALSA v: k6.7.3-zen1-1-zen status: kernel-api tools: N/A
Server-1: PipeWire v: 1.0.3 status: active with: 1: pipewire-pulse
status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli,wpctl
Network:
Device-1: Intel Ethernet I219-LM vendor: Dell driver: e1000e v: kernel
port: N/A bus-ID: 00:1f.6 chip-ID: 8086:15b7 class-ID: 0200
IF: enp0s31f6 state: up speed: 1000 Mbps duplex: full mac: <filter>
Device-2: ASIX AX88179 Gigabit Ethernet driver: ax88179_178a type: USB
rev: 3.0 speed: 5 Gb/s lanes: 1 mode: 3.2 gen-1x1 bus-ID: 2-3:2
chip-ID: 0b95:1790 class-ID: ff00 serial: <filter>
IF: enp0s20f0u3 state: up speed: 1000 Mbps duplex: full mac: <filter>
IF-ID-1: nordlynx state: unknown speed: N/A duplex: N/A mac: N/A
IF-ID-2: virbr0 state: down mac: <filter>
Drives:
Local Storage: total: 7.28 TiB used: 1.45 TiB (20.0%)
SMART Message: Required tool smartctl not installed. Check --recommends
ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Kingston model: SNV2S2000G
size: 1.82 TiB block-size: physical: 512 B logical: 512 B speed: 63.2 Gb/s
lanes: 4 tech: SSD serial: <filter> fw-rev: SBM02103 temp: 36.9 C
scheme: GPT
ID-2: /dev/sda maj-min: 8:0 vendor: Seagate model: ST3000DM001-9YN166
size: 2.73 TiB block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s
tech: HDD rpm: 7200 serial: <filter> fw-rev: CC4B scheme: GPT
ID-3: /dev/sdb maj-min: 8:16 vendor: Western Digital
model: WD30EZRZ-00WN9B0 size: 2.73 TiB block-size: physical: 4096 B
logical: 512 B speed: 3.0 Gb/s tech: HDD rpm: 5400 serial: <filter>
fw-rev: 0A80 scheme: GPT
Partition:
ID-1: / raw-size: 1.31 TiB size: 1.31 TiB (100.00%) used: 678.26 GiB (50.6%)
fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
ID-2: /boot/efi raw-size: 300 MiB size: 299.4 MiB (99.80%)
used: 584 KiB (0.2%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
ID-3: /home raw-size: 1.31 TiB size: 1.31 TiB (100.00%)
used: 678.26 GiB (50.6%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
ID-4: /var/log raw-size: 1.31 TiB size: 1.31 TiB (100.00%)
used: 678.26 GiB (50.6%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
ID-5: /var/tmp raw-size: 1.31 TiB size: 1.31 TiB (100.00%)
used: 678.26 GiB (50.6%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
Swap:
Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default) zswap: no
ID-1: swap-1 type: zram size: 27.29 GiB used: 15.2 MiB (0.1%)
priority: 100 comp: zstd avail: lzo,lzo-rle,lz4,lz4hc,842 max-streams: 4
dev: /dev/zram0
Sensors:
System Temperatures: cpu: 34.0 C pch: 59.5 C mobo: N/A
Fan Speeds (rpm): N/A
Info:
Processes: 225 Uptime: 43m wakeups: 0 Memory: total: 28 GiB
available: 27.29 GiB used: 5.88 GiB (21.6%) Init: systemd v: 255
default: graphical tool: systemctl Compilers: gcc: 13.2.1 Packages:
pm: pacman pkgs: 1288 libs: 407 Shell: Bash v: 5.2.26 running-in: konsole
inxi: 3.3.31
Quite frankly, not having a very technical background and this being a very critical aspect, I don’t feel comfortable suggesting what to delete.
Most likely the problem is related to the existence of so many entries in efibootmgr.
I think you could delete one entry for each of the surely equal pairs (Boot0007/Boot0014, Boot0002/Boot0012, Boot0003/Boot0013, I’d say).
Furthermore, the BootOrder doesn’t go beyond 0009, so the later ones perhaps could be deleted.
Or maybe just wait for feedback from someone with more experience in these aspects… 
Great response!
As the machine is running really well I think I leave things alone and do more research on this potential problem.
It would be fantastic to get the Garuda Grub to properly boot the second ARCH LTS drive directly AND rehabilitate the efivars directory LOL
If present, for sure you should delete the dump files
/sys/firmware/efi/efivars/dump-*.
I don’t appear to have a /dump directory, though the file listing is really long !!!
Thank you for your insights!!!
Use garuda-boot-options
I have tried that but the issue is that I don’t seem to be able to edit the
/\EFI\BOOT\BOOTX64.EFI String
This is a nice to have feature but the underlying issue is What happens if the EFIVARS directory runs out of space? My guess is nothing good LOL
In my case (I have a laptop with Garuda and Arch), Arch didn’t want to show up in the os-prober until it was mounted before (now I have it in the fstab and everything runs smootly).
But your case is different. I use there a single disk with two partitions; you have separate disks, and I seem to remember that os-prober works only if the distro’s share the same EFI System Partition (and maybe you have one ESP in each disk).
For sure. See the warning here.
https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#Userspace_tools_are_unable_to_modify_UEFI_variable_data
In a different context, but:
bricking of machines when the NVRAM gets too full
That is correct both the nvme and the hdd have their own independant efi directories.
Yikes-
Thank goodness I run df -h when I back-up.
–reading your link now…
OK this is a bit over my head.
To be clear the current situation is that I have noticed that my efivars directory has grown to be essentially full (~1-2% available)
While not a problem NOW it appears it could become catastrophic?
This also very likely NOT a Garuda issue.
Any help will be appreciated.
NVRAM is on the motherboard and is likely only 256K and I’m guessing it is read into efivars. So with only 4K available in nvram I guess I need to reset it in the bios interface.
Hopefully I’ll be back to report success.
…And an update…
Wonders never cease!
I restarted in my Arch LTS HDD ran df- h which does not see the efivars directory
Updated Arch LTS and rebooted back into Garuda on SSD nmve.
Magically my efivars is down to 31% use so problem gone.
Arch LTS is on an EXT4 drive.
Garuda KDE-lite is on a BTRFS drive (which is new for me and I’m learning the FS)
Something to watch carefully i guess.
Will review resetting the BIOS to defaults but for now Loving Garuda and don’t want to break it.
Thank you all for helping me along with this.
It is not a problem. /sys/firmware is not a “real” filesystem, it is part of a RAM-based filesystem called sysfs . The sysfs filesystem provides information about devices and drivers in the kernel through virtual files, so certain device properties can be interacted with using “normal” file operations.
Since sysfs resides in memory, it is kind of a temporary structure that gets recreated fresh at every boot. There is no need to make it larger than whatever virtual files it needs to contain, so usually it appears to be full or nearly full.
NVRAM and EFI boot variables are not related to the sysfs virtual filesystem.
Thank You for this clarity!
Garuda Soars!
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.