[arch-general] 32bit chroot in 64bit guest
I've got some packages to upgrade for both arches and I was wondering if it's possible to run a non-native chroot and stop resorting to virtual machines. Given that i686 binaries should be runnable on an x86_64 guest, i just used mkarchroot with an i686-configured pacman.conf, but I get a sudo error when it tries to run makepkg from makechrootpkg. makechrootpkg launches sudo only once, at line 202, and this is the full command: sudo -u nobody makepkg $MAKEPKG_ARGS || touch BUILD_FAILED Now, why require installing sudo in the chroot (standard procedure) if the 'sudo' and 'makepkg' commangs used are *outside* the chroot? Shouldn't they be run through 'mkarchroot -r' to allow cross compilation? Or am I missing something (as usual)? bardo
bardo schrieb:
I've got some packages to upgrade for both arches and I was wondering if it's possible to run a non-native chroot and stop resorting to virtual machines. Given that i686 binaries should be runnable on an x86_64 guest, i just used mkarchroot with an i686-configured pacman.conf, but I get a sudo error when it tries to run makepkg from makechrootpkg.
I never used makechrootpkg myself, and I have heard it fails in this scenario. In principle, i686 chroots work great on x86_64, I have one running for build purposes and to run weird 32 bit applications. If someone would add support to makechrootpkg for cross-arch chroots, that would be great.
When I started my Arch laptop today after applying updates last night, I noticed that the XFCE menu button was not there. After further investigation, I found this in /var/log/slim.log: /usr/lib/xfce4/panel-plugins/xfce4-menu-plugin: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory I have the following relevant packages installed: libjpeg 7-1 xfwm4 4.6.1-1 xfdesktop 4.6.1-1 I really hate having to maneuver around my desktop without a menu button. Any help is greatly appreciated...
sergeantspoon@archlinux.us wrote:
When I started my Arch laptop today after applying updates last night, I noticed that the XFCE menu button was not there. After further investigation, I found this in /var/log/slim.log:
/usr/lib/xfce4/panel-plugins/xfce4-menu-plugin: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory
I have the following relevant packages installed:
libjpeg 7-1 xfwm4 4.6.1-1 xfdesktop 4.6.1-1
I really hate having to maneuver around my desktop without a menu button. Any help is greatly appreciated... There are a thunar revision number problem.
I am sure that you have thunar 1.0.1-3 that is linked with old jpeg, but the new is 1.0.1-2. http://bugs.archlinux.org/task/15506#comment46972 force a "downgrade to new" thunar-1.0.1-2 -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
That seemed to do the trick. Thanks a bunch! On Tue, Jul 14, 2009 at 3:44 PM, Gerardo Exequiel Pozzi<vmlinuz386@yahoo.com.ar> wrote:
sergeantspoon@archlinux.us wrote:
When I started my Arch laptop today after applying updates last night, I noticed that the XFCE menu button was not there. After further investigation, I found this in /var/log/slim.log:
/usr/lib/xfce4/panel-plugins/xfce4-menu-plugin: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory
I have the following relevant packages installed:
libjpeg 7-1 xfwm4 4.6.1-1 xfdesktop 4.6.1-1
I really hate having to maneuver around my desktop without a menu button. Any help is greatly appreciated... There are a thunar revision number problem.
I am sure that you have thunar 1.0.1-3 that is linked with old jpeg, but the new is 1.0.1-2.
http://bugs.archlinux.org/task/15506#comment46972
force a "downgrade to new" thunar-1.0.1-2
-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On Tue 14 Jul 2009 15:34 -0400, sergeantspoon@archlinux.us wrote:
When I started my Arch laptop today after applying updates last night, I noticed that the XFCE menu button was not there. After further investigation, I found this in /var/log/slim.log:
/usr/lib/xfce4/panel-plugins/xfce4-menu-plugin: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory
I have the following relevant packages installed:
libjpeg 7-1 xfwm4 4.6.1-1 xfdesktop 4.6.1-1
I really hate having to maneuver around my desktop without a menu button. Any help is greatly appreciated...
I've had some weird library issues like this before. The only way I know how to fix it is rebooting. Heh, I'd like to figure out the proper way some day.
bardo wrote:
makechrootpkg launches sudo only once, at line 202, and this is the full command: sudo -u nobody makepkg $MAKEPKG_ARGS || touch BUILD_FAILED
I do this all the time. I run the 64 bit kernel on a 32 bit userland and have chroots to build for both architectures. It takes a bit of hacking to mkarchroot and makechrootpkg though. I haven't The reason it fails there is it makechrootpkg needs a scattering of linux32's throughout. Also, you will want it to source /etc/makepkg32.conf (or something...) instead of /etc/makepkg. I posted the hacked scripts I use at http://allanmcrae.com/scripts/dbscripts.tar.gz . Note that mkarchroot builds for i686 and mkarchroot64 builds for x86_64 but as my pacman is i686, I source a different makepkg.conf file on x86_64. Diff the files with similar names against each other to see what I have done... You still need to manually adjust pacman.conf when generating the chroot with mkarchroot, but from then on updating is fine. One day I will patch the devtools to make this easier... Allan
On Tue, Jul 14, 2009 at 6:47 PM, Allan McRae<allan@archlinux.org> wrote:
bardo wrote:
makechrootpkg launches sudo only once, at line 202, and this is the full command: sudo -u nobody makepkg $MAKEPKG_ARGS || touch BUILD_FAILED
I do this all the time. I run the 64 bit kernel on a 32 bit userland and have chroots to build for both architectures. It takes a bit of hacking to mkarchroot and makechrootpkg though. I haven't
The reason it fails there is it makechrootpkg needs a scattering of linux32's throughout. Also, you will want it to source /etc/makepkg32.conf (or something...) instead of /etc/makepkg.
I posted the hacked scripts I use at http://allanmcrae.com/scripts/dbscripts.tar.gz . Note that mkarchroot builds for i686 and mkarchroot64 builds for x86_64 but as my pacman is i686, I source a different makepkg.conf file on x86_64. Diff the files with similar names against each other to see what I have done...
You still need to manually adjust pacman.conf when generating the chroot with mkarchroot, but from then on updating is fine.
One day I will patch the devtools to make this easier...
Perhaps adding arguments like --32 and --64 to selectively include linux32 and linux64 calls would be a good idea
Aaron Griffin wrote:
On Tue, Jul 14, 2009 at 6:47 PM, Allan McRae<allan@archlinux.org> wrote:
bardo wrote:
makechrootpkg launches sudo only once, at line 202, and this is the full command: sudo -u nobody makepkg $MAKEPKG_ARGS || touch BUILD_FAILED
I do this all the time. I run the 64 bit kernel on a 32 bit userland and have chroots to build for both architectures. It takes a bit of hacking to mkarchroot and makechrootpkg though. I haven't
The reason it fails there is it makechrootpkg needs a scattering of linux32's throughout. Also, you will want it to source /etc/makepkg32.conf (or something...) instead of /etc/makepkg.
I posted the hacked scripts I use at http://allanmcrae.com/scripts/dbscripts.tar.gz . Note that mkarchroot builds for i686 and mkarchroot64 builds for x86_64 but as my pacman is i686, I source a different makepkg.conf file on x86_64. Diff the files with similar names against each other to see what I have done...
You still need to manually adjust pacman.conf when generating the chroot with mkarchroot, but from then on updating is fine.
One day I will patch the devtools to make this easier...
Perhaps adding arguments like --32 and --64 to selectively include linux32 and linux64 calls would be a good idea
That is my plan. I just need to find the time.
participants (8)
-
Aaron Griffin
-
Allan McRae
-
bardo
-
Gerardo Exequiel Pozzi
-
Loui Chang
-
sergeantspoon＠archlinux.us
-
Sgt. Spoon
-
Thomas Bächler