Bug 185266

switch the personality to 32bit by using linux32 on the 64bit host?

How do you mean? This isn't a chroot, but a Xen virtual machine.

Of course, what I could do is take some form of minimal 64-bit system, boot the Dom-U into that, and take the 32-bit SuSE image as a linux32 chroot under the 64-bit minimal system (it should even be possible to boot linux32 as the init task, and modify it so that it spawns off /sbin/init of the 32-bit system immediately, but that's hackish, to say the least...).

Anyway, as these machines aren't for me to use, but will be used by people who aren't tech-savvy (and need a _working_ (as in pretty much fixed and not for me to change) 32-bit environment for programs they use, and we don't have any Xen-systems running under a 32-bit hypervisor because of the 4G total memory limitation), it's absolutely a no-go to implement a "work-around" of this sort for not being able to pegg the architecture in YaST, as it makes them depend on me to update their system, which I'm technically not allowed to do anyway because of data-protection concerns...

But, maybe I'll just tell them to use "linux32 yast"...

"As the hypervisor on the corresponding system is 64-bit, the Dom-U-kernel we
use is also a 64-bit kernel (a Gentoo Xen-Kernel 2.6.16.18, to be exact), and
there's no way around this."

How should YaST know that it should use 32bit packages ?

Just like Gentoo/Debian/Slackware does, using a profile which describes the current system?

Gentoo, for example, has a symlink as /etc/make.profile, which describes the architecture and USE flags of the currently running system. If I have an x86-profile symlinked there, my system is compiled/installed as an x86-system (without multilib-support, yadda, yadda, I'm not going to repeat the differences between an x86 system and an x86_64 one, because SuSE is no different there).

Anyway, if I decide to upgrade my kernel to a 64-bit enabled kernel with ia32-bit support (just as the kernel that is in use now), the system will happily continue to be a 32-bit system, because the profile tells it so. Upgrades _won't destroy_ the installation (because they won't pull in libraries twice, or overwrite dependencies), and if I really want to, I just install an x86-kernel at some later stage, and still have a running and working system for Intel chips, in case one of my AMD64s fails.

Debian and Slackware have something similar (well, not exactly the same, but still: you can peg the architecture that the relevant installer installs on your system).

All this makes lots of sense: a mixed 32-bit and 64-bit system is possible if you start with a 64-bit (and multi-lib capable!) system, but it isn't if you start with a 32-bit system (because none of the existing distributions _is_ multi-lib capable in it's 32-bit form!).

Why take the "bit-ness" from the running kernel? It's _not_ a property of the kernel what kind of ABI the userland (esp. libc) provides. _It's_ a property of the installation.

I'm reassigning this to the yast2 maintainers. Anyone who has an idea please comment.

I'm afraid you cannot do this. Charles, does it make sense to run 32-bit system on 64-bit Dom0?

Yes, it makes perfect sense to do this, especially if you have programs which are (or need to be) compiled against the 32-bit ABI of some libraries, which aren't available as open-source or aren't ported yet. Think of mplayer (rather mencoder, which is useful as a server installation), for example:

Win32 codecs will only work when mplayer is 32-bit (because the ABI that the Windows DLLs offer is 32-bitted). mplayer itself has dependencies, which then also need to be 32-bit, and so on, until you (basically) have a complete 32-bit set of libraries installed beside the 64-bit base system.

Now: if the space you have available for the Dom-U system is constricted, why not just install a completely 32-bit machine? The only point which has to have interoperability is the syscall interface (rather libc<->kernel communication) and the actual machine language (but x86_64 is just a superset of i686, so this is always true). And, as the Linux kernel offers the complete IA32-Syscall-ABI when compiled to do so, even when it's 64-bitted at its core, this is perfectly safe to do (and works like a charm, btw.). (I've yet to come across a 32-bit program that wouldn't work with a 64-bit Linux kernel, even though the implementation of the IA32-Syscall-Interface is described as not implementing everything the X86_64-Syscall-Interface does)

mencoder is just an example I've privately come across lately (and as I need the capability to drive a 64-bit system in a Dom-U and don't have any 32-bit Dom-0 at hand at home, I just took the route I described for Gentoo above to be able to use mencoder to convert from quicktime, with a 32-bit system running in a 64-bit-kerneld Dom-U; Gentoo even has the provision to build an x86_64 system with a completely 32-bit userland, including glibc, there a profile to do just that).

But, for the use case at my work: there are lots of other programs which are binary-only _and_ aren't available as 64-bit binaries, and thus using a completely 32-bit userland to drive these makes perfect sense (because of library dependencies), even though the underlying kernel might be a 64-bit kernel. And, when the Hypervisor for a Xen-System is 64-bit, all my Dom-Us need to have a 64-bit kernel. Thus: at least with YaST2, there's no way to go from here (atm).

Currently you can't run a 32 or 32PAE domU kernel on a x86-64 dom0 kernel in paravirtual mode.  This is a limitation of Xen.  (Although you can run 32PAE _fully_ virtual domU on a x86-64 dom0.)

Hence his desire for the 64-on-64 with a 32 bit userspace.

Stano, any idea?

Marking as enhancement

This looks like we need to make libzypp preffer 32-bit packages.

Michael, is there any chance go get this mechanism configurable?

IMO this is a bit more than just to make libzypp preffer 32-bit packages. Anyway we'd need some policy based package selection, a solver that enforces this...

Having 'dependency based transaction definition' would enable us to think about it.

--> Architect

The architecture libzypp operates on is already changeable.

The default architecture is determined by calling uname(1) with additional checks of the CPU capabilities to detect broken CPUs (like VIA chips reporting i686 without supporting cmov and cx8).

A simple setting of architecture can be done by the application, i.e. YaST or zypper. The solver testsuite already uses this capability.


More complex is overriding hardware detection for installing the right kernel drivers.

Back to prjmgr for evaluation.

Thus, closing.