Upgrade from 32-bit to AMD-64?

[Karl Denninger]

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.

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 (:-))

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.

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.

-- 
--
Karl Denninger
karl at denninger.net