Re: Upgrade from 32-bit to AMD-64?
On Wed, 18 Feb 2009, Karl Denninger wrote: KD I have been able to come up with a procedure that works. KD KD 1. Load a new hard disk with the 64-bit code. Perform a buildworld and KD buildkernel, and installkernel and installworld to this disk to verify that KD it will install and run. You now have a base disk to use for migration. KD KD 2. Make sure you have a backup (:-)) KD KD 3. Boot the migration hard disk as the system disk and mount the subject KD machine's disk drive(s) under /mnt. KD KD 4. Do make DESTDIR=/mnt installkernel and make DESTDIR=/mnt installworld KD KD 5. Shut down and disconnect migration disk. KD KD 6. Boot SINGLE USER and verify that the system boots, you can fsck -p the KD disks, and mount them. The system should boot and run. KD KD 7. Come up multiuser but with any services necessary to the world offline. KD Some of your packages may blow up when started. If so, portupgrade SHOULD KD fix it, but this is not consistent. I had to manually dump the ports tree KD and rebuild a few installed ports due to what appear to be broken KD dependancies, but not many. KD KD Postgresql 32-bit runs fine without recompilation after doing this. It is KD arguably preferrable to recompile; doing so requires a dump/restore of the KD data as the 32 and 64-bit code will NOT run off the same binary data store. KD KD Attempting to make instalkernel on an in-place basis resulted in a KD system that booted but failed immediately due to loader conflicts; there was KD no way to get the rest of the codeset loaded if you make that mistake. You can avoid most of these problems if you have copies of ld-elf (both 32-bit and 64-bit), and boot single user for /rescue; however, migration disk approach is much simpler. KD KD The migration disk approach appears to work fine. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade from 32-bit to AMD-64?
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 mandr...@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 mandr...@fark.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ... the future isMobile Goran Lowkrantz goran.lowkra...@ismobile.com System Architect, isMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Luleå, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade from 32-bit to AMD-64?
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 mandr...@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 mandr...@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 k...@denninger.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade from 32-bit to AMD-64?
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 mandr...@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 mandr...@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 ___ freebsd-stable@freebsd.org mailing list
Re: Upgrade from 32-bit to AMD-64?
Hi, When have done this, MySQL is OK but Berkley and PostgreSQL need dump/restore. /glz --On February 13, 2009 2:53:13 -0500 Mike Andrews mandr...@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 mandr...@fark.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ... the future isMobile Goran Lowkrantz goran.lowkra...@ismobile.com System Architect, isMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Luleå, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade from 32-bit to AMD-64?
Sure, it's possible, given sufficient toolchain knowledge, time, and skills, but it's not a sensible thing to do aside from experimentation and learning purposes. Theres an intermediate method between upgrading in place and doing a full re-install which si what I used when I did this. 1) Install amd64 onto a completely separate bootable drive (USB will do). On that one do a 'make buildworld', 'make buildkernel'. 2) Take down the machine you mant to upgrade - boot it off the USB drive. When booted off the USb drive mount the orignal '/' somewhere. 3) Do a 'make installkernel' and 'make installworld' with DESTDIR=/oldslah to install the 64 bit OS onto the old drive. I also rewrote the boot sectors on the old slash drive too. 4) Reboot - it should come up amd64 with the old config fine. I have done this a couple of time to convert from 32 to 64 bit installs. The beauty is that it preserves the config. I would note, however, that in my case I did de-install all the packages and re-installed them afterwards, so I was then running full 64 bit. but it works, and the machine is only down for a few minutes. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Upgrade from 32-bit to AMD-64?
I have a machine that can run either (proved, I can boot the AMD-64 release disk) Can I SOURCE UPGRADE from one to the other? That is, is it possible to do a make buildworld, make buildkernel and then make installkernel and wind up with AMD64 instead of the 32-bit code? Or must I reinstall? It APPEARS I can run most 32-bit code on a 64-bit system. Not all works, but most does. -- -- Karl Denninger k...@denninger.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade from 32-bit to AMD-64?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Karl, Karl Denninger wrote: I have a machine that can run either (proved, I can boot the AMD-64 release disk) Can I SOURCE UPGRADE from one to the other? That is, is it possible to do a make buildworld, make buildkernel and then make installkernel and wind up with AMD64 instead of the 32-bit code? Or must I reinstall? It APPEARS I can run most 32-bit code on a 64-bit system. Not all works, but most does. This is sort of doable but highly recommend you not to do that thing. The simplest way to do 32-bit to 64-bit upgrade would be to backup your data, install from scratch, then restore data; mixing 32-bit and 64-bit stuff together, especially without 32-bit stuff moved to the right place, is among the most terrible mess you wanted to avoid. Online upgrade can be done if you have your 64-bit world/kernel built and installed into a separate directory (i.e. make world kernel DESTDIR=/path/to/a/temp/place), then drop into single user mode, then tar then pipe to another tar to extract the whole thing to /, but this is really a foot, gun, shoot thing. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmU1gMACgkQi+vbBBjt66CLMQCfU77Cxz1YshGJb5C455GIGbXt vvMAn25KgUnJqEmQRbrxnxucD+CTdFyf =DiuA -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade from 32-bit to AMD-64?
Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Karl, Karl Denninger wrote: I have a machine that can run either (proved, I can boot the AMD-64 release disk) Can I SOURCE UPGRADE from one to the other? That is, is it possible to do a make buildworld, make buildkernel and then make installkernel and wind up with AMD64 instead of the 32-bit code? Or must I reinstall? It APPEARS I can run most 32-bit code on a 64-bit system. Not all works, but most does. This is sort of doable but highly recommend you not to do that thing. The simplest way to do 32-bit to 64-bit upgrade would be to backup your data, install from scratch, then restore data; mixing 32-bit and 64-bit stuff together, especially without 32-bit stuff moved to the right place, is among the most terrible mess you wanted to avoid. Online upgrade can be done if you have your 64-bit world/kernel built and installed into a separate directory (i.e. make world kernel DESTDIR=/path/to/a/temp/place), then drop into single user mode, then tar then pipe to another tar to extract the whole thing to /, but this is really a foot, gun, shoot thing. Cheers, - -- Xin LI delp...@delphij.net http://www.delphij.net/ H I was thinking something like this (I have the cvsup tree on the machine) 1. Compile into /usr/robj for amd64 (if I can figure out how to get make to do it - the obvious, MACHINE_ARCH=amd64, does not work - it barfs.) 2. Intentionally break the mirror (just in case) from the controller; I've now got a clean bootable drive if something goes wrong. 3. make installkernel (install new amd64 kernel) 4. Reboot Now, the question - will the 32-bit executables RUN under the 64-bit kernel under single-user so I can make installworld? Or do I get screwed instantly when I reboot? -- -- Karl Denninger k...@denninger.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade from 32-bit to AMD-64?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karl Denninger wrote: Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Karl, Karl Denninger wrote: I have a machine that can run either (proved, I can boot the AMD-64 release disk) Can I SOURCE UPGRADE from one to the other? That is, is it possible to do a make buildworld, make buildkernel and then make installkernel and wind up with AMD64 instead of the 32-bit code? Or must I reinstall? It APPEARS I can run most 32-bit code on a 64-bit system. Not all works, but most does. This is sort of doable but highly recommend you not to do that thing. The simplest way to do 32-bit to 64-bit upgrade would be to backup your data, install from scratch, then restore data; mixing 32-bit and 64-bit stuff together, especially without 32-bit stuff moved to the right place, is among the most terrible mess you wanted to avoid. Online upgrade can be done if you have your 64-bit world/kernel built and installed into a separate directory (i.e. make world kernel DESTDIR=/path/to/a/temp/place), then drop into single user mode, then tar then pipe to another tar to extract the whole thing to /, but this is really a foot, gun, shoot thing. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ H I was thinking something like this (I have the cvsup tree on the machine) 1. Compile into /usr/robj for amd64 (if I can figure out how to get make to do it - the obvious, MACHINE_ARCH=amd64, does not work - it barfs.) 2. Intentionally break the mirror (just in case) from the controller; I've now got a clean bootable drive if something goes wrong. 3. make installkernel (install new amd64 kernel) 4. Reboot Now, the question - will the 32-bit executables RUN under the 64-bit kernel under single-user so I can make installworld? Yes as long as you compiled COMPAT_FREEBSD32 you can run 32-bit executables under a 64-bit kernel, but, you need to be careful since the dynamic linker would have different name. Or do I get screwed instantly when I reboot? There is a reason we don't recommend doing that :) Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmU2swACgkQi+vbBBjt66CvjwCggpu439Rif7SzKnrOjpTFtCH1 CwUAnjRflrkmlrLlJvhCEJq5kUk8nPGd =rwVa -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade from 32-bit to AMD-64?
Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karl Denninger wrote: Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Karl, Karl Denninger wrote: I have a machine that can run either (proved, I can boot the AMD-64 release disk) Can I SOURCE UPGRADE from one to the other? That is, is it possible to do a make buildworld, make buildkernel and then make installkernel and wind up with AMD64 instead of the 32-bit code? Or must I reinstall? It APPEARS I can run most 32-bit code on a 64-bit system. Not all works, but most does. This is sort of doable but highly recommend you not to do that thing. The simplest way to do 32-bit to 64-bit upgrade would be to backup your data, install from scratch, then restore data; mixing 32-bit and 64-bit stuff together, especially without 32-bit stuff moved to the right place, is among the most terrible mess you wanted to avoid. Online upgrade can be done if you have your 64-bit world/kernel built and installed into a separate directory (i.e. make world kernel DESTDIR=/path/to/a/temp/place), then drop into single user mode, then tar then pipe to another tar to extract the whole thing to /, but this is really a foot, gun, shoot thing. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ H I was thinking something like this (I have the cvsup tree on the machine) 1. Compile into /usr/robj for amd64 (if I can figure out how to get make to do it - the obvious, MACHINE_ARCH=amd64, does not work - it barfs.) 2. Intentionally break the mirror (just in case) from the controller; I've now got a clean bootable drive if something goes wrong. 3. make installkernel (install new amd64 kernel) 4. Reboot Now, the question - will the 32-bit executables RUN under the 64-bit kernel under single-user so I can make installworld? Yes as long as you compiled COMPAT_FREEBSD32 you can run 32-bit executables under a 64-bit kernel, but, you need to be careful since the dynamic linker would have different name. Or do I get screwed instantly when I reboot? There is a reason we don't recommend doing that :) Cheers, - -- Xin LI delp...@delphij.net http://www.delphij.net/ ROFL! Ok, I get it. I'm asking to get hosed as soon as I reboot. I CAN reload the machine but it would take the machine out of service for MUCH LESS TIME if I could do it this way; a full reload is going to take a couple of hours, where I can do it that way in ~5-10 minutes of downtime. Of course if its going to blow up. 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. -- -- Karl Denninger k...@denninger.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade from 32-bit to AMD-64?
On Feb 12, 2009, at 5:31 PM, Karl Denninger wrote: I have a machine that can run either (proved, I can boot the AMD-64 release disk) Can I SOURCE UPGRADE from one to the other? That is, is it possible to do a make buildworld, make buildkernel and then make installkernel and wind up with AMD64 instead of the 32-bit code? Or must I reinstall? Sure, it's possible, given sufficient toolchain knowledge, time, and skills, but it's not a sensible thing to do aside from experimentation and learning purposes. The recommended course is to determine the platform which best suits your requirements and the available hardware: ie, are you doing database stuff, SSL, or arbitrary-precision math which would really benefit from the 64-bit architecture; does the machine have more than 3 GB of RAM; does the machine have hardware (like a graphics card) which has better 32-bit drivers, etc. It APPEARS I can run most 32-bit code on a 64-bit system. Not all works, but most does. Right, the vast majority of 32-bit binaries should work just fine on a 64-bit platform Regards, -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade from 32-bit to AMD-64?
-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. My personal suggestion is that you do an experiment on another box (64-bit capable) to make sure that the data would work, this never hurts and avoids surprises (you do want 64-bit compile of your database application since you want to take full advantage of 64-bit OS); also, just like all upgrades, full backup is advised. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmU37AACgkQi+vbBBjt66BzlwCfUuQuTY8rXnhE/T1K9BNIZ7bi j9sAoJiPJApQrX5Gwd4kfFWoiGfQs44g =0oRk -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade from 32-bit to AMD-64?
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. My personal suggestion is that you do an experiment on another box (64-bit capable) to make sure that the data would work, this never hurts and avoids surprises (you do want 64-bit compile of your database application since you want to take full advantage of 64-bit OS); also, just like all upgrades, full backup is advised. Cheers, - -- Xin LI delp...@delphij.net http://www.delphij.net I already know I have to dump the database and then reload it - I attempted to migrate the disk structure across (which would have saved even more time) and got instantaneously hosed, presumably due to internal data type length differences. This little upgrade is going to take a while; sounds like the best approach is to load a new box, shut down the dbms to connections and dump/pipe it over, then physically swap the machines. Thanks. -- -- Karl Denninger k...@denninger.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade from 32-bit to AMD-64?
On Thu, 12 Feb 2009 21:01:38 CST Karl Denninger k...@denninger.net 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. My personal suggestion is that you do an experiment on another box (64-bit capable) to make sure that the data would work, this never hurts and avoids surprises (you do want 64-bit compile of your database application since you want to take full advantage of 64-bit OS); also, just like all upgrades, full backup is advised. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net I already know I have to dump the database and then reload it - I attempted to migrate the disk structure across (which would have saved even more time) and got instantaneously hosed, presumably due to internal data type length differences. This little upgrade is going to take a while; sounds like the best approach is to load a new box, shut down the dbms to connections and dump/pipe it over, then physically swap the machines. May be you can install the 64 bit world from an install CD to a 2 to 4GB USB flash drive, reboot to the 64 bit kernel set root on the flash drive, mount your original filesystems under /mnt, make and install with DESTDIR=/mnt, mergemaster -D /mnt and reboot? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade from 32-bit to AMD-64?
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 mandr...@fark.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
