Upgrade from 32-bit to AMD-64?
ian j hart
ianjhart at ntlworld.com
Wed Feb 18 12:13:53 PST 2009
On Wednesday 18 February 2009 17:57:16 Karl Denninger wrote:
> ian j hart wrote:
> > On Friday 13 February 2009 08:40:27 Goran Lowkrantz wrote:
> >> Hi,
> >> When have done this, MySQL is OK but Berkley and PostgreSQL need
> >> dump/restore.
> >> /glz
> > [sorry I'm a bit late]
> > IIRC system accounting did weird stuff until I adjusted it with rm :)
> >> --On February 13, 2009 2:53:13 -0500 Mike Andrews <mandrews at bit0.com>
> >>> Xin LI wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>> Karl Denninger wrote:
> >>>> [...]
> >>>>> I guess I need to schedule the 2-3 hours of downtime..... the reason
> >>>>> for this, by the way, is that I have a dbms app on there that is
> >>>>> getting too RAM hungry for its own good (its a Quadcore CPU) and I'm
> >>>>> up against the RAM limit for 32-bit code. The board will support
> >>>>> more but 32-bit code won't; ergo, the only way to get beyond this is
> >>>>> to go to 64-bit.
> >>>> Oh wait! One thing you wanted to know is that, some database *can*
> >>>> have different on-disk format for 32-bit and 64-bit binaries. Be sure
> >>>> to have a dump handy. Last time I hit this on a MySQL "upgrade"
> >>>> between two servers, and I end up using its replication functionality.
> >>>> The operation took longer time than I expected at the beginning.
> >>> For what it's worth, I did an in-place source upgrade on our MySQL
> >>> server (for the same lack-of-memory reason) and didn't have any on-disk
> >>> format problems. In fact later on when troubleshooting data corruption
> >>> problems that turned out to be bad hardware, I switched between 32-bit
> >>> and 64-bit mysqld binaries without rebooting or dumping/reimporting the
> >>> database.
> >>> BUT... there was no replication involved. It wouldn't surprise me if
> >>> the binlog or relay logs were in an architecture specific format.
> >>> InnoDB and MyISAM tables don't appear to be. This was over a year ago
> >>> though, so test on a scratch box first and you may save yourself a bit
> >>> of downtime.
> >>> The upgrade is a pain, and does have a lot of potential foot-shooting,
> >>> and you have to immediately recompile ALL of your installed ports (and
> >>> anything else not built from ports) to avoid mixing 32-bit and 64-bit
> >>> shared libraries... and that rebuilding ports time is where most of
> >>> your downtime comes from if it's a production box.
> >>> If you're feeling lucky, the procedure's in the list archives somewhere
> >>> and the super-short version is you turn your swap partition into a
> >>> temporary amd64 root filesystem, installworld/kernel into that, boot
> >>> into that, then mount and installworld/kernel on top of the old i386
> >>> root filesystem from there, then boot into it and recompile all your
> >>> ports (after reclaiming your swap partition for swap). Or, the way I
> >>> did it last time was to boot into a PXE diskless FreeBSD/amd64 install
> >>> and use that to mount/install over the i386 stuff.
> >>> Definitely practice on a scratch system first. :)
> >>> --
> >>> Mike Andrews
> >>> Server Monkey
> >>> Fark, Inc
> >>> mandrews at fark.com
> I have been able to come up with a procedure that works.
It's a while back, but I believe this matches what I did.
I built the same major/minor revision, just in case it made any difference.
> 1. Load a new hard disk with the 64-bit code. Perform a buildworld and
> buildkernel, and installkernel and installworld to this disk to verify
> that it will install and run. You now have a "base" disk to use for
> 2. Make sure you have a backup (:-))
Not optional. I broke the mirror and took a backup and I actually checked the
> 3. Boot the migration hard disk as the system disk and mount the subject
> machine's disk drive(s) under /mnt.
> 4. Do "make DESTDIR=/mnt installkernel" and "make DESTDIR=/mnt
> 5. Shut down and disconnect migration disk.
> 6. Boot SINGLE USER and verify that the system boots, you can fsck -p
> the disks, and mount them. The system should boot and run.
> 7. Come up multiuser but with any services necessary to the world
> offline. Some of your packages may blow up when started. If so,
> portupgrade SHOULD fix it, but this is not consistent. I had to
> manually dump the ports tree and rebuild a few installed ports due to
> what appear to be broken dependancies, but not many.
I put "ports" in rc.conf.local. Makes it simple to disable them all.
IIRC I deleted them all and did pkg_add -r, which is quick enough if you don't
have X. Save a listing first, of course.
> Postgresql 32-bit runs fine without recompilation after doing this. It
> is arguably preferrable to recompile; doing so requires a dump/restore
> of the data as the 32 and 64-bit code will NOT run off the same binary
> data store.
> Attempting to "make instalkernel" on an "in-place" basis resulted in a
> system that booted but failed immediately due to loader conflicts; there
> was no way to get the rest of the codeset loaded if you make that mistake.
> The "migration disk" approach appears to work fine.
ian j hart
More information about the freebsd-stable