# [Answered] HOWTO Kernel 32bits / 64bits

## MaximeG

Hi,

I know it will be a bit of a noob question here, but I want to be sure to know exactly what's involving before choosing my kernel, and therefore performing my new installation.

First is there a difference between the kernel 32 bit and kernel 64 bit ? Has it an impact on what I'll be able to install afterwards ?

Can I do a chroot to get a 64 bit environment in a 32bit environment ? Can I do the opposite (32 in a 64 environment)? If yes, what are the conditions ?

Do I need a amd64 kernel in every case ?

I'm admit being a bit confused down here.

My plan is : To run a 32 bit pure environment as a base and being able to chroot to a 64bit environment if possible.

Thanks for your help,

MaximeLast edited by MaximeG on Wed Oct 29, 2008 2:50 pm; edited 1 time in total

----------

## beso_1717

 *MaximeG wrote:*   

> Hi,
> 
> I know it will be a bit of a noob question here, but I want to be sure to know exactly what's involving before choosing my kernel, and therefore performing my new installation.
> 
> First is there a difference between the kernel 32 bit and kernel 64 bit ? Has it an impact on what I'll be able to install afterwards ?
> ...

 

well, i would recommend instead a no-multilib 64 bit profile and a chroot for apps that don't run in 32bit mode (like flash player or java plugin for firefox). chrooting to 32bit from a 64 bit is possible, but i don't know of the opposite. anyway, there are still only a few 32bit apps around that don't have a 64bit counterpart and since 64bit is faster on a 64bit capable machine it would be useless not going with it.

in the end, i would also say one one thing: gentoo has probably the best multilib profile in the linux world and it's very simple to run 32 bit apps from 64bit  multilb without chrooting and so. the user experience on the multilib profile is very pleasant on gentoo.

----------

## MaximeG

Hi,

Thanks. I've tried once to have a multilib installation. But the problem is that I wasn't able to run a single game with this mixed up libs, plus you never know what library your system is actually using.

I'd like to try to have both 32bits and 64bits pure environments, switching from one to the other with chroot, to get the best from these 2 worlds.

And I don't agree that 64bits is faster than 32 bits. I'd add it depends a lot on :

        1) What kind of application you're running

        2) Whether this application has been developed with a 64bits mode or not.

And this because of the way memory is addressed. I don't want to go into a detailed explanation on how 64bits and 32 bits work, but I just wanted to say that I know a bit about it  :Wink: 

What I don't know (or what I barely know) is how to manage the 2 environments with chroot and linux kernels.

Thanks,

Maxime

----------

## MaximeG

Hi,

Is there really 2 different kernels for 32bits and 64bits ? I know this sounds like stupid a question, but I can't get a clear answer on this one.

----------

## pappy_mcfae

 *MaximeG wrote:*   

> Hi,
> 
> Is there really 2 different kernels for 32bits and 64bits ? I know this sounds like stupid a question, but I can't get a clear answer on this one.

 

I think that's because you aren't asking the question properly. Kernel source is kernel source, and it will compile either a 32 or 64 bit kernel depending on how you set up the .config file. Once compiled, yes, the kernels are different from each other, and as far as I know, 32 bit kernels won't work in a 64 bit environment. I believe that the opposite might be true, but I have never tested this to find out one way or the other.

Also, to answer another question, you can chroot a 32 bit setup with a 64 bit kernel, but not the other way around. If you desire to setup a 64 bit system, it has to be done from a 64 bit install disk.

Hope that answers your questions.

Blessed be!

Pappy

----------

## RoundsToZero

Well it's the same kernel but you compile for either 32 or 64 bit, not both.  If you want to run 64 bit in any way, you need to compile the kernel for 64 bit.  This kernel can run both 64 and 32 bit applications.  If you compile the kernel for 32 bit you can only run 32 bit.  If you try to run a 64 bit application on a 32 bit kernel, even if you chroot into a completely 64 bit userland, you will get a message that says invalid executable format.  It might not even be possible to do this chroot because when you chroot it needs to run a shell inside the new environment, and you couldn't run the 64 bit shell that would be in that environment.

