Something new that I have discovered playing with 2 nvme xmas presents.

Fresh install 15.3 with MATE desktop - UEFI with 500mb boot/efi (fat16), 32gb swap the remainder a single ext4 / . Everything works fine after installing packman and doing a zypper up.

If I use gparted from the live 15.3 usb to shrink the partition to allow Windows 11 install, the same apps have the 30 second delay as reported earlier.

Leafpad, VLC , and Oracle VM Virtualbox manager all have a 30 second delay - have not tried any other apps as they are things I use every day.

What is the cause for the delay? It is the same as if I used fsarchiver, or backup and restore with my tar backup scripts.

The sum -r of every boot bin etc sbin usr and var (except logs) are identical.

Is there some hidden thing written in a predefined sector that they are looking for that got moved.

Free memory is 11gb - I hope you see something that appeared - I hit alt-f4 as soon as it opened. Leafpad is the smallest of the slow programs.

LLR1 is the slow and VM1 is normal speed.

llrainey@LLR1:~> time perf record leafpad
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (1025 samples) ]

real    0m29.866s
user    0m0.252s
sys     0m0.148s

llrainey@LLR1:~>perf report > zlog
#
llrainey@VM1:~>

On 10/19/21 6:31 PM, Aaron Puchert wrote:

Am 20.10.21 um 00:01 schrieb Larry Len Rainey:

I have posted in the forum for help but have not gotten anything that helped - I would love to find a way to see why. I know this is not the right way but I hope someone has an idea why and or how to find the problem and fix it.

First of all, does it consume CPU in those 30 seconds or not?

* If it does, you could try some profiling with "perf". (From the package of the same name.) So run e.g. "perf record vlc", then close VLC after it has started. Then run "perf report" to get an idea where the most time is spent.

* More likely it doesn't and instead waits. That's a bit more difficult but not insurmountable. Install bcc-tools and kernel-devel, then run "sudo /usr/share/bcc/tools/offcputime -p $PID", where $PID is the pid of the relevant process. (The script might be slow to start. If that's the case, run without "-p $PID" and instead filter the stacks after the fact for vlc or whatever program you're running.)

Then paste the results here, just the top symbols for perf or the bottom results for offcputime (the longest waits come last) or open a bug right away if you think you know the culprit.

In fact opening a bug report isn't the worst idea, even if you don't have any idea what component is at fault.

Possibly it's some mutexes though, i.e. user space waiting for user space, which could get a bit harder.

Best regards,
Aaron