[SOLVED]Moving from 32-bit to 64-bit - not so hard after all

[mailedfist]

Hi Folks.

The time has come when I have to finally move from 32-bit to 64-bit, as I need to use docker and there isn't a 32-bit version of it.

Now, we all know that there isn't an out-of-the-box upgrade to do this. I've been running on 64-bit hardware for years but haven't wanted to go through the pain of trying to find the things I forgot to install for the new architecture.

I'm going to copy /etc somewhere so that I don't lose all the customisations that have been built up over time but the question is, can I generate a file listing all the packages that I currently have installed so that I can diff this with what I end up with under 64-bit and thereby work out what I forgot?

There are some things that I've built and installed from source but I suspect many are now in the package library, and the rest I can deal with as and when I need them.

I'm presuming (naively?) that VirtualBox will make the change transparent to all my virtual machines.

Anything else I've forgotten?

All the best,

Mark

[tarakbumba]

To get all installed rpms, with only name, you can use

Code: Select all

rpm -qa | rev| cut -d "-" -f3-5 | rev > rpms.txt

[jiml8]

rpm -qa will list out all installed packages.

I would expect virtualbox to not care on the VM side about whether the host was 32 or 64 bits. I know vmware workstation did not care.

If I were you, and I had the space, I would save the whole 32 bit system and not just /etc. When I made that move, from 32 bit Mandriva 10 to 64 bit Mageia 2, I found many opportunities to go back into the old distro to pick things up that I needed for one reason or another. /etc was obvious, but there were many other things. I still have the old distro on my archival hard drive, and I still from time to time reference it - and it has been more than 15 months since I made the move.

[Ken-Bergen]

the question is, can I generate a file listing all the packages that I currently have installed so that I can diff this with what I end up with under 64-bit and thereby work out what I forgot?

Code: Select all

rpm -qa --qf '%{NAME}\n' | sort > some-file.txt

Will generate such a list.

[mailedfist]

Thanks Ken, that's perfect.

jiml8 - Thanks for the note about needing more than /etc. I'm going to swap out the drives (RAID) with the OS on (/home is on a separate volume) so should be able to refer to the original in the future as needed. I'm copying /etc to something that is more immediately available as I'm out of bays to be able to have the originals live with everything else.

All the best,

Mark

[tarakbumba]

Code: Select all

rpm -qa --qf '%{NAME}\n' | sort > some-file.txt

Will generate such a list.

That' s more simpler and elegant. Thanks.

[doktor5000]

Can be shortened even more

Code: Select all

rpm -qa --qf '%{N}\n'  | sort > file.txt

(name, epoch, version and release tags can be abbreviated by their first letter)

[mailedfist]

Thanks All. This has worked very well so far and I'm nearly there. I don't suppose there's a sed guru who can give me the syntax for replacing lib with lib64 is there though please? Sorry I''m being lazy - will work out how to do it tomorrow otherwise!

All the best,

Mark

[Ken-Bergen]

As library's are not programs but installed as dependencies of programs just delete them from the list.
The required ones 32 or 64bit will be installed.

[mailedfist]

The only thing with that is that I would need to delete them each time from the newly generated list, which is a bit of a nuisance when looking at the diff list to work out what is still inconsistent.

The following extra bit worked well:

Code: Select all

rpm -qa --qf '%{N}\n'  | sed '/^lib/d' | sort > allpackages_nolibs.txt

This has the important caveat that anything beginning with "lib" which is not a library is not in the output either, the libreoffice suite for example!
I therefore don't recommend that you do this on the original list - generate it without the sed and then do the sed afterwards when creating you file for diff'ing.

So, the final method I used was:

copy /etc somewhere safe.

Code: Select all

rpm -qa --qf '%{N}\n'  | sort > allpackages.txt

before migrating.
Then, after migrating:

Code: Select all

cat allpackages.txt | sed '/^lib/d' > allpackages_nolibs.txt

Install all the packages you think you need (including such things as libreoffice!), then:

Code: Select all

rpm -qa --qf '%{N}\n'  | sed '/^lib/d' | sort | diff allpackages_nolibs.txt -

Use the output to see the things you missed, install them, and then try again (others are likely to be resolved when one package is spotted due to dependencies).

Use the reference /etc to get your settings back as they were.

Voila! All done

Thanks to everyone who posted for your help - this has proved a lot less painful than I expected. Note that the Mageia 4 64-bit installer automatically works out where your mount points were if you install to your existing disk (or, preferably just in case of trouble, a copy of it) and by default only wants to format / and /usr, not /home or /var, so it really is very straightforward unless you want to change volume sizes before moving to 64-bit.

Note: I actually have an old, smaller, /home on my OS drives so that I could make sure all was well before switching to my real /home by changing fstab. Not everyone will be able to do this and I strongly advise anyone else using this thread as a reference that, even if you can't back everything up for some reason, if you need to install with your real /home live then please copy it somewhere safe before installing 64-bit just in case bad things happen

[doktor5000]

Note that the Mageia 4 64-bit installer automatically works out where your mount points were if you install to your existing disk (or, preferably just in case of trouble, a copy of it) and by default only wants to format / and /usr, not /home or /var, so it really is very straightforward unless you want to change volume sizes before moving to 64-bit.

That's not unique or specific to the Mageia 4 64-bit installer, that has always been the case.
It will by default never propose to format the /home partition, and usually it will relate the partitions to their old mountpoints pretty well.