[opensuse] Architecture change (upgrade from x86 to x86_64) via offline install (iso image written to usb key) possible?
Hello, thanks for giving a quick hint. Is architecture change (upgrade from x86 to x86_64) via offline install (iso image written to usb key) possible? Currently some 12.3 32bit needs to upgrade to x64. Can I also specify an additional local hdd folder where a local copy of the http://download.opensuse.org/update/12.3/ is saved to so that the offline upgrade via the iso image from the usb key uses the endless updates that had been released in the mean time since 12.3 wen vanilla? What way could I specify an additional repository place or folder during that offline install so that it makes use of the latest patches as best as possible? Am I doing it wrong? Thanks for helping. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 12/12/14 a las 17:52, cagsm escribió:
Hello, thanks for giving a quick hint.
Is architecture change (upgrade from x86 to x86_64) via offline install (iso image written to usb key) possible?
Currently some 12.3 32bit needs to upgrade to x64
While this kind of upgrade is not officially supported I think Stefan ("seife") did it with success and documented the precise steps to do so. search on the list archives of "factory" and "opensuse". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Okay thanks for the quick reply, I already found some posts at various
places which say offline upgrade or change of architecture should
rather work. Now it all boils down to specifying an additional
location of the patch rpm packages in ly locally mirrored update
folder from the update servers of the opensuse project. It is
basically the same when people come late to a current opensuse release
and dont want to fall back to the vanilla offline install media but
want to make use of an additional source (the update folder). With
zypper and multiple repositories and then zypper dup this works fine,
question remains how do I specify what parameter for the installer or
kernel bootparameter of the installmedia or the linuxrc or what those
parts are called to make it use the dvd media packages *and* the local
update folder on the hdd in the system? Any hints? Thank you.
On Fri, Dec 12, 2014 at 10:02 PM, Cristian Rodríguez
El 12/12/14 a las 17:52, cagsm escribió:
Hello, thanks for giving a quick hint.
Is architecture change (upgrade from x86 to x86_64) via offline install (iso image written to usb key) possible?
Currently some 12.3 32bit needs to upgrade to x64
While this kind of upgrade is not officially supported I think Stefan ("seife") did it with success and documented the precise steps to do so. search on the list archives of "factory" and "opensuse".
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-12-12 22:18, cagsm wrote:
Okay thanks for the quick reply, I already found some posts at various places which say offline upgrade or change of architecture should rather work. Now it all boils down to specifying an additional location of the patch rpm packages in ly locally mirrored update folder from the update servers of the opensuse project. It is
Don't run the updates during the system upgrade. You run the upgrade first. The DVD will not see the partition, you will have to manually enter it; then the installer will complain in red letters or something. Just go ahead. Well, better made a full backup in advance. After the upgrade (do not attempt graphical mode yet, probably will crash), you have to search and update all remaining packages from the wrong architecture. Try: rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \ | sort | cut --fields="2-" | tee rpmlist \ | egrep -v "x86_64" | | egrep -v "noarch" | less -S which will list all 32 bit packages, and other things, but not many. Some of the 32 bit packages do not have 64 bit versions, like grub. You can create a mirror of the oss and non-oss repos, and point the updater to them, yes. But do not add the update repos initially, it complicates things. After purging the remaining 32 bit packages, and booting, you can attempt a zypper patch or yast online update, in graphical mode if you wish. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlSLYgcACgkQtTMYHG2NR9XA0QCePpCsKq66fpQ4zbPMmHNO5uAC hY0AoJPKNtc1u5aWjXUwNk6wVoJCsTDb =1Bix -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I did the architecture change via offline (usb key) and it somehow
wasnt going all that bad after all. But it did write quite a lot of
stuff such as wrong permissions 4755 0755 or all those kind of things
I remember from past years, I always wanted to ask the community why
there are constantly wrong permissions in the packages while install
or upgrade. I even often experience these wrongly set permissions from
one beta or releasecandidate edition of opensuse to the following or
during zypper up in the past. Anyways, the x64 system first enumerated
the external ethernet interface badly, but I had that update folder
locally on the disk so I set that as an additional repo via yast as
local folder or path, and zypper up found 600something patches and
applied them including kernel and all, and after the next reboot the
ethernet interface was back again enumerated properly again or maybe
the reboot or udev or whatever fixed it and it came back online and
the system was again working properly with ssh named squid ntp and
some little normal things.
About these many errors (not just the permission errors) during the
opensuse install procedures: Some netscape NSS package struck me that
it crashed the javaruntime that was mangling and working it with a
java interpreter core crash or something, I dont know what it was
eactly about some package containing the string nss some library or
certificates or something?
Does rpm -Va actually really verify all installed rpm packages and
tell me for example if that java-crashing nss package was really
executing fine or did rpm automatically somehow fix this at a later
time or how does this really work on linux with rpm, how to make sure
that an rpm really did all the steps according to what it should do,
scripts and extracting and working on files and all?
I think I remember from years back when during an offline update via
dvd or so later inside the upgraded but somewhat crappy system I fired
up yast software management module and it brought up some screen with
some tens or so listed packages and yast module automatically told me
that there was something wrong with those packages listed and it
needed to work on them again and if I wanted to do that or so I
remember. Is that the same as with rpm -Va or is there a way to really
check packages? I never again found that place in yast ever again
after that single incident. Any hints?
Thanks.
On Fri, Dec 12, 2014 at 10:45 PM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-12-12 22:18, cagsm wrote:
Okay thanks for the quick reply, I already found some posts at various places which say offline upgrade or change of architecture should rather work. Now it all boils down to specifying an additional location of the patch rpm packages in ly locally mirrored update folder from the update servers of the opensuse project. It is
Don't run the updates during the system upgrade.
You run the upgrade first. The DVD will not see the partition, you will have to manually enter it; then the installer will complain in red letters or something. Just go ahead. Well, better made a full backup in advance.
After the upgrade (do not attempt graphical mode yet, probably will crash), you have to search and update all remaining packages from the wrong architecture. Try:
rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \ | sort | cut --fields="2-" | tee rpmlist \ | egrep -v "x86_64" | | egrep -v "noarch" | less -S
which will list all 32 bit packages, and other things, but not many. Some of the 32 bit packages do not have 64 bit versions, like grub.
You can create a mirror of the oss and non-oss repos, and point the updater to them, yes. But do not add the update repos initially, it complicates things. After purging the remaining 32 bit packages, and booting, you can attempt a zypper patch or yast online update, in graphical mode if you wish.
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlSLYgcACgkQtTMYHG2NR9XA0QCePpCsKq66fpQ4zbPMmHNO5uAC hY0AoJPKNtc1u5aWjXUwNk6wVoJCsTDb =1Bix -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-12-13 02:18, cagsm wrote:
I did the architecture change via offline (usb key) and it somehow wasnt going all that bad after all. But it did write quite a lot of stuff such as wrong permissions 4755 0755 or all those kind of things I remember from past years, I always wanted to ask the community why there are constantly wrong permissions in the packages while install or upgrade. I even often experience these wrongly set permissions from one beta or releasecandidate edition of opensuse to the following or during zypper up in the past.
I don't know if this is your case, but it is normal in openSUSE for an rpm to contain files with some permissions, which are later adjusted to some other permissions via /etc/permissions, and there are reasons for this.
Does rpm -Va actually really verify all installed rpm packages and tell me for example if that java-crashing nss package was really executing fine or did rpm automatically somehow fix this at a later
No, it does nothing of the sort. It only verifies that the files on disk match or not what was contained in the rpms. It can not take into account the rpm scripts, I think.
I think I remember from years back when during an offline update via dvd or so later inside the upgraded but somewhat crappy system I fired up yast software management module and it brought up some screen with some tens or so listed packages and yast module automatically told me that there was something wrong with those packages listed and it needed to work on them again and if I wanted to do that or so I remember. Is that the same as with rpm -Va or is there a way to really check packages? I never again found that place in yast ever again after that single incident. Any hints?
There are some verification options in YaST, but I don't know if that is what you saw. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Hi there,
On Fri, Dec 12, 2014 at 10:45 PM, Carlos E. R.
After the upgrade (do not attempt graphical mode yet, probably will crash), you have to search and update all remaining packages from the wrong architecture. Try:
rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \ | sort | cut --fields="2-" | tee rpmlist \ | egrep -v "x86_64" | | egrep -v "noarch" | less -S
I think there is a surplus pipe in that line, I changed it to:
rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day}
%{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch}
%25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" | sort |
cut --fields="2-" | tee rpmlist | egrep -v "x86_64" | egrep -v
"noarch" | less -S
Resulting on the system in:
Wed Mar 02 2011 Wed Mar 02 2011 gpg-pubkey
0dfb3188-41ed929b (none) (none)
(none) == (none) (none)
Wed Mar 02 2011 Wed Mar 02 2011 gpg-pubkey
307e3d54-4be01a65 (none) (none)
(none) == (none) (none)
Wed Mar 02 2011 Wed Mar 02 2011 gpg-pubkey
3d25d3d9-36e12d04 (none) (none)
(none) == (none) (none)
Wed Mar 02 2011 Wed Mar 02 2011 gpg-pubkey
56b4177a-4be18cab (none) (none)
(none) == (none) (none)
Wed Mar 02 2011 Wed Mar 02 2011 gpg-pubkey
7e2e3b05-4be037ca (none) (none)
(none) == (none) (none)
Wed Mar 02 2011 Wed Mar 02 2011 gpg-pubkey
9c800aca-4be01999 (none) (none)
(none) == (none) (none)
Wed Mar 02 2011 Wed Mar 02 2011 gpg-pubkey
a1912208-446a0899 (none) (none)
(none) == (none) (none)
Mon Nov 07 2011 Mon Nov 07 2011 gpg-pubkey
392ffa88-47965b30 (none) (none)
(none) == (none) (none)
Fri May 31 2013 Wed Aug 15 2012 libpng14-14
1.4.11-2.5.1 i586 openSUSE
http://bugs.opensuse.org == openSUSE 12.2 (none)
Fri May 31 2013 Sun Jul 15 2012 libcdio13
0.83.git-4.1.2 i586 openSUSE
http://bugs.opensuse.org == openSUSE 12.2 (none)
Fri May 31 2013 Sat Jan 26 2013 master-boot-code
1.22-12.1.1 i586 openSUSE
http://bugs.opensuse.org == openSUSE 12.3 (none)
Fri May 31 2013 Sun Jan 27 2013 xf86-video-geode
2.11.14-2.1.1 i586 openSUSE
http://bugs.opensuse.org == openSUSE 12.3 (none)
Sun Jan 19 2014 Tue Jan 07 2014 grub2-i386-efi
2.00-19.31.1 i586 openSUSE
http://bugs.opensuse.org == openSUSE 12.3 (none)
Tue May 13 2014 Mon May 05 2014 gpg-pubkey
3dbdc284-53674dd4 (none) (none)openSUSE
Project Signing Key
On 2014-12-13 02:26, cagsm wrote:
I think there is a surplus pipe in that line, I changed it to:
True. I edited it before posting and I made a mistake.
Resulting on the system in:
Wed Mar 02 2011 Wed Mar 02 2011 gpg-pubkey 0dfb3188-41ed929b (none) (none) (none) == (none) (none)
These are ok
Fri May 31 2013 Wed Aug 15 2012 libpng14-14 1.4.11-2.5.1 i586 openSUSE http://bugs.opensuse.org == openSUSE 12.2 (none)
This one you have to upgrade. You can see that it comes from openSUSE 12.2, and that it is 32 bit.
Fri May 31 2013 Sun Jul 15 2012 libcdio13 0.83.git-4.1.2 i586 openSUSE http://bugs.opensuse.org == openSUSE 12.2 (none)
ditto.
Fri May 31 2013 Sat Jan 26 2013 master-boot-code 1.22-12.1.1 i586 openSUSE http://bugs.opensuse.org == openSUSE 12.3 (none)
Not this one.
Fri May 31 2013 Sun Jan 27 2013 xf86-video-geode 2.11.14-2.1.1 i586 openSUSE http://bugs.opensuse.org == openSUSE 12.3 (none)
Try to upgrade this one.
Sun Jan 19 2014 Tue Jan 07 2014 grub2-i386-efi 2.00-19.31.1 i586 openSUSE http://bugs.opensuse.org == openSUSE 12.3 (none)
Try to upgrade, but I don't know if there will be a 64 bit package. Your list is very short, mine had hundreds of entries. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-12-12 22:02, Cristian Rodríguez wrote:
El 12/12/14 a las 17:52, cagsm escribió:
Hello, thanks for giving a quick hint.
Is architecture change (upgrade from x86 to x86_64) via offline install (iso image written to usb key) possible?
Currently some 12.3 32bit needs to upgrade to x64
While this kind of upgrade is not officially supported I think Stefan ("seife") did it with success and documented the precise steps to do so. search on the list archives of "factory" and "opensuse".
Me too. :-) And several more people did it. It takes some time, it is not trivial. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlSLXjsACgkQtTMYHG2NR9WQQgCghk4tc7Xi15KhDdVxcs959vnX mpMAn20hYJSwRl+0aPmW/tvzLgaPomAW =jlK1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-12-12 21:52, cagsm wrote:
Can I also specify an additional local hdd folder where a local copy of the http://download.opensuse.org/update/12.3/ is saved to so that
Don't. Unless there is a patch you absolutely need for the system to start. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Since the network card for external connection was messed up after the
architecture change initially installed from the vanilla media usb
key, I was lucky that I had fetched the 12.3 update folder to the
local disk in advance, so that I was able to add that local hdd folder
as repository for zypper and zypper up there and then after the next
reboot the network card came back fine as before on the 32bit system
and it is mostly all good now.
So maybe future opensuse releases could somehow really do make use of
additional repositories even when using vanilla read-only potentially
outdated media to do offline install from but already the install
process could take in such nice update packagas as kernel or udev
systemd and init related stuff and all those things for basic
operating the hardware and network and really the core of things.
Thanks for the thread and explanations. Regards.
On Fri, Dec 12, 2014 at 10:30 PM, Carlos E. R.
On 2014-12-12 21:52, cagsm wrote:
Can I also specify an additional local hdd folder where a local copy of the http://download.opensuse.org/update/12.3/ is saved to so that Don't. Unless there is a patch you absolutely need for the system to start. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-12-15 11:26, cagsm wrote:
Since the network card for external connection was messed up after the architecture change initially installed from the vanilla media usb key, I was lucky that I had fetched the 12.3 update folder to the local disk in advance, so that I was able to add that local hdd folder as repository for zypper and zypper up there and then after the next reboot the network card came back fine as before on the 32bit system and it is mostly all good now.
Aha.
So maybe future opensuse releases could somehow really do make use of additional repositories even when using vanilla read-only potentially outdated media to do offline install from but already the install process could take in such nice update packagas as kernel or udev systemd and init related stuff and all those things for basic operating the hardware and network and really the core of things.
The installer can make use of networked repos, but when it does, they replace completely the DVD. Say, you have pack.9.rpm both in the dvd and in the oss repo, it takes the one from oss, wasting bandwidth and time. The update repo is a different case. It is normally better to not use it during install/upgrades, because the result was untested/undesigned for. There are exceptions. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Hello, On Fri, 12 Dec 2014, cagsm wrote:
Is architecture change (upgrade from x86 to x86_64) via offline install (iso image written to usb key) possible?
Currently some 12.3 32bit needs to upgrade to x64.
Yes. But if something goes wrong, and no way to start from scratch (see below), you're in rather deep trouble ;) I'm not sure if I described it here in english, but basically, there one step you MUST take as the VERY first: change the arch = i586 entry in /etc/zypp/zypp.conf to arch = x86_64 After that, it should be as documented for a normal distro update (i.e. change the repos, zypper clean ref; zypper dup). Oh, and I _kept_ all repos active that offered a repo for the new version. Otherwise, you get e.g. all packman stuff uninstalled, and you won't remember all that, so better check the repos for who has the new version and just leave them active. The official way of disabling all other repos is IMO just due to them not wanting to be responsible if some repo does not have e.g. currently 13.2 available and thus stuff breaking. I DO strongly recommend doing this on a (e.g. rsync'd) clone of the actual system though! If anything goes wrong, you can ask for help first, clone again, and then start from scratch ... -dnh, BTDT, using the unpacked boot from the ISO and the loop-mounted ISO itself instead of an USB-shtik (IIRC: 11.2(32bit) -> 11.4(64bit), still running that system dupped to 12.1 (and not planning to upgrade). Which does not mean I've no experience with e.g. 12.3 or 13.1. -- 167: DAU Leute, die sich beim Falschparken selbst anzeigen. (Dietz Proepper) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-12-12 23:11, David Haller wrote:
After that, it should be as documented for a normal distro update (i.e. change the repos, zypper clean ref; zypper dup).
That's the "online upgrade procedure". He asked about the "offline upgrade procedure", ie, boot dvd, choose upgrade. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Hello, On Sat, 13 Dec 2014, Carlos E. R. wrote:
On 2014-12-12 23:11, David Haller wrote:
After that, it should be as documented for a normal distro update (i.e. change the repos, zypper clean ref; zypper dup).
That's the "online upgrade procedure". He asked about the "offline upgrade procedure", ie, boot dvd, choose upgrade.
It's the same offline: ==== /etc/zypp/repos.d/DVD.repo ==== [openSUSE-13.2-DVD-x86_64] name=openSUSE-13.2-DVD-x86_64 enabled=1 autorefresh=0 baseurl=iso:///?iso=openSUSE-13.2-DVD-x86_64.iso&url=file:///data/ path=/ type=yast2 priority=94 keeppackages=0 ==== (if you have the ISO lying in /data/) HTH, -dnh -- I've seen people with new children before, they go from ultra happy to looking like something out of a zombie film in about a week. -- Alan Cox about Linus after his 2nd daughter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-12-13 14:01, David Haller wrote:
It's the same offline:
The term "offline upgrade" vs "online upgrade" is not related to the packages being downloaded "online" or locally. It refers to the system being upgraded being live, online, or dead, offline. Doing a "zypper dup" from the same system as it is being upgraded is an online upgrade, even if pulling from a local disk. Booting a live dvd or stick or a partition on disk in order to run a system that upgrades another linux that resides on a different partition, and which is thus not currently running, is called an offline upgrade. The OP, cagsm, is doing an offline upgrade - see subject line of the posts. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlSQzmIACgkQtTMYHG2NR9WeugCfVxQV8rVDgtOzpWHpy1FcdRj2 27AAmgIanmUH9d+qh+gnf8EtIY4E1zdx =3aHn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (5)
-
cagsm -
Carlos E. R. -
Carlos E. R. -
Cristian Rodríguez -
David Haller