I suppose it would be possible to create a completely 32 bit userland with a 64 bit kernel, then chroot into 64 bit environment when you want to, but it doesn't really make sense.  The most direct way to get the 64 bit kernel is with the amd64 Gentoo LiveCD.  The stage tarballs for this are 64 bit userlands so that's what you'd get when you install it.  It makes more sense to install a 64 bit kernel and userland with no multilib (as a previous poster suggested) to make sure you get no 32 bit userland stuff in your environment, making it pure 64 bit.  Then you create a 32 bit chroot environment with all the necessary 32 bit userland stuff inside it.  You chroot to it when you want to do 32 bit stuff.  The kernel is still the same when you chroot, still 64 bit.  You can't very well change that while the system is running.  But once you chroot to your 32 bit environment, all the applications and userland are 32 bits.  This works because 64 bit kernels can run either type of application.  If you used the i386 Gentoo LiveCD you'd get a 32 bit kernel and you wouldn't be able to run 64 bit applications even if you had a 64 bit chroot environment set up.

Edit:

But this:

 *Quote:*   

> Thanks. I've tried once to have a multilib installation. But the problem is that I wasn't able to run a single game with this mixed up libs, plus you never know what library your system is actually using.

  is really what you want to try to solve.  It's definitely possible to run 32 bit games and have them use 32 bit libs.  It's also definitely possible to know "what library your system is actually using".  I don't know why you make these out to be such difficult tasks.  Plus then you don't need to maintain two separate environments and keep each one up to date independently, etc.

----------

## beso_1717

 *RoundsToZero wrote:*   

> 
> 
> Edit:
> 
> But this:
> ...

 

simple example: wine runs in 32bit only (there isn't still a 64bit wine version) and uses 32bit libraries. the same goes for firefox-bin (32bit precompiled version) that uses 32bit plugins (i have to build mplayerplugin with ABI=x86 or it won't find it). usually if you try to run an app in 32bit on a multilib system it will only use 32bit libs and not 64bit one. the problem you had with the games wasn't due to the multilib system, but to the game being buggy on linux.

----------

## beso_1717

 *MaximeG wrote:*   

> Hi,
> 
> Thanks. I've tried once to have a multilib installation. But the problem is that I wasn't able to run a single game with this mixed up libs, plus you never know what library your system is actually using.
> 
> I'd like to try to have both 32bits and 64bits pure environments, switching from one to the other with chroot, to get the best from these 2 worlds.
> ...

 

hmmmm..... if you compile a program for 64 bit do you agree that it was written for 64bit?! the lenght of the types, to do a simple example, are different in 64bit when compared to 32bit. so i think that it's obvious that a 64bit compiled app has been written for 64bit arch. nowadays there isn't any single reason not to go with 64bit system (i can assure you that i can feel the change on my system). 

also if you run 64bit apps on 64bit system then you don't have problems. if you run 32bit apps on a 32bit chroot system you'll go about the same as running it from 64bit multilib system. it's true that if you want to use a 32bit app on a 64bit system it could be a little slower, but this happens also in a chroot system. the only good reason to have a chroot is the cleaness of the system, but i tend to consider the chroot a lost of time since the time needed to mantain both chroots and how the losing of time for configuration of the system is quite high when compared with the performances.

----------

## MaximeG

Thanks a lot for your answer guys, really.

I've suspected all of these but wasn't sure at all. Now I'm less stupid :p

But for the multilib thingy I think I expressed myself wrongly : my question was more : "How to be sure that the application I've installed will use 32bits, or will use 64bits ?"

For instance, how can I make sure that, while installing a software, I get the 32bit version ?

But, I guess these questions are for later, when my multilib environment will be installed.

Thanks,

Maxime

----------

## RoundsToZero

You can be sure because a 32 bit application can only use 32 bit libraries, same with 64 bit.  If a 32 bit application needs some library that you only have 64 bit libraries of, it won't start because "no such file or directory" on the appropriate 32 bit library it needs.  To get 32 bit libraries you install emul- packages, or I guess you can use the ABI variable to build a regular package 32 bit (assuming its 32 bit build time dependencies are satisfied) like a previous poster suggested.  Generally the emul- packages will get you as far as standard system libraries like sound, X, Qt, etc. but for stuff like mplayerplug-in you build it yourself.  I think that answers your second question too, how to make sure you get the 32 bit version.

