[opensuse-factory] Is the upgrade from 32 bits to 64 bit supported? Question for devs O:-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I'm asking here a question not related to factory directly, because I want to reach the devs. You can reply on opensuse list instead if you prefer.
To keep it short (longer post in the opensuse list), I'm attempting to upgrade from 11.0 to 11.2 (32 bits) using the retail DVD, wich turns out it has only the x64 version. It offers to upgrade to 64 bit the 32 bit install:
The architecture of the system installed in the selected partition is different from the one of this product" [continue] [cancel]
I said "continue", then I checked the package list. As far as I could see, it intended to replace all packages with those corresponding to the 64 bits version. If this works, fine... but I was afraid, and I cancelled. Not because risking data (it is a copy), but because of possible waste of time. I thought I'd better RFC.
Has anybody done this, an upgrade from 32 to 64 bits? Does it work? Is it "supported"?
- -- Cheers / Saludos,
Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar))
On Sun, 07 Feb 2010 22:45:22 +0100 "Carlos E. R." carlos.e.r@opensuse.org wrote:
Has anybody done this, an upgrade from 32 to 64 bits? Does it work? Is it "supported"?
I guess it is not officially supported, but If you know what you are doing, you could probabyly make it work.
The problem is, IIUC, that you need a system that's halfway consistent and capable of running binaries throughout the update. As soon as an important (to the rest of the update process) binary is updated to 64 bit, you are screwed.
I guess you could work around that by upgrading important packages upfront: * kernel (the 64bit kernel should be able to run a 32bit userland without changes) * glibc (after rebooting into the 64bit kernel) and corresponding glibc-32bit compat libraries * maybe rpm
After that, it might work. Keep us posted on your success. I might actually try this in a virtual machine one day, sounds interesting ;)
have fun,
seife
Hi,
On Mon, 8 Feb 2010, Stefan Seyfried wrote:
On Sun, 07 Feb 2010 22:45:22 +0100 "Carlos E. R." carlos.e.r@opensuse.org wrote:
Has anybody done this, an upgrade from 32 to 64 bits? Does it work? Is it "supported"?
I guess it is not officially supported, but If you know what you are doing, you could probabyly make it work.
The problem is, IIUC, that you need a system that's halfway consistent and capable of running binaries throughout the update. As soon as an important (to the rest of the update process) binary is updated to 64 bit, you are screwed.
I guess you could work around that by upgrading important packages upfront:
- kernel (the 64bit kernel should be able to run a 32bit userland
without changes)
- glibc (after rebooting into the 64bit kernel) and corresponding
glibc-32bit compat libraries
- maybe rpm
After that, it might work. Keep us posted on your success. I might actually try this in a virtual machine one day, sounds interesting ;)
It should work without any special preparations if you boot "from outside" to do the update 32 -> 64.
Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)
On Mon, 8 Feb 2010 00:26:18 +0100 (CET) Eberhard Moenkeberg emoenke@gwdg.de wrote:
It should work without any special preparations if you boot "from outside" to do the update 32 -> 64.
Of course. But that's obvious. And boring.
:-)
Hi,
On Mon, 8 Feb 2010, Stefan Seyfried wrote:
On Mon, 8 Feb 2010 00:26:18 +0100 (CET) Eberhard Moenkeberg emoenke@gwdg.de wrote:
It should work without any special preparations if you boot "from outside" to do the update 32 -> 64.
Of course. But that's obvious. And boring.
:-)
Shine on, you crazy diamond. ;-)) Really. Do it.
Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2010-02-08 00:26, Eberhard Moenkeberg wrote:
Hi,
On Mon, 8 Feb 2010, Stefan Seyfried wrote:
On Sun, 07 Feb 2010 22:45:22 +0100 "Carlos E. R." <> wrote:
Has anybody done this, an upgrade from 32 to 64 bits? Does it work? Is it "supported"?
I guess it is not officially supported, but If you know what you are doing, you could probabyly make it work.
The problem is, IIUC, that you need a system that's halfway consistent and capable of running binaries throughout the update. As soon as an important (to the rest of the update process) binary is updated to 64 bit, you are screwed.
...
After that, it might work. Keep us posted on your success. I might actually try this in a virtual machine one day, sounds interesting ;)
I'd be interested in knowing if it "should" work before I attempt it, instead of being the guinea pig. Hopefully from the devs that designed the upgrade process ;-)
It should work without any special preparations if you boot "from outside" to do the update 32 -> 64.
Did I say that it is the retail DVD? Yes, the update runs from the DVD live system on a "dead", aka stopped, system, so that is not an issue. I'm not doing a "zypper dup" procedure, that definitely would not work (IMO).
You see, it has been told here, for years, that this upgrade (32-->64) is impossible. But the dvd message box doesn't say that... :-? So I thought it might work now.
In fact, the retail 11.2 DVD only contains the x64 version, that's why I discovered this. :-o
- -- Cheers / Saludos,
Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar))
Hi,
On Mon, 8 Feb 2010, Carlos E. R. wrote:
On 2010-02-08 00:26, Eberhard Moenkeberg wrote:
On Mon, 8 Feb 2010, Stefan Seyfried wrote:
On Sun, 07 Feb 2010 22:45:22 +0100 "Carlos E. R." <> wrote:
Has anybody done this, an upgrade from 32 to 64 bits? Does it work? Is it "supported"?
I guess it is not officially supported, but If you know what you are doing, you could probabyly make it work.
The problem is, IIUC, that you need a system that's halfway consistent and capable of running binaries throughout the update. As soon as an important (to the rest of the update process) binary is updated to 64 bit, you are screwed.
...
After that, it might work. Keep us posted on your success. I might actually try this in a virtual machine one day, sounds interesting ;)
I'd be interested in knowing if it "should" work before I attempt it, instead of being the guinea pig. Hopefully from the devs that designed the upgrade process ;-)
It should work without any special preparations if you boot "from outside" to do the update 32 -> 64.
Did I say that it is the retail DVD? Yes, the update runs from the DVD live system on a "dead", aka stopped, system, so that is not an issue. I'm not doing a "zypper dup" procedure, that definitely would not work (IMO).
You see, it has been told here, for years, that this upgrade (32-->64) is impossible. But the dvd message box doesn't say that... :-? So I thought it might work now.
In fact, the retail 11.2 DVD only contains the x64 version, that's why I discovered this. :-o
Nice. Please do it and report here. I'm sure it works, at least it should this way. If you will experience show stoppers, they have to get solved.
If your system gets unusable, just do the procedure again and have a look at "not higher" new version numbers of packets than before, or inspect "rpm -qa --last" for the oldest packages and update them.
Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2010-02-08 01:17, Eberhard Moenkeberg wrote:
Hi,
On Mon, 8 Feb 2010, Carlos E. R. wrote:
In fact, the retail 11.2 DVD only contains the x64 version, that's why I discovered this. :-o
Nice. Please do it and report here. I'm sure it works, at least it should this way. If you will experience show stoppers, they have to get solved.
If your system gets unusable, just do the procedure again and have a look at "not higher" new version numbers of packets than before, or inspect "rpm -qa --last" for the oldest packages and update them.
Now that I think, I have some programs in that install that will fail if I upgrade to x64, because they were compiled a few years ago, and no longer compile, because the gcc compiler got a lot more finicky with the warnings it would accept. It has been impossible to recompile for a long time now, so I kept using the old binary. They are programs not actively developed (for Fidonet: Golded+ and some more).
I might have to use those inside a vmware client running an older suse version. Or is it possible to run 32 bits apps in an x64 oS?
- -- Cheers / Saludos,
Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar))
Hi,
On Mon, 8 Feb 2010, Carlos E. R. wrote:
On 2010-02-08 01:17, Eberhard Moenkeberg wrote:
On Mon, 8 Feb 2010, Carlos E. R. wrote:
In fact, the retail 11.2 DVD only contains the x64 version, that's why I discovered this. :-o
Nice. Please do it and report here. I'm sure it works, at least it should this way. If you will experience show stoppers, they have to get solved.
If your system gets unusable, just do the procedure again and have a look at "not higher" new version numbers of packets than before, or inspect "rpm -qa --last" for the oldest packages and update them.
Now that I think, I have some programs in that install that will fail if I upgrade to x64, because they were compiled a few years ago, and no longer compile, because the gcc compiler got a lot more finicky with the warnings it would accept. It has been impossible to recompile for a long time now, so I kept using the old binary. They are programs not actively developed (for Fidonet: Golded+ and some more).
I might have to use those inside a vmware client running an older suse version. Or is it possible to run 32 bits apps in an x64 oS?
Of course 32-bit applications will run upon 64-bit architecture.
If you are compiling yourself and 64-bit does not compile, you have gcc switches like -m i386.
Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2010-02-08 02:18, Eberhard Moenkeberg wrote:
Hi,
On Mon, 8 Feb 2010, Carlos E. R. wrote:
Now that I think, I have some programs in that install that will fail if I upgrade to x64, because they were compiled a few years ago, and no longer compile, because the gcc compiler got a lot more finicky with the warnings it would accept. It has been impossible to recompile for a long time now, so I kept using the old binary. They are programs not actively developed (for Fidonet: Golded+ and some more).
I might have to use those inside a vmware client running an older suse version. Or is it possible to run 32 bits apps in an x64 oS?
Of course 32-bit applications will run upon 64-bit architecture.
They do? I have no experience on 64 bits. I'll have to try this app in this test partition.
If you are compiling yourself and 64-bit does not compile, you have gcc switches like -m i386.
Ah, noted, but unfortunately, they are old apps that will no way compile, not even on 32 bits 11.0: they produce tons of syntax warnings. I'm forced to use the binary I compiled years ago on 7.3 or thereabouts. I also need some -compat versions of libraries.
I need to investigate this.
- -- Cheers / Saludos,
Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar))
Hi Carlos,
* Carlos E. R. carlos.e.r@opensuse.org [Feb 07. 2010 22:45]:
Has anybody done this, an upgrade from 32 to 64 bits? Does it work? Is it "supported"?
yes, this is supported.
But you have to boot from the installation medium in order to run the upgrade with a 64bit kernel running.
Thus a 'zypper dup' from the old system won't work because its still a 32bit kernel running.
Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
On Mon, 8 Feb 2010 01:17:04 +0100 (CET) Eberhard Moenkeberg emoenke@gwdg.de wrote:
Nice. Please do it and report here. I'm sure it works, at least it should this way.
Actually, the more I think about it, I'm not sure if it makes such a big difference if the system is "live" or "offline" updated. The RPM postinstall scripts still run in a chroot()ed environment, don't they?
If you will experience show stoppers, they have to get solved.
I agree, but I am not the product manager :)
OTOH, similar problems could be experienced during an update to a completely incompatible libc version (not likely to happen, but still...) and similar, so it is a good Idea to solve them.
It might be hard to impossible to implement the "online" upgrade to an incompatible architecture (x86_64->i386 or x86->ppc), but "offline" should be possible (the new installation also must cope with the "no compatible libc present" problem for bootstrapping).
I really have to try this ;)
Thus a 'zypper dup' from the old system won't work because its still a 32bit kernel running.
It's not only the 32bit kernel. Also 32-bit rpm might refuse to install 64-bit packages.
Am Montag 08 Februar 2010 schrieb Stefan Seyfried:
On Mon, 8 Feb 2010 00:26:18 +0100 (CET)
Eberhard Moenkeberg emoenke@gwdg.de wrote:
It should work without any special preparations if you boot "from outside" to do the update 32 -> 64.
Of course. But that's obvious. And boring.
No, it's not "of course". You can't replace the glibc and expect rpms still being able to call bash to do their %post scripts.
This _can_ work, but only with special care.
Greetings, Stephan
Am Montag 08 Februar 2010 schrieb Klaus Kaempf:
Hi Carlos,
- Carlos E. R. carlos.e.r@opensuse.org [Feb 07. 2010 22:45]:
Has anybody done this, an upgrade from 32 to 64 bits? Does it work? Is it "supported"?
yes, this is supported.
Define "supported". We will WONTFIX all bug reports about it and it's not tested at all. I wouldn't call that "supported".
Greetings, Stephan
On Mon, Feb 08, 2010 at 08:21:48AM +0100, Klaus Kaempf wrote:
- Carlos E. R. carlos.e.r@opensuse.org [Feb 07. 2010 22:45]:
Has anybody done this, an upgrade from 32 to 64 bits? Does it work? Is it "supported"?
yes, this is supported.
But you have to boot from the installation medium in order to run the upgrade with a 64bit kernel running.
And it works even with a remote upgrade. The network installation instructions from http://en.opensuse.org/Network_Install work well.
Be extra careful with the remote upgrades if you have more than one NIC. In this case you have to force the order of the load of the NIC modules to get the correct ethX names fitting to your configuration. If they aren't all supported by the same driver.
Lars
On Mon, 8 Feb 2010 10:40:22 +0100 Stephan Kulow coolo@novell.com wrote:
No, it's not "of course". You can't replace the glibc and expect rpms still being able to call bash to do their %post scripts.
This _can_ work, but only with special care.
Yes, but I'd argue that this special care has to be applied anyway. Because your sentence is true, even without an architecture change :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2010-02-08 at 14:30 +0100, Stefan Seyfried wrote:
On Mon, 8 Feb 2010 10:40:22 +0100 Stephan Kulow <> wrote:
No, it's not "of course". You can't replace the glibc and expect rpms still being able to call bash to do their %post scripts.
This _can_ work, but only with special care.
Yes, but I'd argue that this special care has to be applied anyway. Because your sentence is true, even without an architecture change :)
I was talking about an upgrade "the traditional way", ie, booting from the install DVD. No way would I attempt of upgrading this using zypper - I'm not that adventurous ;-)
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2010-02-08 at 09:15 +0100, Stefan Seyfried wrote:
On Mon, 8 Feb 2010 01:17:04 +0100 (CET) Eberhard Moenkeberg <> wrote:
Nice. Please do it and report here. I'm sure it works, at least it should this way.
Actually, the more I think about it, I'm not sure if it makes such a big difference if the system is "live" or "offline" updated. The RPM postinstall scripts still run in a chroot()ed environment, don't they?
If you will experience show stoppers, they have to get solved.
I agree, but I am not the product manager :)
Uch!
In any case, I would not use zypper, but booting from the install DVD, so the running kernel during the upgrade would be 64 bit.
OTOH, similar problems could be experienced during an update to a completely incompatible libc version (not likely to happen, but still...) and similar, so it is a good Idea to solve them.
It might be hard to impossible to implement the "online" upgrade to an incompatible architecture (x86_64->i386 or x86->ppc), but "offline" should be possible (the new installation also must cope with the "no compatible libc present" problem for bootstrapping).
I really have to try this ;)
I'm very tempted to try it. Several people either encouraged me to try, or say they have actually done it. However, Kulow saying that any bugzilla on this will be "wontfixed" automatically, is a pail of cold water on our illusions.
You see, I'd like to try, I'm not risking data (it is a backup install). I would happily ask for help in the list if required, and report confirmed issues on bugzilla, for improvement next time, but knowing beforehand that they will be ignored... it is very discouraging.
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2010-02-08 at 10:41 +0100, Stephan Kulow wrote:
Am Montag 08 Februar 2010 schrieb Klaus Kaempf:
Hi Carlos,
- Carlos E. R. <> [Feb 07. 2010 22:45]:
Has anybody done this, an upgrade from 32 to 64 bits? Does it work? Is it "supported"?
yes, this is supported.
Define "supported". We will WONTFIX all bug reports about it and it's not tested at all. I wouldn't call that "supported".
Ugh. This is very discouraging. Actually, your very answer poses one or two bugzilla reports; I'll explain.
(Note: I'm in no way attempting to use zypper upgrade. I'm booting from the retail DVD, the classical upgrade method, or "dead" upgrade)
1) I'm booting from the retail DVD, which says it supports both 32 and 64 bits versions. However, in a 64 bit machine I see no way to select a 32 bit install or upgrade.
2) The retail DVD, when asked to upgrade possible installs, does not automatically propose to upgrade the existing 32 bit installation (it only sees the 64 bit install). When manually pointed to the partition containing the 32 bit install, it does not propose to upgrade to 11.2-32 bit.
2.bis) Instead, when pointed to the partition containing the 32 bit 11.0 install, it actually proposes to upgrade to 11.2-64 bit. The message box says:
| The architecture of the system installed in the | | selected partition is different from the one of | | this product" [continue] [cancel] |
If I press "continue", it goes trough the upgrade motions; I did not go on, I cancelled in order to ask here first. Several people (some in private or in the other list) have said they did it sucesfully.
The issue is, if this is not supported at all, the install DVD should warn the user about this, and then give the option to continue in 32 bit mode, or explain how to boot the DVD in 32 bit mode to retry.
As it is, the retail DVD behaviour implies that upgrade to 64 bit is the only possible procedure.
I'd propose that the message be modified. I has to either say that it is not possible, or that it is not supported at all (and explain how to switch to a 32 bit upgrade). I would also like you (suse) decide to "mildly" support the procedure, in low priority mode, at least, and perhaps point to a wiki page with cautions, pitfalls, sugestions, alternatives, etc.
The thing is, people have done this upgrade sucesfully. It is a very interesting posibility, even if not for the inexperienced. I'm not requesting full support, that is not possible, but at least, some help.
Either that, or completely discourage the procedure in the message box. As it is, suse devs have designed the DVD to do or attempt this upgrade, that is clear. How far, that is not clear.
:-)
After all, zypper live upgrade has been possible for a long time, but not officially suported. However, bugzillas on it were accepted. I wrote some! Couldn't the same be the case for the 32->64 process? It will become more interesting in the future.
- -- Cheers, Carlos E. R.
On Mon, 8 Feb 2010, Carlos E. R. wrote:
After all, zypper live upgrade has been possible for a long time, but not officially suported. However, bugzillas on it were accepted. I wrote some! Couldn't the same be the case for the 32->64 process? It will become more interesting in the future.
I think that is a fair request. No guarantee that issues popping up will be fixed (or can with reasonable effort, think database formats), but having a look as opposed to an automated WONTFIX appears reasonable.
If you or someone else is giving it a try can summarize on the Wiki, that would be nice.
Gerald
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2010-02-15 at 16:21 +0100, Gerald Pfeifer wrote:
On Mon, 8 Feb 2010, Carlos E. R. wrote:
After all, zypper live upgrade has been possible for a long time, but not officially suported. However, bugzillas on it were accepted. I wrote some! Couldn't the same be the case for the 32->64 process? It will become more interesting in the future.
I think that is a fair request. No guarantee that issues popping up will be fixed (or can with reasonable effort, think database formats), but having a look as opposed to an automated WONTFIX appears reasonable.
Yes, that's it.
With the current state, I might try, but I would not bother to report anything; it takes many hours, even days, to prepare and do the trial, but any report would be ignored... why bother? :-(
If you or someone else is giving it a try can summarize on the Wiki, that would be nice.
I have been told by several people that they succeeded. But I have no idea where in the wiki it would be appropiate.
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2010-02-15 at 21:48 +0100, Carlos E. R. wrote:
On Monday, 2010-02-15 at 16:21 +0100, Gerald Pfeifer wrote:
On Mon, 8 Feb 2010, Carlos E. R. wrote:
After all, zypper live upgrade has been possible for a long time, but not officially suported. However, bugzillas on it were accepted. I wrote some! Couldn't the same be the case for the 32->64 process? It will become more interesting in the future.
I think that is a fair request. No guarantee that issues popping up will be fixed (or can with reasonable effort, think database formats), but having a look as opposed to an automated WONTFIX appears reasonable.
Yes, that's it.
With the current state, I might try, but I would not bother to report anything; it takes many hours, even days, to prepare and do the trial, but any report would be ignored... why bother? :-(
If you or someone else is giving it a try can summarize on the Wiki, that would be nice.
I have been told by several people that they succeeded. But I have no idea where in the wiki it would be appropiate.
Just to mention that I succeeding upgrading 11.0 32 bits to 11.2 64 bits.
- -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar)
-
"Markus Koßmann" -
Carlos E. R. -
Carlos E. R. -
Eberhard Moenkeberg -
Gerald Pfeifer -
Klaus Kaempf -
Lars Müller -
Stefan Seyfried -
Stephan Kulow