bubbl3

Fixed in 6.12.9

Issue is resolved for me with the fix in 6.12.9: root@Tower:~# grep -c ^processor /proc/cpuinfo 128 Thanks everyone

That's not what I asked, can you try to boot a different USB drive with a different OS?

Ok, but what about now, does another bootable usb boot automatically?

Did you try another bootable USB? Like another drive and/or another OS, or both at the same time. Just to make sure it's a bios issue.

Recommended steps if you have the ability to get another drive: Take disk out of the server and keep in safe space Install new 6TB drive and follow rebuild process If rebuild successful proceed RMA faulty drive When drive comes back from RMA, keep it as spare

Believe the SOLVED label should be removed from this report :D

He run the one you need too:

model name : AMD EPYC 7V12 64-Core Processor SMT disabled: root@Tower:~# grep -c ^processor /proc/cpuinfo 64 SMT enabled: root@Tower:~# grep -c ^processor /proc/cpuinfo 128

That's what I'm wondering, will ask Synd to share his diagnostics later when he's online.

The puzzling thing is that according to the conversation we were having yesterday this is not affecting everyone with 64 cores / 128 threads CPUs, which makes me think the high core count is just one of the factors.

For sake of completion, disabling SMT seems to be a better workaround if that's an option in your setup: https://forums.unraid.net/bug-reports/stable-releases/6128-no-webgui-run-full-r2854/?do=findComment&comment=27345

@AppleJon disabling SMT indeed solved the issue, but seems to be a mitigation as 75% usage of /run is still abnormal: /run/udev/data still taking way too much space: Now wondering why other Threadripper/EPYC users with similar core counts are not affected.

Looks stable at around 34MB, it only increases (few KB, nothing much) if i plug in a new device, like usb storage, etc. or if I run more docker containers.

I think the abnormal allocation under /run/udev/data is affecting everyone, it just doesn't fill the 32MB for people with lower core counts and lower pci-e lanes + associated devices. Please fix the allocation issue, must be a bug introduced with 6.12.8 as it wasn't happening in 6.12.6, or give us a way to increase the size of /run that is not a line in the go file as there are services failing before that runs and it's messy and potentially unstable to fix it that way. Atm only 2 users reported it, but i bet since the release was on Friday, many high core count and pci-e lanes users did not upgrade yet, for sure there are many that I know of on Discord with similar systems which are gonna have the same issue. TLDR: if you're one of those users, do not upgrade yet

Thanks, but this is not a solution, just a workaround. Would also suggest you to check your syslog after the change as you may also have DBUS failing (it starts before the GO file), which will cause all sort of underlaying issues: At least this confirms why the bug is affecting us, you're on a 64 cores Threadripper and I'm on a 64 cores EPYC, we have more devices creating UDEV files than others, I bet their /run/udev is probably abnormally big as well even if it doesn't affect them.

Also look here, all 0 bytes files in /run/udev/data are using 4KB:

That is correct, most of the files are 0 bytes and the total data that can be read from them is 512KB (confirmed by the output of tree --du -h -a /run > run.txt , attached here) , that said the block size is 4KB so every file will consume that amount of space on the partition. If you multiply the number of files for the minimum allocation you get a rough idea of why so much space is being taken: 9843 x 4 = 39372 If I learned anything in my years of working with file systems is that disk usage with small files gets often out of hand due to the default block size, NCDU is actually great for this, with tree or df you would be chasing ghosts as they just list the actual size. This also doesn't happen with 6.12.6, so it must be some change made between that and 6.12.8 run.txt

Bunch of 4KB files in there, weird:

Looks like udev is taking all the space:

