I am a little confused. I downloaded Debian squeeze 32bit. I installed that 32bit. I then installed Truecrypt 32bit (which doesn't work on a 64bit os as Truecrypt64 doesn't work on a 32bit os.)

However uname -r says

It is not a 64bit, if it is a 64 bit did it somehow get upgraded from 32 to 64 but it didn't break any of the 32bit packages? Everything runs perfectly fine.

I am completely lost here.

Edit: Unless when I installed the Nvidia drivers it updated to the 64bit kernel automatically? But why didn't anything break?

How sure are you about that?

A 64bit app certainly doesn't work on a 32 bit OS. But most 32 bit x86 apps work on 64 bit x86 OS's. So is there something special about Truecrypt32 that makes it not work on a 64bit OS?

That is just a name. It would be possible to give that name to a 32bit kernel. It is very unlikely that anyone would. But you haven't given room for any likely explanations.

I think upgrading 32 bit to 64 bit would be very difficult (without reinstalling the whole distribution). But if you could do such an upgrade, it wouldn't break your 32 bit packages.

No way. That one is flat out impossible.

I think you were just mistaken about what Debian you were installing.

Debian doesn't make mistakes like labeling a kernel as amd64 when it is 32-bits. Check your '/' directory, if /lib64 is present, you are most likely running 64 bits.

Since you have the 32-bit compatibility libs installed you should be running most 32-bits apps without a problem.

Upgrading from 32 to 64 bits is impossible AFAIK, only re-install.

jlinkels

1 members found this post helpful.

Nope. No /lib64.

Uname -r Says 2.6.32-5-amd64 though.

Look for yourself...

http://s10.postimage.org/62b14dfo9/ss1.png


Edit: I am NOT mistaken about what I installed. As far as it just being a name. Then what could have renamed it, for that matter how could it get renamed? This makes no sense.

Edit II: Also /boot shows config-2.6.32-5-amd64, same for the initrd.img, system.map, vmlinuz-2.6.32-5-amd64.

This has to have something to do with Nvidia.


i nvidia-kernel-2.6.32-5-amd64 - NVIDIA binary kernel module for Linux 2.6.32-5-amd64

uname -a gives more info than uname -r

A true AMD64 kernel should say x86_64 three times in the output of uname -a. A 32-bit kernel will not have x86_64 at all in that output.

I've seen many posts by experts that ought to know saying that it won't work to just drop a 64bit kernel and its associated module files into a 32bit install (a few critical files would be missing). But I've never tried it. If an expert really wanted to, I think it would be possible to create a package to install all the files needed to convert a 32bit Linux system into a 64bit Linux system leaving mostly 32bit packages. I'm actually a little surprised no one is doing that. But I've never heard of it.

When I have installed Nvidia drivers, that involved an obfuscated script from Nvidia that rebuilds the drivers based on the headers of installed kernel. So it didn't modify the kernel itself. If you installed a package that includes a new kernel as part of Nvidia drivers, that makes your idea that the Nvidia install did it a bit more plausible.

Within the theory of "Nvidia driver install did it" there seem to be two unlikely possibilities. That installed a 32-bit kernel that is misnamed AMD64 or that installed all the files needed to convert a 32bit Linux to 64bit Linux. Neither is a very believable theory. If it was the second, I'd sure like to get a long at that package and find out what files are needed to successfully install a 64bit kernel on a 32bit Linux.

1 members found this post helpful.

It only says this,

I just checked the install dvd, just to make sure I didn't make a mistake. It is an i386.


Johnsfine, I just read the bottom part of your reply. That is the thing. I never did anything, I wouldn't trust myself. However I did install Nvidia and I think that may have somehow did all this. But everything works perfectly, no issues at all.


Edit: Hows this for interesting. I uninstalled truecrypt32 and tried to install truecrypt64,

Ok. I am getting that same warning when I install truecrypt32. But the difference is truecrypt64 wouldn't work, truecrypt32 works fine.

I don't know why it says x86_64 only once. But once is enough. That isn't part of the name. I'm pretty sure that indicates a 64bit kernel.

I don't know very much about the Ubuntu installer. But a Linux installer normally boots a copy of Linux from the CD and runs under that while installing a copy of Linux on the hard drive. The info you posted indicates the copy of Linux booted during installation is 32 bit. But that doesn't necessarily imply the copy it installed onto your hard drive was 32 bit.

Wouldn't 64bit programs run on it then? This is the strangest problem I ever had with Linux.


Edit: Actually, so far, this isn't even really a problem since everything is running ok. I am just really curious as to why.

A Debian based system would need /lib and probably other directories populated with essential 64 bit files before 64bit programs would run. Those files conflict with 32 bit files already there, so you would need to have a /lib32 directory to hold 32 bit files whose names collide with 64 bit, and you would need the loader to be configured to look there (and all that is only the beginning).

But did you test? Do you know that 64bit programs don't run?

I just tried a test on a few systems that should get some insight into strange 32bit / 64bit mixes. Look at the last few lines of the output of
cat /proc/self/maps

If you have a 64 bit copy of cat, the last line should have some very long addresses, such as
With a 32 bit cat under a 64 bit kernel, everywhere I've tried the last few lines look something like:
The addresses are just 8 hex digits indicating a 32 bit copy of cat. But there is a rw (readwrite) section very near the end of the 4GB address space (which I marked in bold) indicating a 32 bit process under a 64 bit kernel.

Under a 32 bit kernel I get:
Note the end of the last rw segment c0000000 is much lower than it was for 32 bit cat in 64bit Linux.

Other differences are because these were run on three very different versions of Linux. But the end address of the last rw segment should be a strong indicator of the three possible combinations of sizes for cat itself and for the Linux kernel.

1 members found this post helpful.

lol, now I am seeing i686. And yes, I tried to install truecrypt64 and it acted like it installed but there was nothing there. I installed truecrypt32 and it worked fine. The only thing I can think of is that Nvidia did it. If so this is the very first time in 10+years that I have seen Nvidia do this, or anything do this for that matter.

Where? In the output of uname -a which you quoted earlier?

I think that indicates a 32bit copy of cat running under a 64 bit Linux kernel.

You're making a very convincing case that you have done by accident something many people have asked how to do on purpose and been told "you can't". You seem to have installed a 64bit kernel package into a 32bit Linux and have everything still work.

No with the command you told me to run above,

The only thing that makes sense is that nvidia, when I installed it, installed a 64bit kernel. I am just amazed that everything works well and I just noticed this now. I installed this a few of weeks ago (approx.) and that same day I set up Nvidia.

So basically I have a 64bit kernel that was dropped into a 32bit install but it all works beautifully. Got to love Debian, lol.


Edit: Unless someone has a better explanation other then Nvidia. If so, please share. I don't hate mysteries I just like to solve them, correctly solve them.

Edit II: I just went through re-reading the thread. I got back to the part that you wrote about Nvidia. I had to look around to find what I did. This is how I installed Nvidia,