FS#49426 - [arch-install-scripts] Warning about $LC_* and $LANG not set using installation scripts.

Attached to Project: Arch Linux
Opened by Frederic Bezies (fredbezies) - Saturday, 21 May 2016, 07:03 GMT
Last edited by Dave Reisner (falconindy) - Sunday, 03 July 2016, 21:14 GMT
Task Type Bug Report
Category Arch Projects
Status Closed
Assigned To Gerardo Exequiel Pozzi (djgera)
Dave Reisner (falconindy)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description: I faced this bug while installing archlinux in VirtualBox for some tests this morning.

On pacstrap step, after installing base and base devel, I got this message while processing man hook :

"Updating manpage index...
mandb: can't set the locale; make sure $LC_* and $LANG are correct"

As both are configured in arch_chroot step, I think it is a little bug :)

Additional info:
man-db 2.7.5-2

Steps to reproduce:
See details :)
This task depends upon

Closed by  Dave Reisner (falconindy)
Sunday, 03 July 2016, 21:14 GMT
Reason for closing:  Won't fix
Additional comments about closing:  Nothing to be fixed in arch-install-scripts, see comments for rationale. The fact that man-db complains about this is specific to man-db.
Comment by Frederic Bezies (fredbezies) - Saturday, 21 May 2016, 09:52 GMT
This bug can be seen on any single pacstrap /mnt installation line, like for grub. Done a screenshot of it in a VirtualBox session. It doesn't matter if is a x86_64 or i686 installation. Same problem.
   001.png (30.4 KiB)
Comment by Jan Alexander Steffens (heftig) - Saturday, 21 May 2016, 09:55 GMT
I assume this is because LANG leaked through pacstrap. Maybe pacstrap should enforce LANG=C and unset LC_*?
Comment by Peter Mattern (krabat) - Saturday, 28 May 2016, 10:51 GMT
The problem is due to the installer indeed by default invoking pacstrap and hence probably its child processes as well in locale en_US.UTF-8 which simply isn't available in the target system yet.

The message ceases after the locale was generated in the target system and either man-db is re-installed by running pacstrap from the installer again or binary mandb which is actually throwing the message is run in the Arch chroot. Also, it cannot be seen at all when pacstrap is invoked with LANG=C in the first place.
The problem got manifest when pacman hooks were introduced to run mandb as these are triggered during package installation. In earlier versions of package man-db the binary was launched by systemd timers or cron jobs which were triggered when the installed system was running only.

Personally, I do not think that package man-db is to blame here as throwing a warning message seems like the right thing to do when mandb gets invoked that way. It should probably be re-assigned to Release Engineering.
If invoking pacstrap with LANG=C doesn't have any downside this may be the best solution.
Comment by Dave Reisner (falconindy) - Saturday, 25 June 2016, 15:13 GMT
There's two cases to consider:

1) Entirely empty chroot where no locales previously exist. If pacstrap sets LANG=C, it's just papering over the error. The default behavior for libc when encountering an unknown locale is to fallback on the POSIX/C locale anyways.
2) Mostly empty chroot, but locales exist (for whatever reason) at the time that pacstrap runs. If pacstrap sets LANG=C, it might break things which expected to use the locale accessible in the chroot.

Because of that, I think it's safer to do nothing and just ignore the error from man-db.
Comment by Samantha McVey (samcv) - Saturday, 25 June 2016, 21:52 GMT
When I last tried installing Arch Linux in a VM, from an install image about a week ago, I encountered this error. Subsequently after the error pacman would always hang on "Updating Manpages", even after I had run pacstrap and chroot'd into /mnt and generated and set my locale, running pacman to update ALL installed packages still resulted in it hanging at Updating Manpages and I would have to Ctrl+C to get the installer to progress.
Comment by Dave Reisner (falconindy) - Saturday, 25 June 2016, 22:00 GMT
Yes, updating the index is slow in a VM. That has nothing to do with this bug.
Comment by Samantha McVey (samcv) - Saturday, 25 June 2016, 22:34 GMT
Tried again and you are right, even though the error message is still there it generated the manpages (eventually). Thanks.

Loading...