----------

## Monkeh

 *RoundsToZero wrote:*   

> If you try to run a 64 bit application on a 32 bit kernel, even if you chroot into a completely 64 bit userland, you will get a message that says invalid executable format.  It might not even be possible to do this chroot because when you chroot it needs to run a shell inside the new environment, and you couldn't run the 64 bit shell that would be in that environment.

 

The shell is what brings up the error.

----------

## beso_1717

 *Monkeh wrote:*   

>  *RoundsToZero wrote:*   If you try to run a 64 bit application on a 32 bit kernel, even if you chroot into a completely 64 bit userland, you will get a message that says invalid executable format.  It might not even be possible to do this chroot because when you chroot it needs to run a shell inside the new environment, and you couldn't run the 64 bit shell that would be in that environment. 
> 
> The shell is what brings up the error.

 

nope. i've installed gentoo 64bit from an existing suse 9.3 32bit by chrooting into gentoo and building from suse while continuing to do my normal work. what's important is that the chroot to be outside the 32bit system. but again, using a 32base system on a modern machine (which is 64bit capable) in my opinion is a little stupid. it's better to do the opposite if it's really necessary to have 64bit and 32bit separate systems.

----------

## eccerr0r

 *beso_1717 wrote:*   

> nope. i've installed gentoo 64bit from an existing suse 9.3 32bit by chrooting into gentoo and building from suse while continuing to do my normal work. what's important is that the chroot to be outside the 32bit system. but again, using a 32base system on a modern machine (which is 64bit capable) in my opinion is a little stupid. it's better to do the opposite if it's really necessary to have 64bit and 32bit separate systems.

 

What's important is that you have a 64-bit kernel with 32-bit support, which will happily run both 64 and 32-bit binaries transparently, even with a 32-bit root.  If you have a 32 bit kernel, the previous posters are right, you cannot chroot into a 64-bit environment.  

This is a different case when you're cross compiling a 64-bit environment using a 32-bit kernel and 32-bit environment.  But you can't chroot into it, a 32 bit kernel would not know what to do with a program that requests a 64-bit pointer or 64-bit registers.  The kernel will stop this from happening early by noticing the magic numbers on the file do not match a known binary type and return back to the shell, which will say "invalid executable."

----------

## Monkeh

 *beso_1717 wrote:*   

>  *Monkeh wrote:*    *RoundsToZero wrote:*   If you try to run a 64 bit application on a 32 bit kernel, even if you chroot into a completely 64 bit userland, you will get a message that says invalid executable format.  It might not even be possible to do this chroot because when you chroot it needs to run a shell inside the new environment, and you couldn't run the 64 bit shell that would be in that environment. 
> 
> The shell is what brings up the error. 
> 
> nope. i've installed gentoo 64bit from an existing suse 9.3 32bit by chrooting into gentoo and building from suse while continuing to do my normal work.

 

Not with a 32-bit kernel you haven't.

----------

## beso_1717

 *Monkeh wrote:*   

>  *beso_1717 wrote:*    *Monkeh wrote:*    *RoundsToZero wrote:*   If you try to run a 64 bit application on a 32 bit kernel, even if you chroot into a completely 64 bit userland, you will get a message that says invalid executable format.  It might not even be possible to do this chroot because when you chroot it needs to run a shell inside the new environment, and you couldn't run the 64 bit shell that would be in that environment. 
> 
> The shell is what brings up the error. 
> 
> nope. i've installed gentoo 64bit from an existing suse 9.3 32bit by chrooting into gentoo and building from suse while continuing to do my normal work. 
> ...

 

well, i might miss but at that time suse only worked at 32bit on my pc and i was forced to go through it to install the 64bit version i'm on now. i can also do chroots in my 64bit environments and mount the lvm partitions (the livecds don't support lvm) to resize them.

----------

