Vitalio

There is easy way to determine build-id for the running kernel from `/sys/kernel/notes` which is detached `.notes` section of `vmlinux`. It exists since v2.6.23 (2007). For example, perf can show...

Btw, sorry for a slight off-topic, what do you think, should Linux show GNU build-ids on stack traces?

Thank you for answers!

Additional suggestion -- please try to use Address Sanitizer (ASan)[1][2] (for testing) -- which is present in both gcc and clang. It is as easy as add `-fsanitize=address` into `g++`...

Thanks for the reply. We can wait forever. ;)

I also confirm this on `gcc version 12.1.1 20220518` https://git.altlinux.org/beehive/logs/Sisyphus/x86_64/archive/2022/0602/error/simde-0.7.2-alt2 ``` [660/1748] Compiling C object test/x86/avx-native-c.p/avx.c.o In file included from ../test/x86/avx.c:25: ../simde/x86/avx.h: In function ‘simde_mm256_maskload_ps’: ../simde/x86/avx.h:4071:10: warning: ‘simde_mm256_loadu_ps’ reading 32...

And I was unable to replace `linux-generic` with `linux-virtual` using `Packages` syntax (nor with command line `-p`): ``` [Packages] Packages= !linux-generic linux-virtual ``` But, even if it was replaceable it...

There is how it behaves if I add `--verify`: ``` builder@x86_64:~/RPM/BUILD/restic-0.9.6$ restic -r ../test restore latest -t x --verify 2>&1 | head restoring to x verifying files in x finished...

Note that invalid restore does not produce non-zero `exit` code. (Not even message if `--verify` is not specified.) This is unusual and non-unix style behavior that would make restore failures...

It's reproducible with your repo/cache/pass settings. I can upload archive (38M) of the data which would reproduce the problem.