i386 7.2 to AMD64 8.0 possible?

Ben

Ben

Hi,

I have a server running i386 7.2. Now I want to upgrade to 8.0 and switch to AMD64.

Is this easily possible or would you recommend to completely reinstall and migrate the data?

Thanks for recommendations.
 
back up your data - test that backup, wipeout your hard drive and instal amd64. restore your data. the only recomendation, everything else is wasting time and cpu cycles.
 
+1 for mk. They're are probably ways to upgrade your material otherwise but this way will save you many headaches in the future.
 
I disagree. While it DOES take a lot longer to build 8.0 from source, you get the advantage of using your /etc/make.conf to set your CPUTYPE and other flags, also, if you want, you can build only the parts of the system you need.

I like doing src updates.
 
Wonslung, what do you disagree with? No one is advocating against installing or upgrading from sources. The question is whether trying to upgrade from a 32-bit to a 64-bit OS without starting from scratch is advisable.
 
yah, i see that now, i totally misread. (didn't see the i386 to amd64 part)

All i saw was upgrade from 7.2 -> 8.0

so, yah, i'm an idiot.
 
It's not impossible to source upgrade from i386 -> amd64, but it is a pretty major undertaking.

The upside is, you could learn a whole lot that you never even suspected you might want to know about FreeBSD and cross building.

The downside is, you'll spend several days pulling your hair out and all that stuff you learned will make you say things like: it's a lot easier to just backup, install the new version, and restore your data.
 
fronclynne said:
The downside is, you'll spend several days pulling your hair out and all that stuff you learned will make you say things like: it's a lot easier to just backup, install the new version, and restore your data.
Click to expand...

Yeah, i always learn a lot more when i break something first
 
Thanks for your comment.

I guess I will go with the fresh install. Time is rare these days ;)

Thanks guys.

P.S: I dont like that others change the thread status to "solved".
 
Isn't amd64 really just the kernel and kernel modules since I thought when you do "make buildworld", it will still build the same i386 binaries and it's only the kernel that is based on different architectures?
 
vincepoy said:
Isn't amd64 really just the kernel and kernel modules since I thought when you do "make buildworld", it will still build the same i386 binaries and it's only the kernel that is based on different architectures?
Click to expand...


I'm pretty sure most of the libs are different in amd64 as well. I know it includes 32 bit emulation for programs that don't run 64 bit natively but building 64 bit is a lot more than just the kernel.
 
vincepoy said:
Isn't amd64 really just the kernel and kernel modules since I thought when you do "make buildworld", it will still build the same i386 binaries and it's only the kernel that is based on different architectures?
Click to expand...

It will use the same source code, yes. But it will compile code using AMD64 instructions and not i386. So no, they're not the same from a binary point of view.
 
Is there really any advantages of using amd64 vs i386 with PAE assuming you did have more than 4GB of memory? You're right it's not the same from a binary point of view but what happens if you enable 32bit emulation in amd64, can you use existing libraries that are 32bit assuming that the versions you need aren't part of the base system.
 
Personally, I really dislike PAE and would go for native amd64 whenever possible.

The FreeBSD handbook, chapter 8.6.1 lists some disadvantages of PAE. Normally, running 32-bit libs and programs should be no problem so there is not really a point against amd64.
 
vincepoy said:
Is there really any advantages of using amd64 vs i386 with PAE assuming you did have more than 4GB of memory? You're right it's not the same from a binary point of view but what happens if you enable 32bit emulation in amd64, can you use existing libraries that are 32bit assuming that the versions you need aren't part of the base system.
Click to expand...


There is a huge advantage to amd64 if you are using ZFS
 
vincepoy said:
Is there really any advantages of using amd64 vs i386 with PAE assuming you did have more than 4GB of memory? You're right it's not the same from a binary point of view but what happens if you enable 32bit emulation in amd64, can you use existing libraries that are 32bit assuming that the versions you need aren't part of the base system.
Click to expand...

The biggest difference is in the way memory is handled. On the i386, you are limited in the amount of virtual memory (RAM + swap) that a single process can access: 4 GB. However, up to 2 GB of that is reserved for the kernel, leaving just 2 GB of VM for a process to access. Even with PAE, each individual process is limited to 2 GB.

With PAE, the kernel can use up to ... 48 GB? of VM, which means you can run multiple processes, each with their own 2 GB. But they are still limited.

On amd64, each process can access up to ... 128 GB? I think. So, you can put 128 GB of RAM into a server, and dedicate it all to a single database process. That's impossible to do on a 32-bit system.

The way memory is accessed is also different, but that's getting into the nitty gritty details of how the CPU access RAM. Suffice to say, amd64 is better is pretty much every way, when it comes to RAM.
 
I can see the advantages of avoiding a reinstall, having reinstalled various servers, reconfiguring customised configs etc. certianly as far as I am concerned wiping and starting again is a lot of work.

So if anyone does succeed doing this please if possible do a how-to on it.
 
I recently "cross-graded" from i386 8.0 to amd64 without reinstalling.

It's not as simple as a cross-buildworld and install, though. You need to be running in 64 bit for an installworld to work.

Fortunately, booting an AMD64 installation DVD and mounting the liveFS in fixit mode is the solution.

First, back up everything. Just because I succeeded doesn't mean I'm right (or not forgetting a step or two here or there). Next, boot up the DVD, go into fixit mode with the liveFS.

Once you are running in fixit mode with the livefs, give yourself a chrooted shell on the livefs root, mount devfs on /dev, then fsck and mount all of your system's actual disks on the livefs' /mnt directory.

Next, perform loopback mounts of your systems /tmp, /var/tmp, /usr/src and /usr/obj on their respective directories in the livefs (so /mnt/tmp to /tmp, for instance).

Now, cd /usr/src && make installworld DESTDIR=/mnt && make installkernel DESTDIR=/mnt

and stand back.

There is currently a...bug? misfeature? not sure... where /libexec/ld-elf.so does not get updated by an installworld. You need to cd /usr/src/libexec/rtld-elf && make install

Now you should be able to reboot into multiuser mode.
 
Hello,

I'm pretty new to Unix/Linux in general and FreeBSD in particular, and nevertheless trying to migrate an 7.2 i386 system to 8.1-RC2 amd64 as [nsayer] explained it.

Being new, i have problems with giving myself a "chrooted shell on the livefs root" and "mounting devfs on /dev".


"Next, perform loopback mounts of your systems /tmp, /var/tmp, /usr/src and /usr/obj on their respective directories in the livefs (so /mnt/tmp to /tmp, for instance)."

that would be done with "mount -F lofs", right?

Would someone care to elaborate?

Thanks in advance, Mask.
 
why one would want to that?
clearly there is no benefit of not interrupting any given services.you still have to reboot. it add more time, more ways to damage your system with option to render it _i_don't_know_what's_on_disk_ situation (be paranoid aka don't gamble with your data) where you can't retrieve your data back.
so.. 32 to 64bits while compiling the hell out of your machine - just because you can, not because it's worth.
 
You really, really, really, really don't want to "upgrade" a running 32-bit system to a 64-bit system. Just don't!

Backup your data. Re-install from a 64-bit install CD. Re-install your apps. Restore your data.

Trust me. It will be a *LOT* faster, safer, and smoother that way.
 
You must log in or register to reply here.
Back
Top