[SOLVED] Arch32 chroot failing at gnupg (dirmngr hangs)

sLLiK · 2017-01-16 03:17:00

From a fresh Arch install, I'm following the guide located at:

https://wiki.archlinux.org/index.php/In … bit_system

...to the letter, and the setup always hangs during this step:

> pacman --root /opt/arch32 --cachedir /opt/arch32/var/cache/pacman/pkg --config /opt/arch32/pacman.conf -S base base-devel

...at the "installing gnupg" part of the insallation. After some Googling, most articles seem to attribute this problem to dirmngr (which is running in the background at 100% on one core in my case), but the behavior seems old (circa 2010) and the usual solution provided is to killall dirmngr. Doing so here simply causes the pacman -S base base-devel to fail spectacularly on subsequent packages like gpgme.

Any suggestions on how to resolve this?

Last edited by sLLiK (2017-01-21 23:08:21)

zlatkig · 2017-01-16 19:37:47

I see this too but cannot pin the cause yet. I am creating a 64-bit chroot (with base and base-devel) on a 64-bit host for clean package build. The install script from gnupg does a

dirmngr < /dev/null &> /dev/null

and that hangs forever. Stracing the dirmngr process reveals the following activity:

read(3, "ERR 167772435 Unknown IPC comman"..., 1002) = 352
write(4, "ERR 167772435 Unknown IPC comman"..., 43) = 43
write(4, "\n", 1)                       = 1
...last two lines repeated 6 times...

This sequence is being done over and over again producing an IO of about 15 MB/s and using up one processor core. Lsof shows no foreign files open except /dev/null.

Sending a SIGHUP to the dirmngr process allows pacman to continue. This is hardly the solution, but allows one to move forward until this can be investigated in more depth.

amcinnes · 2017-01-17 10:18:27

Is the /dev/null in your chroot a regular file instead of the device file it should be?

Edit: Yes; the gnupg install script is assuming that you have a real /dev/null, but in your chroot you don't.

Last edited by amcinnes (2017-01-17 10:22:14)

amcinnes · 2017-01-17 10:34:18

Something must have changed, though; I have a script that did this and worked a few weeks ago, and now hangs because of this issue.

zlatkig · 2017-01-17 12:20:13

This happens during the execution of pacman -r <path>. At this point the chroot environment at <path> has not been created yet. The command is being executed in the context of the host system and /dev/null is a real device node.

zlatkig · 2017-01-17 18:34:01

@amcinnes you were right. After taking a second glance to 'lsof' output it dawned on me that dirmngr is massaging '$chroot/dev/null' instead of '/dev/null', despite the fact that we haven't even finished making the chroot environment, let alone chrooted. It is probably the desired behaviour of 'pacman -r', it would make sense. This means that we must provide special filesystems inside '$chroot' prior to installing 'base' and 'base-devel'.

What I did is to first install the package 'filesystem' to get all directories with proper permissions in place ($chroot_dir points to where I put my chrooted environment):

pacman -r $chroot_dir -S filesystem

Then mount special filesystems:

for d in /dev /dev/pts /run /tmp
do
    mount -o bind $d $chroot_dir$d
done
mount -t proc none $chroot_dir/proc
mount -t sysfs none $chroot_dir/sys

Now install 'base' and 'base-devel' minus the allready installed 'filesystem' package:

pacman -r $chroot_dir -S $(pacman -Sgq base base-devel | sed -e '/^filesystem$/d')

Now the installation goes okay and dirmngr does not hang.

I guess on can continue with the tutorial in the wiki now, just remember that the special filesystems are allready mounted at this time. When done, unmount the special filesystems in reverse mount order.

sLLiK · 2017-01-18 19:20:21

That seemed to have unexpected consequences.

# cd /opt
# mkdir arch32
# sed -e 's/\$arch/i686/g' /etc/pacman.d/mirrorlist > /opt/arch32/mirrorlist
# sed -e 's@/etc/pacman.d/mirrorlist@/opt/arch32/mirrorlist@g' -e '/Architecture/ s,auto,i686,'  /etc/pacman.conf > /opt/arch32/pacman.conf
# mkdir -p /opt/arch32/var/{cache/pacman/pkg,lib/pacman}
# pacman --root /opt/arch32 --cachedir /opt/arch32/var/cache/pacman/pkg --config /opt/arch32/pacman.conf -Sy
# pacman --root /opt/arch32 --cachedir /opt/arch32/var/cache/pacman/pkg --config /opt/arch32/pacman.conf -S filesystem

