Leo Famulari writes: > First, how was the LUKS2 volume created? Was it created by Guix > System? No, this would've been a volume I created myself; I expect only users who are partitioning their drives manually or replacing an existing system would encounter this. The Guix manual actually instructs users to select a different PBKDF algorithm[0] for compatibility with GRUB, one that by coincidence does not appear to be affected[1]. However, remember this problem potentially affects _all_ packages that use threads in C or C++. It appears that dynamically-linked executables (i.e. the vast majority) generally sidestep the problem by avoiding any "dangerous" methods in libgcc, but there could still be crashing bugs elsewhere waiting to be discovered. > Is Guix doing something wrong that requires the workaround? This is all a consequence of stripping libraries with the "--strip-unneeded" option instead of "--strip-debug"[2], in the interest of reducing store sizes. The man page for "strip" describes it like this: --strip-unneeded Remove all symbols that are not needed for relocation processing. My personal opinion is that this option makes sense for executables but is too aggressive to use on libraries. - Unlike executables, we generally want to do more with a library than just relocate it. - Providing a rich set of symbols is normally a desirable feature of a library and not a bug. - Only at link time is it possible to say which of a library's symbols are truly relevant; therefore, the selection of symbols to retain should logically be performed by the linker, not an automated step during the library's packaging (outside of any link context). Specifically, it's impossible for us to predict cases like this one, where a symbol not obviously needed to use a library is nonetheless relied on by an application. However, Guix's gnu-build-system provides only a single "#:strip-flags" argument that is applied to all of a package's binaries. So, as an alternative solution, we could either extend that mechanism to allow different sets of flags to be applied to different types of binaries, or revert the changes (commits f32a6055a5 and e0f31baacc) altogether. I didn't expect either of those options would be popular, and truthfully, everything does appear to work okay (for now) with only this one change to glibc. [0] https://guix.gnu.org/en/manual/devel/en/html_node/Keyboard-Layout-and-Networking-and-Partitioning.html#Disk-Partitioning [1] But then, neither GRUB nor the Guix installer are commonly used on non-Intel systems. [2] Originally proposed in https://issues.guix.gnu.org/42555 -- Simon South simon@simonsouth.net