Hello,
I have migrated my home server from an old 32bit M/B - CPU to an Athlon 64bit.
In this forum as well as in other places, a lot of people say that we can upgrade the 13.1 bit to 31.1 64 bit by simply inserting the 64bit DVD into the system selecting “Update”
When I did so, the installer had only one option: Install from scratch.
Note that my old / is ext3 (if that makes any difference).
What am I missing here?
If you have a separate “/home” partition, this should not be too much of a problem.
At the partitioning section of the install, click the “Import partitioning” button. That will keep your current partitions. It will want to reformat the root partition (I suggest you switch to “ext4”), and it will retain the “/home” partition untouched.
That’s how I usually install anyway.
You need the full DVD not one of the live DVDs
On 2014-07-16 16:36, tpe wrote:
>
> Hello,
> I have migrated my home server from an old 32bit M/B - CPU to an Athlon
> 64bit.
> In this forum as well as in other places, a lot of people say that we
> can upgrade the 13.1 bit to 31.1 64 bit by simply inserting the 64bit
> DVD into the system selecting “Update”
Simply? That’s and understatement if there ever was one 
I have done it, and I would do it again, but simple it ain’t.
When the DVD says that it finds nothing to upgrade, you have to manually
select the partition where the 32 bit system is, and tell YaST you want
to upgrade /that/. YaST will politely insult you, call you mad, or there
abouts. Just insist and go ahead…
After it finishes, you will have to go hunting for any 32 bit leftover,
and upgrade it, clicking on the YaST version tab to switch it. With some
exceptions like grub, I think.
Try, after the DVD upgrade - with only the four official repos enabled:
zypper patch
zypper up
zypper dup
(yes, all three of them, in that order)
Then, examine the output of
rpm -q -a --queryformat "%{INSTALLTIME} %{INSTALLTIME:day} \
%{BUILDTIME:day} %-30{NAME} %15{VERSION}-%-7{RELEASE} %{arch} \
%25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}
" \
| sort | cut --fields="2-" | tee rpmlist \
| less -S
and go hunting…
Some more info:
Note: I must insist you make a good backup prior to starting any major road.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
On 2014-07-16 18:16, gogalthorp wrote:
>
> You need the full DVD not one of the live DVDs
Not even then. The 32 -> 64 upgrade is not officially supported.
It can be done, many people have done it, but the DVD will not offer it
on its own. You have to insist on doing it.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Yes but also you can not do any kind of upgrade with a live. Well you can I guess if you force it not to format root but it will never show an option but bot sure that is a real upgrade .
On 2014-07-16 19:06, gogalthorp wrote:
>
> Yes but also you can not do any kind of upgrade with a live.
True enough
And it says so in the download page, which confuses some people.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Guys,
I am not faint to the heart. Let me put this this way. THe alternative is to setup the 64bit system on another HDD, then rsync data from one disk to another.
And since we talk about data from MANY years ago (starting back at the 90ies…), believe me, I cannot do it. And my backup plan sucks (it was almost non-existant. I recently started using rsync and I plan to upgrade to Amanda).
So, I need to be sure that I will not make any mistake:
I choose INSTALL.
Then, I choose the detailed partionning and I insist on my selection.
I am missing something?
The rest of the issues will be solved after the upgrade.
Yes you miss first backing up your data just in case.
But in general yep force the issue don’t take no for an answer 
Note also that not all things will be changed and you are bounded to run into some problems.
On 2014-07-16 23:06, tpe wrote:
>
> Guys,
> I am not faint to the heart. Let me put this this way. THe alternative
> is to setup the 64bit system on another HDD, then rsync data from one
> disk to another.
> And since we talk about data from MANY years ago (starting back at the
> 90ies…), believe me, I cannot do it. And my backup plan sucks (it was
> almost non-existant. I recently started using rsync and I plan to
> upgrade to Amanda).
>
> So, I need to be sure that I will not make any mistake:
> I choose INSTALL.
> Then, I choose the detailed partionning and I insist on my selection.
NO!
Choose “Upgrade”, select the partition manually, and insist on it.
If you choose “install”, it will format partitions and destroy data -
unless your valued data is on separate data partitions, like /home.
And let me insist: Any operating system installation is a dangerous
operation. An upgrade is a dangerous operation. An upgrade from 32 to 64
is even more, er… delicate.
So you ABSOLUTELY need a good and complete backup before starting.
Probably you will not need it, but if you do and you didn’t do it, you
will be very sorry indeed.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Hi tpe!
The point is that changing from 32bit to 64bit
practically every piece of software has to be replaced.
So an ‘update’ hardly makes sense.
Using ext3 isn’t linked in any way to using 32bit or 64bit software !
You may very well use ext3 - if you prefer that - when installing a 64bit version of openSUSE.
But changing from 32bit to 64bit, on whatever volume (ext3, ext4, ReiserFS, …),
a fresh install would probably be the best thing that you can do!
The installer gave a good advice in that case.
Everything else would lead to heavy fragmentation of your Linux/openSUSE (ext3, ext4, …) volumes.
Good luck
Mike
On 2014-07-17 23:56, ratzi wrote:
> The point is that changing from 32bit to 64bit
> practically -every- piece of software has to be replaced.
Yes, of course.
> So an ‘update’ hardly makes sense.
It does to me
> tpe;2654273 Wrote:
>> Note that my old / is ext3 (if that makes any difference).
>> What am I missing here?
>
> Using ext3 isn’t linked in any way to using 32bit or 64bit software !
Well… on some filesystems it matters. For instance, on XFS, you need
64 bit to go beyond certain size.
> Everything else would lead to heavy fragmentation of your Linux/openSUSE
> (ext3, ext4, …) volumes.
Why?
I can not imagine why, I don’t see the relation.
Filesystem fragmentation?
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Hi Carlos!
It is quite simple:
The files of a 64bit system (Kernel, Libs, Apps) will each have an at least slightly different size compared to the respective files of a 32bit system.
Replacing all these 32bit files (how many?), which after the initial installation of a 32bit system will probably will be placed one after another,
i.e. whithout any free space in between, by files of even slightly different size (the ones of the 64bit system) will unavoidably cause fragmentation.
Hmm, maybe, using a Linux file system, this may not take effect until the respective disk/volume is full, or is closed to be so.
But the fragmentation is there once you replaced each 32bit file whith another 64bit one of slightly different size.
Greets!
Mike
On 2014-07-18 02:06, ratzi wrote:
>
> Hi Carlos!
>
> robin_listas;2654588 Wrote:
>>> Everything else would lead to heavy fragmentation of your
>> Linux/openSUSE
>>> (ext3, ext4, …) volumes.
>>
>> Why?
>> I can not imagine why, I don’t see the relation.
>> Filesystem fragmentation?
>
> It is quite simple:
>
> The files of a 64bit system (Kernel, Libs, Apps) will each have an at
> least slightly different size compared to the respective files of a
> 32bit system.
>
> Replacing all these 32bit files (how many?), which after the initial
> installation of a 32bit system will probably will be placed one after
> another,
> i.e. whithout any free space in between, by files of even slightly
> different size (the ones of the 64bit system) will unavoidably cause
> fragmentation.
You should have more trust in Linux
Upgrading from 32 bit to 64 causes the same filesystem fragmentation as,
for instance, upgrading from 12.2 to 12.3 and staying in the same 32 bit
arch. Close to nil, as in any normal usage. Like when you get a packman
update.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Hi Carlos!
Yes, of course, any update poses problems to the file system (like ext3, ext4, …).
OK, let’s say the Linux file systems are designed such that - in case of a change of a file’s size -
first a location on the device is sought where the file could be written as a whole - i.e. without fragmentation.
Whatever drawbacks this could involve - I’m not familiar with that matter in that detail.
And I’m not a mathematician.
But do you know about some documentation in which the behaviour of the Linux file systems in cases like these is explained ?
I would be keen to read such.
Greets!
Mike
Why does it seem to be so hard to get documentation about Linux, and critical components of it, like the file systems ?
Good question. That would make a good thread in one of the other forum areas here, don’t you agree?
There are plenty of places that have general usage info on all the file systems. However very deep seldom wondered about questions can only be answered by the developers and/or the source code. Like maybe differences between 32 and 64 bit OS usage. I really don’t think there is any difference, since either bit modal can access the same partition at the same time.
On 2014-07-19 18:46, gogalthorp wrote:
>
> There are plenty of places that have general usage info on all the file
> systems. However very deep seldom wondered about questions can only be
> answered by the developers and/or the source code. Like maybe
> differences between 32 and 64 bit OS usage. I really don’t think there
> is any difference, since either bit modal can access the same partition
> at the same time.
There is a difference when using XFS and very large partitions. For
instance, if you use acroread in 64 bit system (acroread remains 32
bit), in a very large partition (I forget the crucial size figure, but
not huge by today standards) and try a file that lies beyond that point,
acroread fails. A file that sits before that point, works.
On a 32 bit system you simply can not use a partition that large, or you
can not format it in 64 bit mode - I forget which.
There was a thread about this problem, perhaps in the mail list.
The problem in this case is that acroread is a 32 bit application and
can not index the location of the files that lie beyond certain point,
in a modern XFS partition.
But what worries ratzi is that the upgrade from 32 to 64 bits would
replace every bit of code on disk with a slightly larger file, so they
can not be written to the same spot, and would fragment.
I think not, as the files, having new names (version tag) or being in a
diffferent …64/ directory, will be written new, in a new location. The
original files are either removed after, in a bunch, or prior to writing
the new ones, again in a bunch - so no file would try to be written to
the same location, anyway.
So I believe there is no ground for that fear
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
On Wed, 16 Jul 2014 21:06:02 GMT, tpe <tpe@no-mx.forums.opensuse.org>
wrote:
>
>Guys,
>I am not faint to the heart. Let me put this this way. THe alternative
>is to setup the 64bit system on another HDD, then rsync data from one
>disk to another.
>And since we talk about data from MANY years ago (starting back at the
>90ies…), believe me, I cannot do it. And my backup plan sucks (it was
>almost non-existant. I recently started using rsync and I plan to
>upgrade to Amanda).
>
>So, I need to be sure that I will not make any mistake:
>I choose INSTALL.
>Then, I choose the detailed partionning and I insist on my selection.
>
>I am missing something?
>
>The rest of the issues will be solved after the upgrade.
OK, my personal opinion but, do the backup first. If it takes a week it
takes a week, tough. If your data is valuable it is crazy to not have
backup. Once your data is safe you can play games with the system for all
i care.
?-)