...all seemed to go well. From there:

# mount -o bind /dev /opt/arch32/dev
# mount -o bind /dev/pts /opt/arch32/dev/pts
# mount -o bind /run /opt/arch32/run
# mount -o bind /tmp /opt/arch32/tmp
# mount -t proc none /opt/arch32/proc
# mount -t sysfs none /opt/arch32/sys
# pacman --root /opt/arch32 --cachedir /opt/arch32/var/cache/pacman/pkg --config /opt/arch32/pacman.conf -S $(pacman -Sgq base base-devel | sed -e '/^filesystem$/d')
warning: skipping target: file
warning: skipping target: findutils
warning: skipping target: gawk
warning: skipping target: gettext
warning: skipping target: grep
warning: skipping target: gzip
warning: skipping target: pacman
warning: skipping target: sed
warning: skipping target: texinfo
warning: skipping target: util-linux
warning: skipping target: which
resolving dependencies...
looking for conflicting packages...

...seemed to get past gnutils without incident, then:

:: Running post-transaction hooks...
(1/6) Updating linux initcpios
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: 4.8.13-1-ARCH
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
==> ERROR: failed to detect root filesystem
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [filesystems]
*** Error in `/bin/bash': free(): invalid next size (fast): 0x083e9ee8 ***
======= Backtrace: =========
/usr/lib/libc.so.6(+0x67d2a)[0xf756ad2a]
/usr/lib/libc.so.6(+0x6e9c7)[0xf75719c7]
/usr/lib/libc.so.6(+0x6f196)[0xf7572196]
/bin/bash[0x8097625]
/bin/bash[0x8097f11]
/bin/bash(expand_string_assignment+0x6e)[0x809807e]
/bin/bash(expand_assignment_string_to_string+0x1f)[0x809811f]
/bin/bash(assign_array_element+0x146)[0x80a45e6]
/bin/bash[0x8091154]
/bin/bash[0x8099f69]
/bin/bash[0x8072540]
/bin/bash(execute_command_internal+0x608)[0x80740a8]
/bin/bash(execute_command_internal+0xb6d)[0x807460d]
/bin/bash(execute_command+0x43)[0x80762d3]
/bin/bash(execute_command_internal+0xb1e)[0x80745be]
/bin/bash(execute_command+0x43)[0x80762d3]
/bin/bash(execute_command_internal+0x160e)[0x80750ae]
/bin/bash(execute_command+0x43)[0x80762d3]
/bin/bash[0x8076388]
/bin/bash(execute_command_internal+0xe75)[0x8074915]
/bin/bash(execute_command_internal+0xb6d)[0x807460d]
/bin/bash(execute_command+0x43)[0x80762d3]
/bin/bash(execute_command_internal+0xb1e)[0x80745be]
/bin/bash(execute_command+0x43)[0x80762d3]
/bin/bash(execute_command_internal+0xb1e)[0x80745be]
/bin/bash(execute_command+0x43)[0x80762d3]
/bin/bash(execute_command_internal+0xb1e)[0x80745be]
/bin/bash(execute_command_internal+0x9d1)[0x8074471]
/bin/bash[0x8077b06]
/bin/bash[0x80738f8]
/bin/bash(execute_command_internal+0x608)[0x80740a8]
/bin/bash(execute_command+0x43)[0x80762d3]
/bin/bash(execute_command_internal+0x18b4)[0x8075354]
/bin/bash(execute_command+0x43)[0x80762d3]
/bin/bash(execute_command_internal+0x1b1f)[0x80755bf]
/bin/bash(execute_command_internal+0xb6d)[0x807460d]
/bin/bash(execute_command+0x43)[0x80762d3]
/bin/bash(execute_command_internal+0xb1e)[0x80745be]
/bin/bash(execute_command_internal+0x9d1)[0x8074471]
/bin/bash[0x8077b06]
/bin/bash[0x80738f8]
/bin/bash(execute_command_internal+0x608)[0x80740a8]
/bin/bash(execute_command_internal+0xb6d)[0x807460d]
/bin/bash(execute_command+0x43)[0x80762d3]
/bin/bash(execute_command_internal+0x160e)[0x80750ae]
/bin/bash(execute_command+0x43)[0x80762d3]
/bin/bash[0x8076388]
/bin/bash(execute_command_internal+0xe75)[0x8074915]
/bin/bash(execute_command_internal+0xb6d)[0x807460d]
/bin/bash(execute_command+0x43)[0x80762d3]
/bin/bash(execute_command_internal+0xb1e)[0x80745be]
/bin/bash(execute_command+0x43)[0x80762d3]
/bin/bash(execute_command_internal+0xb1e)[0x80745be]
/bin/bash(execute_command+0x43)[0x80762d3]
/bin/bash(execute_command_internal+0xb1e)[0x80745be]
/bin/bash(execute_command_internal+0x9d1)[0x8074471]
/bin/bash[0x8077b06]
/bin/bash[0x80738f8]
/bin/bash(execute_command_internal+0x608)[0x80740a8]
/bin/bash(execute_command+0x43)[0x80762d3]
/bin/bash(execute_command_internal+0x18b4)[0x8075354]
/bin/bash(execute_command+0x43)[0x80762d3]
/bin/bash(execute_command_internal+0x1b1f)[0x80755bf]
======= Memory map: ========
08048000-08120000 r-xp 00000000 08:03 2497699                            /usr/bin/bash
08120000-08121000 r--p 000d7000 08:03 2497699                            /usr/bin/bash
08121000-08123000 rw-p 000d8000 08:03 2497699                            /usr/bin/bash
08123000-0812e000 rw-p 00000000 00:00 0 
0837e000-08421000 rw-p 00000000 00:00 0                                  [heap]
f72e2000-f72fe000 r-xp 00000000 08:03 2494956                            /usr/lib/libgcc_s.so.1
f72fe000-f72ff000 r--p 0001b000 08:03 2494956                            /usr/lib/libgcc_s.so.1
f72ff000-f7300000 rw-p 0001c000 08:03 2494956                            /usr/lib/libgcc_s.so.1
f7300000-f7321000 rw-p 00000000 00:00 0 
f7321000-f7400000 ---p 00000000 00:00 0 
f7413000-f7496000 rw-p 00000000 00:00 0 
f7496000-f74fe000 r-xp 00000000 08:03 2497599                            /usr/lib/libncursesw.so.6.0
f74fe000-f74ff000 ---p 00068000 08:03 2497599                            /usr/lib/libncursesw.so.6.0
f74ff000-f7501000 r--p 00068000 08:03 2497599                            /usr/lib/libncursesw.so.6.0
f7501000-f7502000 rw-p 0006a000 08:03 2497599                            /usr/lib/libncursesw.so.6.0
f7502000-f7503000 rw-p 00000000 00:00 0 
f7503000-f76b5000 r-xp 00000000 08:03 2494590                            /usr/lib/libc-2.24.so
f76b5000-f76b6000 ---p 001b2000 08:03 2494590                            /usr/lib/libc-2.24.so
f76b6000-f76b8000 r--p 001b2000 08:03 2494590                            /usr/lib/libc-2.24.so
f76b8000-f76b9000 rw-p 001b4000 08:03 2494590                            /usr/lib/libc-2.24.so
f76b9000-f76bc000 rw-p 00000000 00:00 0 
f76bc000-f76bf000 r-xp 00000000 08:03 2494644                            /usr/lib/libdl-2.24.so
f76bf000-f76c0000 r--p 00002000 08:03 2494644                            /usr/lib/libdl-2.24.so
f76c0000-f76c1000 rw-p 00003000 08:03 2494644                            /usr/lib/libdl-2.24.so
f76c1000-f7704000 r-xp 00000000 08:03 2497660                            /usr/lib/libreadline.so.7.0
f7704000-f7705000 ---p 00043000 08:03 2497660                            /usr/lib/libreadline.so.7.0
f7705000-f7706000 r--p 00043000 08:03 2497660                            /usr/lib/libreadline.so.7.0
f7706000-f770a000 rw-p 00044000 08:03 2497660                            /usr/lib/libreadline.so.7.0
f770a000-f770b000 rw-p 00000000 00:00 0 
f7711000-f7714000 rw-p 00000000 00:00 0 
f7714000-f7716000 r--p 00000000 00:00 0                                  [vvar]
f7716000-f7718000 r-xp 00000000 00:00 0                                  [vdso]
f7718000-f773a000 r-xp 00000000 08:03 2494589                            /usr/lib/ld-2.24.so
f773a000-f773b000 r--p 00021000 08:03 2494589                            /usr/lib/ld-2.24.so
f773b000-f773c000 rw-p 00022000 08:03 2494589                            /usr/lib/ld-2.24.so
fff89000-fffaa000 rw-p 00000000 00:00 0                                  [stack]
/usr/bin/mkinitcpio: line 278: 28780 Aborted                 (core dumped) MKINITCPIO_PROCESS_PRESET=1 "$0" "${preset_cmd[@]}"
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> Starting build: 4.8.13-1-ARCH
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [modconf]
  -> Running build hook: [block]

...and there, it has stayed. Forever. Looks lke mkinitcpio is working on compiling from the fallback preset, which is taking forever, but I would expect that to be an indication that a Bad Thing Happened under normal circumstances. I think that's the first time the default preset didn't work for me. The fact that it says it failed to detect root filesystem is, I'm sure, a contributing factor. Did I miss a step?

Last edited by sLLiK (2017-01-18 19:32:18)

amcinnes · 2017-01-19 08:20:59

Have you looked at pacstrap (part of the arch-install-scripts package)? It handles the process of mounting special filesystems in a chroot and then running pacman. I haven't tried it for installing 32-bit under 64-bit, but it can probably do that.

eschwartz · 2017-01-19 08:59:13

+1 to pacstrap/mkarchroot, also note that creating a 32-bit chroot on a 64-bit system is even easier with `setarch` as is used in (devtools).

sLLiK · 2017-01-19 17:04:12

Even before I'd started working through trying to follow the howto, it had a mention at the top of the page related to consideration of pacstrap as an talking point, so it's definitely an option on the table. Was there a reasoning behind not using it for this from the beginning?

Alad · 2017-01-19 17:06:31

That article dates years back - I doubt much of it is still relevant at this point.

edit: made some updates

Last edited by Alad (2017-01-19 17:22:45)

sLLiK · 2017-01-21 23:15:25

Slam dunk. Thanks to everyone's attention, troubleshooting, and updates to the wiki article in question. The revised how-to worked like a charm.

Ironically, this was all brought about by a need for Webex. Hopefully someday soon, Webex will support 64-bit Linux, or vendors will stop using it. My additional steps to pass a successful Webex test from the new chroot were the following:

> linux32 arch-chroot /opt/arch32
> pacman -S icedtea-web
> pacman -S firefox
> pacman -S gtk2
> pacman -S libpng12
> pacman -S libx11
> pacman -S libxmu
> pacman -S libxt
> pacman -S pango
> pacman -S pangox-compat
> pacman -S xf86-input-evdev
> pacman -S xf86-input-libinput
> pacman -S zsh
  
> cd /home
> mkdir /home/{username}
> chown {username}:{username} {username}
> sudo su - {username}
> DISPLAY=:0 firefox

Arch Linux

#1 2017-01-16 03:17:00

[SOLVED] Arch32 chroot failing at gnupg (dirmngr hangs)

#2 2017-01-16 19:37:47

Re: [SOLVED] Arch32 chroot failing at gnupg (dirmngr hangs)

#3 2017-01-17 10:18:27

Re: [SOLVED] Arch32 chroot failing at gnupg (dirmngr hangs)

#4 2017-01-17 10:34:18

Re: [SOLVED] Arch32 chroot failing at gnupg (dirmngr hangs)

#5 2017-01-17 12:20:13

Re: [SOLVED] Arch32 chroot failing at gnupg (dirmngr hangs)

#6 2017-01-17 18:34:01

Re: [SOLVED] Arch32 chroot failing at gnupg (dirmngr hangs)

#7 2017-01-18 19:20:21

Re: [SOLVED] Arch32 chroot failing at gnupg (dirmngr hangs)

#8 2017-01-19 08:20:59

Re: [SOLVED] Arch32 chroot failing at gnupg (dirmngr hangs)

#9 2017-01-19 08:59:13

Re: [SOLVED] Arch32 chroot failing at gnupg (dirmngr hangs)

#10 2017-01-19 17:04:12

Re: [SOLVED] Arch32 chroot failing at gnupg (dirmngr hangs)

#11 2017-01-19 17:06:31

Re: [SOLVED] Arch32 chroot failing at gnupg (dirmngr hangs)

#12 2017-01-21 23:15:25

Re: [SOLVED] Arch32 chroot failing at gnupg (dirmngr hangs)

Board footer