Upgrade from 32-bit to AMD-64?

[ian j hart]

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> 
wrote:
> >>> 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
> migration.
>
> 2. Make sure you have a backup (:-))

Not optional. I broke the mirror and took a backup and I actually checked the 
backup.

>
> 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
> installworld"
>
> 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