On Tue, 19 Oct 2021 at 14:54, John Marino (NetBSD) <net...@marino.st> wrote: > > I've put together a system root based on a minimalist subset of the > NetBSD 9.2/AMD64 release. It's working fine except for one small > problem with locales. > > These are the complete contents of /usr/share/locale in that system root: > usr/share/locale/en_US.UTF-8/LC_MONETARY > usr/share/locale/en_US.UTF-8/LC_NUMERIC > usr/share/locale/en_US.UTF-8/LC_TIME > usr/share/locale/en_US.UTF-8/LC_MESSAGES/SYS_LC_MESSAGES > usr/share/locale/en_US.UTF-8/LC_CTYPE > > This is the result of the attempt to set to the en_US.UTF-8 locale: > > # env LANG=en_US.UTF-8 ./locale > LANG="en_US.UTF-8" > LC_CTYPE="C" > LC_COLLATE="C" > LC_TIME="en_US.UTF-8" > LC_NUMERIC="en_US.UTF-8" > LC_MONETARY="en_US.UTF-8" > LC_MESSAGES="en_US.UTF-8" > LC_ALL="" > > > The LC_COLLATE being left at the C locale is normal, I believe. > However, the loading of LC_CTYPE is failing silently. I've tried > going through the source. I'm sure it's some file that needs copying > into the system root, but I can't figure out which file that is. It > doesn't appear to be documented. The LC_CTYPE appears to have a > different mechanism (runes) for loading than the other categories. > > Is there anyone really familiar with the NetBSD locale system that > knows why LC_CTYPE is being ignored inside the chroot? I've spent a > lot of time on this, so it's probably time for me to ask for some help > here.
As a general quick debugging aid that may help in this case - try ktracing a working vs not version and compare "kdump | grep -A1 NAMI" for each :) David
