OK, screw 32-bit PAE, I'm going to switch to 64-bit Linux. (For reasons left as a teaser to read the upcoming newsletter...)
I'm going to attempt an in-place upgrade F19 to F20, similar to what is outlined here: http://archive09.linux.com/feature/123800
It sounds do-able. I'm more than used to doing wacky pseudo-supported upgrade procedures; I'm running many boxes that have been upgraded from Fedora 3 all the way through to F19 via yum (headless, via network) only; and those boxes have also been hw upgraded a few times each! Try that with Windows (and the end result is clean and trim, not bloated)!
I do have a couple of questions I can't seem to find answers to:
1. Will /usr/local/bin stuff I've compiled myself (not too much), which are obviously 32-bit binaries, run on my new 64 system?
2. If #1 requires 32-bit libraries, can Fedora 64-bit have both 32 and 64 libraries installed?
3. Will I lose flash?
4. How many programs am I running that (as per link above) use binary arch-dependent data files? The article mentions db files (I use only MySQL/Maria), but I don't mind doing a full text dump/restore. But what else might use them? I'm a bit scared that systemd's new journal logs might also cause problems. What else? (Good thing UNIX is so text-based.)
Why do I not want to do a wipe/reinstall? a) I'm good at getting the wacky option to work, generally. b) I've configured the !*%@@ out of my box and to resetup everything to the way I have it would take way more than the 1 day I am guessing the upgrade method will take. c) #b includes the bazillion daemons I run (and would require reconfig / data file migration)
Thanks guys.
On 25/08/2014 11:05 PM, Trevor Cordes wrote:
OK, screw 32-bit PAE, I'm going to switch to 64-bit Linux. (For reasons left as a teaser to read the upcoming newsletter...)
I'm going to attempt an in-place upgrade F19 to F20, similar to what is outlined here: http://archive09.linux.com/feature/123800
Good luck with that... :)
It sounds do-able. I'm more than used to doing wacky pseudo-supported upgrade procedures; I'm running many boxes that have been upgraded from Fedora 3 all the way through to F19 via yum (headless, via network) only; and those boxes have also been hw upgraded a few times each! Try that with Windows (and the end result is clean and trim, not bloated)!
I do have a couple of questions I can't seem to find answers to:
- Will /usr/local/bin stuff I've compiled myself (not too much), which
are obviously 32-bit binaries, run on my new 64 system?
Yes, provided they are either statically linked or you have the required 32-bit libraries (of compatible versions)...
- If #1 requires 32-bit libraries, can Fedora 64-bit have both 32 and
64 libraries installed?
Absolutely. That's been the case pretty much since x86_64 support was added to Fedora and RHEL, I believe. (With early 64-bit distros, you had the reverse problem that it seemed to load most of the 32-bit libraries as well, whether you needed them or not, which made for a lot of bloat.)
- Will I lose flash?
Adobe Flash should continue to work, provided you have all the 32-bit libraries it needs. If you've installed it via the Adobe RPM repository, the dependencies should (in theory) keep the needed libraries around (hopefully without creating an upgrade dependency conflict). You'll also want to keep a 32-bit version of Firefox around, as the Flash plugin won't work in the 64-bit version.
(I've given up on trying to support Flash on any of my 64-bit installations.)
- How many programs am I running that (as per link above) use
binary arch-dependent data files? The article mentions db files (I use only MySQL/Maria), but I don't mind doing a full text dump/restore. But what else might use them? I'm a bit scared that systemd's new journal logs might also cause problems. What else? (Good thing UNIX is so text-based.)
Not sure how many other arch-dependent data files you're likely to encounter, in practice. Your guess is as good as mine...
Why do I not want to do a wipe/reinstall? a) I'm good at getting the wacky option to work, generally.
My success has been more mixed. I don't think I've ever attempted an in-place upgrade from 32 to 64-bit distro, though.
b) I've configured the !*%@@ out of my box and to resetup everything to the way I have it would take way more than the 1 day I am guessing the upgrade method will take.
I'm with you on that one! I've always found that to be the biggest pain about complete reinstalls. (You think you've got a complete set of config files for all your customisations, only to find that you've either missed a few, or something has been completely redesigned and your old config is only useful as a rough guide for hand-editing the new one.)
c) #b includes the bazillion daemons I run (and would require reconfig / data file migration)
Not sure how (b) and (c) are different...
Thanks guys.
You're welcome, and good luck!
On 2014-08-26 Gilbert E. Detillieux wrote:
Good luck with that... :)
Oops, doh! Turns out F20 (actually as of F17?) the DVD install method no longer contains an "upgrade" option. As in anaconda can't do it anymore. That removes the "offline" option which makes changing arches easier/possible.
Instead they want one to use fedup, which, from what I can tell, appears to be nothing more than a glorified "yum upgrade". It strikes me as odd, as fedup provides a new specialized initrd but then says it boots into your system "mostly" as normal so it can mount all your disks, etc. Then does the upgrade while the system is all running. Uh, ok.
Anyhow, I see ZERO instructions on google on tricking fedup to switch 32->64, and the few people who have asked have gotten a firm "NO, DON'T BE INSANE" response. I'm not sure I want to be the very first to try!
(One would think you could possibly install a 64 kernel on my F19 system with 32b userland, boot into that, trick fedup or yum into thinking it's 64-bit, etc. But perhaps that would break badly as whilst yum is running it'll pull the rug out on libraries, programs, etc, by changing them to 64 on the fly. Who knows, maybe it would work, maybe it would blow up badly.)
I'm with you on that one! I've always found that to be the biggest pain about complete reinstalls. (You think you've got a complete set of config files for all your customisations, only to find that you've
Sigh, it looks like I may be forced into a wipe/reinstall. I've made dd image backups of my drives so I may still give yum or fedup a stab. Nothing to lose, really.
I'm always shocked yum upgrade works at all, even when arch remains the same, so perhaps if it can survive the carpet-yanking there, it can survive it when going 64. Who knows.
Thanks for the help.
If you're starting from scratch, I can't speak highly enough about configuration management tools like Chef, Puppet, Ansible, cfengine, etc. The time spent getting up to speed will pay itself back many times over. Reinstalls become a non event. Finding out "what changed" isn't an issue. You can spin up new boxes, even if there are customizations to each one.
As an aside, you don't need to start from scratch to make use of config management. If you can just start off managing your motd and ntpd on existing boxes, you'll soon start finding reasons to bring stuff under config management rather than one offs.
http://ertw.com/chef-walberg-winnipegrb/ is a presentation I gave at WinnipegRB about some of the work I was doing with Chef at the time. While the demo is obviously missing there are some code snippets at the end that show what you can do with the tools.
Sean
On Tue, Aug 26, 2014 at 4:00 PM, Trevor Cordes trevor@tecnopolis.ca wrote:
On 2014-08-26 Gilbert E. Detillieux wrote:
Good luck with that... :)
Oops, doh! Turns out F20 (actually as of F17?) the DVD install method no longer contains an "upgrade" option. As in anaconda can't do it anymore. That removes the "offline" option which makes changing arches easier/possible.
Instead they want one to use fedup, which, from what I can tell, appears to be nothing more than a glorified "yum upgrade". It strikes me as odd, as fedup provides a new specialized initrd but then says it boots into your system "mostly" as normal so it can mount all your disks, etc. Then does the upgrade while the system is all running. Uh, ok.
Anyhow, I see ZERO instructions on google on tricking fedup to switch 32->64, and the few people who have asked have gotten a firm "NO, DON'T BE INSANE" response. I'm not sure I want to be the very first to try!
(One would think you could possibly install a 64 kernel on my F19 system with 32b userland, boot into that, trick fedup or yum into thinking it's 64-bit, etc. But perhaps that would break badly as whilst yum is running it'll pull the rug out on libraries, programs, etc, by changing them to 64 on the fly. Who knows, maybe it would work, maybe it would blow up badly.)
I'm with you on that one! I've always found that to be the biggest pain about complete reinstalls. (You think you've got a complete set of config files for all your customisations, only to find that you've
Sigh, it looks like I may be forced into a wipe/reinstall. I've made dd image backups of my drives so I may still give yum or fedup a stab. Nothing to lose, really.
I'm always shocked yum upgrade works at all, even when arch remains the same, so perhaps if it can survive the carpet-yanking there, it can survive it when going 64. Who knows.
Thanks for the help. _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-
Gilbert E. Detillieux -
Sean Walberg -
Trevor Cordes