Walter Haidinger wrote:
Hi!
Is there a recommended way to switch an _existing_ 32-bit 10.3 installation to
64-bit x86_64?
A "simple" upgrade with Yast from 10.3 installmedia leads to lots of dependency problems when resolving the packages.
Any way to prevent a new installation?
How about replacing the installed packages with the 64-bit versions?
Regards, Walter
---
Being of similar perversity, I'm working toward the same thing --
I did a live update of Suse9.3 up to suse10.[23] -- that isn't
supported either ((1) not supported upgrading more than 1 version and
(2) not supported upgrading 'live')....
I figure for my next 'trick', I'd try upgrading
a 10.2-ia32 ->10.[23]-x86-64.
I say "10.[23]" because there were a few packages in 10.3 that
caused problems, so I back-graded them to 10.2 (which I new was working
on another system). They were mostly NFS related (packages got renamed
between .2 & .3, making it all the more fun.
But for my 1st step, I wanted to get my kernel to 64-bits.
Rationale: 64-bit kernel is supposed to run current 32-bit packages
(or 64-bit packages).
As an "aside", my personal view (subject to quantum uncertainty when
examined closely) is that if a package exists in 32 and 64 bit formats
and both are "supposed to run", I'd consider it a "bug" if the on-disk
formats conflicted -- that's certainly a recipe for disaster since in
if you use any 3rd party apps that are currently 32-bit and then upgrade
to 64-bit, it'd be a sad vendor who didn't support portability. I'm
sure not all apps are "endian-clean", but anyone who wants to support
linux on multiple platforms has probably already converted their apps
to be "endian-clean", at least in their ondisk format, but likely at
the source level as well. OTOH, though, I wouldn't bet production
machines on it...
Anyway -- I haven't gotten any further than the 1st step.
I just booted the x86-64 suse10.3 kernel on a machine that has
suse10.2-ia32 installed.
Most everything came up -- one network card didn't come up,
but the primary card did, so I can ssh into it. It would be 'neat'
to make the machine "dual boot", so booting from the 64-bit kernel
would automatically setup paths and such to use 64-bit binaries if
available, but booting from the 32-bit kernel would use the 32-bit
binaries. That way I could maintain a dual purposed machine.
Perhaps I'll never have need to boot 32-bit after upgrading to
64-bit, but I'd prefer not to burn bridges.
Will have to see what happens next when installing packages.
(I guess I could install everything into an alternate root...egads, I
could really make this complicated).
It would be great if SuSE considered supporting "live"
installs. I've only asked for that since the suse7.x days. I don't
have a convenient "console" for all my machines -- I use ssh to access them.
When I did the suse9.2->10.3 on another machine, I mounted the packages
via NFS and used NFS as the source for the new RPM's. Went faster in
some ways, but slower in others as I did many of the packages by hand.
After I was fairly sure I had the base packages installed, I was able to
upgrade most of the rest via scriptlets...
One rpm line shows 55 rpm packages I had to install at same
time to satisfy interdependencies.
The more "interesting" problems arise when you need 2 versions
of the same rpm -- I just installed both versions (without "update"),
so both versions of a needed library file were present at the same
time (this information was gleaned from getting "prereq" errors from
uninstalled libs (which (I added to install line), which then changed
to prereqs for the previous lib version based on already installed packages.
In those cases, I temporarily installed both, or, occasionally, copied
the needed lib to a tmpdir, installed the upgrade (which deleted the
old lib, breaking 'something'), then copied the oldlib, manually back
into the lib dir and re-running "/etc/boot.ldconfig restart". Note --
any libs added manually (via copy), or removed manually required a
manual rerun of "boot.ldconfig".
I'm "practicing" on test systems -- but I'd like to upgrade
(suse9.3->10.[23]) my main net-proxy and backup server w/o taking it
off-line, *eventually*. If I take it off line and upgrade, I then
have to go through all the config files while it is "offline" in order
for it to be back up in service. That means no-external network
access until it's done and working in uncomfortable quarters, at least
until I get it back up on the network.
If everything goes smoothly, I suppose it would be an hour
or two depending on installation source. However, I have yet to have
everything go smoothly during a full upgrade, but since I don't
upgrade all of my machines every 4-6 months, I'm not current on
the "update-treadmill", so updates are usually unsupported anyway.
As it is, I'm 'incentivized' to make the live-update work, since with
a live-update, I can usually upgrade a few packages, fix any breakages
and then go on...
The system I'm upgrading from ia32->x86_64, (and suse10.2
->suse10.3), I installed with the 10.3 kernel: the x86_64 suse10.2
kernel conflicts in name with the ia32-suse10.2 kernel (so it would
involve overwriting the working suse kernel from 10.2). I *could*
have done this since my default boot kernel is 2.6.23.1, an unpatched
vanilla kernel from kernel.org), but I didn't want to eliminate
(overwrite) the previous 'suse-default' until I was sure new kernel
would work for a while.
Just made sure the required dependencies were loaded (2
app-armor rpms), then added "--ignorearch" to the "rpm -ihv"
line and it installed. Added it to 'grub' and it booted first time
I spelled it right! :-)
Anyway -- officially, not supported, but in case you are
into playing... :-)
L
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