root@Tower:/# ls -la /run/ total 80 drwxr-xr-x 19 root root 1040 Feb 17 17:59 ./ drwxr-xr-x 21 root root 460 Feb 17 14:55 ../ -rw-r--r-- 1 root root 0 Feb 17 14:52 acpid.pid srw-rw-rw- 1 root root 0 Feb 17 14:52 acpid.socket= -rw------- 1 root root 0 Feb 17 14:53 agetty.reload -rw-r--r-- 1 root root 6 Feb 17 14:53 apcupsd.pid -rw-r--r-- 1 root root 0 Feb 17 14:52 atd.pid drwxr-xr-x 2 avahi avahi 80 Feb 17 14:54 avahi-daemon/ -rw-r--r-- 1 root root 6 Feb 17 14:54 avahi-dnsconfd.pid drwxr-xr-x 2 root root 80 Feb 17 14:55 blkid/ drw------- 3 root root 60 Feb 17 14:54 containerd/ drwxr-xr-x 2 root root 40 Feb 17 14:52 cron/ drwx------ 2 root root 40 Feb 17 14:53 cryptsetup/ drwxr-xr-x 2 root root 80 Feb 17 14:53 dbus/ drwx------ 8 root root 180 Feb 17 14:54 docker/ srw-rw---- 1 root docker 0 Feb 17 14:54 docker.sock= -rw-r--r-- 1 root root 5 Feb 17 14:54 dockerd.pid drwxr-xr-x 8 root root 160 Feb 17 14:54 elogind/ -rw-r--r-- 1 root root 6 Feb 17 14:53 elogind.pid srw-rw-rw- 1 root root 0 Feb 17 14:53 emhttpd.socket= drwxr-xr-x 2 root root 40 Feb 17 14:52 faillock/ -rw-r--r-- 1 root root 6 Feb 17 14:53 inetd.pid drwxr-xr-x 12 root root 440 Feb 17 14:54 libvirt/ drwxr-xr-x 4 root root 80 Feb 17 14:52 lock/ drwx------ 2 root root 40 Feb 17 14:52 lvm/ drwxr-xr-x 2 root root 40 Feb 17 14:51 mount/ -rw-r--r-- 1 root root 216 Feb 17 17:30 nchan.pid -rw-r--r-- 1 root root 6 Feb 17 14:53 nginx.pid srw-rw-rw- 1 root root 0 Feb 17 14:53 nginx.socket= -rw-r--r-- 1 root root 0 Feb 17 14:52 ntpd.pid -rw-r--r-- 1 root root 5 Feb 17 14:53 php-fpm.pid srw-rw---- 1 root users 0 Feb 17 14:53 php5-fpm.sock= -rw------- 1 root root 25 Feb 17 14:53 qga.state -rw-r--r-- 1 rpc rpc 6 Feb 17 14:53 rpc.statd.pid drwxr-x--- 2 rpc root 40 Feb 17 14:53 rpcbind/ -r--r--r-- 1 root root 0 Feb 17 14:53 rpcbind.lock srw-rw-rw- 1 root root 0 Feb 17 14:53 rpcbind.sock= -rw-r--r-- 1 root root 5 Feb 17 14:54 rsyslogd.pid -rw-r--r-- 1 root root 1 Feb 17 14:52 runlevel drwxr-xr-x 4 root root 80 Feb 17 14:52 samba/ -rw-r--r-- 1 root root 6 Feb 17 17:58 samba-dcerpcd.pid -rw------- 1 root root 6 Feb 17 14:53 sm-notify.pid -rw-r--r-- 1 root root 6 Feb 17 14:54 smbd.pid -rw-r--r-- 1 root root 6 Feb 17 14:53 sshd.pid -rw-r--r-- 1 root root 5 Feb 17 14:54 syslogd.pid lrwxrwxrwx 1 root root 7 Feb 17 14:52 systemd -> elogind/ drwxr-xr-x 8 root root 180 Feb 17 16:56 udev/ srwxr-xr-x 1 root root 0 Feb 17 14:53 unraid-api.sock= drwxr-xr-x 3 root root 60 Feb 17 14:55 user/ -rw-rw-r-- 1 root utmp 4224 Feb 17 14:55 utmp -rw-r--r-- 1 root root 6 Feb 17 14:54 winbindd.pid -rw------- 1 root root 0 Feb 17 14:52 xtables.lock

I agree, but since the upgrade to 6.12.8 the 32MB of the /run mount are not enough and there's no other way to increase it, if I don't do that many services won't start, not to mention i have to manually start dbus as it runs before the go file and fails to create a .pid. Have a thread open but no help so far 🤷‍♂️

That worked 👍

root@Tower:/etc/samba/unassigned-shares# cat /etc/samba/unassigned-shares/ZCH0859H.conf [ZCH0859H] comment = ZCH0859H path = /mnt/disks/ZCH0859H browseable = yes valid users = emanuele write list = emanuele vfs objects = catia fruit streams_xattr fruit:encoding = native case sensitive = auto preserve case = yes short preserve case = yes [global] root@Tower:/etc/samba/unassigned-shares# cat /etc/samba/smb-unassigned.conf include = /etc/samba/unassigned-shares/ZCH0859H.conf