Can a version upgrade be done entirely within YaST? Specifically: 1. amend all repositories from 15.1 to 15.2 2. use Online Update to do a "force update all"
Also, can this be done from within a graphical session from a user account, should it be done when logged in as root, or should it be done strictly from a command line, but not logged into a graphical session?
(Hopefully I've worded that so as not to be overly confusing ;) )
On 24/06/2020 21.03, Darryl Gregorash wrote:
Can a version upgrade be done entirely within YaST? Specifically:
- amend all repositories from 15.1 to 15.2
- use Online Update to do a "force update all"
Better not.
Just use "zypper dup" in text mode, with download first. There is a new command option to edit the repos, I think, but I don't recall if 15.1 has it.
On 2020-06-24 1:14 p.m., Carlos E. R. wrote:
On 24/06/2020 21.03, Darryl Gregorash wrote:
Can a version upgrade be done entirely within YaST? Specifically:
- amend all repositories from 15.1 to 15.2
- use Online Update to do a "force update all"
Better not.
Just use "zypper dup" in text mode, with download first. There is a new command option to edit the repos, I think, but I don't recall if 15.1 has it.
This will be the first time I've ever done a version upgrade -- previously, I've always done a fresh install from a DVD/USB stick. So please give very detailed information. Especially, why not do it the way I asked? I've also never used zypper for anything, preferring to use the YaST updater (or the desktop widget in the GUI), so you should presume I know nothing about this utility. I do, however, have these early questions:
1. Why not just use "--releasever 15.2" on the zypper dup commandline? It seems to me that this should work at least for the main, non-OSS and update repositories. However, I also have the libdvdcss and Packman repositories configured, and these 2 have "openSUSE_Leap_15.1" in the URL -- so maybe this wouldn't work with those 2?
2. The zypper default seems to be "download-in-advance", so why is this option needed at all?
3. Would "download-in-heaps" work?
On 24/06/2020 22.08, Darryl Gregorash wrote:
On 2020-06-24 1:14 p.m., Carlos E. R. wrote:
On 24/06/2020 21.03, Darryl Gregorash wrote:
Can a version upgrade be done entirely within YaST? Specifically:
- amend all repositories from 15.1 to 15.2
- use Online Update to do a "force update all"
Better not.
Just use "zypper dup" in text mode, with download first. There is a new command option to edit the repos, I think, but I don't recall if 15.1 has it.
This will be the first time I've ever done a version upgrade -- previously, I've always done a fresh install from a DVD/USB stick. So please give very detailed information.
I wrote a very detailed wiki page - on the DVD upgrade method ;-) And others wrote another wiki page on the dup method.
Especially, why not do it the way I asked?
1) Because it is not designed for it. 2) Because if graphics mode crashes (and I have seen it crash during upgrades), you are left in a bad situation.
That reminds me. Make sure that your network connection works in text mode. There is a CLI mode to activate network manager if you can not restart the graphics mode, come the worst.
I've also never used zypper for anything, preferring to use the YaST updater (or the desktop widget in the GUI), so you should presume I know nothing about this utility. I do, however, have these early questions:
There is a detailed wiki page on this:
https://en.opensuse.org/SDB:System_upgrade
And there is a book:
https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha-update-osuse.html
My recommendation: do a full backup in advance. A system upgrade is a dangerous operation: if it fails, you can figure out what happened and how to solve the issue, or recover from backup and re-try, or install fresh install, with copies of your files and configs in the backup for use. That said, I have been doing upgrades of my system since SuSE 6.4 till now, and it works.
- Why not just use "--releasever 15.2" on the zypper dup commandline?
It seems to me that this should work at least for the main, non-OSS and
That must be the new option I mentioned and that I'm not familiar with ;-)
update repositories. However, I also have the libdvdcss and Packman repositories configured, and these 2 have "openSUSE_Leap_15.1" in the URL -- so maybe this wouldn't work with those 2?
/I/ don't know. It should, but I do not know.
Maybe there is a procedure to verify what repos it is actually using before going ahead.
My recommendation: disable any repo you do not really need. For example, extra plasma/gnome/xfce repos. Just leave those for packages not included in the main distro repos.
- The zypper default seems to be "download-in-advance", so why is this
option needed at all?
My paranoia. O:-)
It was not the default previously.
- Would "download-in-heaps" work?
I don't think it has been really implemented. And if it has, no, I would still download full in advance, because if during the upgrade the network crashes (or an external failure) and can not be restarted, you are sold-out.
Again, my paranoia. O:-)
Le 24/06/2020 à 22:44, Carlos E. R. a écrit :
Again, my paranoia. O:-)
and my one: change by hand with yast any repo from 15.1 to 15.2 before updating.
un-active any non main repo (anything else than main, update, packman (with oss/nonoss)
and be warned, additional repos may not work afterward, some not needed, some not yet ready
jdd
On 24/06/2020 22.59, jdd@dodin.org wrote:
Le 24/06/2020 à 22:44, Carlos E. R. a écrit :
Again, my paranoia. O:-)
and my one: change by hand with yast any repo from 15.1 to 15.2 before updating.
un-active any non main repo (anything else than main, update, packman (with oss/nonoss)
and be warned, additional repos may not work afterward, some not needed, some not yet ready
A download only phase serves to detect the non-working repos without doing any change.
Ah, reminds me:
I edit the repos in /etc/zypp/repos.d/ with an editor (actually, with 'mc'), then I do:
zypper clean zypper refresh
This also detects those problems.
Carlos E. R. schrieb am 24.06.20 um 23:05:
Ah, reminds me:
I edit the repos in /etc/zypp/repos.d/ with an editor (actually, with 'mc'), then I do:
you might do a »sed -i.bak 's|15.1|15.2|g' *repo i« instead :). This leaves you with a .repo.bak file for each repo to go back to when necessary.
Or you use $releasever in the baseurl lines, this is adapted automatically by zypper, as in http://download.opensuse.org/repositories/security/openSUSE_Leap_$releasever/. No bothering with changing URLs any more :)
This might work after adapdating /etc/os-release ;)
zypper clean zypper refresh
This also detects those problems.
That's always useful :)
Werner --
On 30/06/2020 10.27, Werner Flamme wrote:
Carlos E. R. schrieb am 24.06.20 um 23:05:
Ah, reminds me:
I edit the repos in /etc/zypp/repos.d/ with an editor (actually, with 'mc'), then I do:
you might do a »sed -i.bak 's|15.1|15.2|g' *repo i« instead :). This leaves you with a .repo.bak file for each repo to go back to when necessary.
Well...
I have this file:
/etc/zypp/repos.d/openSUSE_Leap_15.1_Update.repo
I will also change the filename.
Or you use $releasever in the baseurl lines, this is adapted automatically by zypper, as in http://download.opensuse.org/repositories/security/openSUSE_Leap_$releasever/. No bothering with changing URLs any more :)
This might work after adapdating /etc/os-release ;)
zypper clean zypper refresh
This also detects those problems.
That's always useful :)
I prefer being a bit paranoid here ;-)
Carlos E. R. schrieb am 30.06.20 um 10:35:
On 30/06/2020 10.27, Werner Flamme wrote:
Carlos E. R. schrieb am 24.06.20 um 23:05:
Ah, reminds me:
I edit the repos in /etc/zypp/repos.d/ with an editor (actually, with 'mc'), then I do:
you might do a »sed -i.bak 's|15.1|15.2|g' *repo i« instead :). This leaves you with a .repo.bak file for each repo to go back to when necessary.
Well...
I have this file:
/etc/zypp/repos.d/openSUSE_Leap_15.1_Update.repo
I will also change the filename.
OK, this I do after seeing that for the first time :) The file gets rid of the "_15.1" part at first sight of its name :)
Often by using mmv "*_15.1*" "#1#2" since I always install the mmv package :)
zypper clean zypper refresh
This also detects those problems.
That's always useful :)
I prefer being a bit paranoid here ;-)
:)
--
Darryl Gregorash composed on 2020-06-24 14:08 (UTC-0600):
- The zypper default seems to be "download-in-advance", so why is this
option needed at all?
Required, no. Desirable, yes. As long as sufficient filesystem space is available to store everything to be installed, and get it installed, it's a really really good idea. It protects against a partially upgraded system getting cut off from the mirrors, making recovery more likely possible if something goes wrong. This is a primary reason why I quit using YaST when Zypper became available. If the GUI breaks while the process is incomplete, it can prevent recovery/completion, even rebooting.
YaST does provide features not otherwise available, so I do use it on occasion.
- Would "download-in-heaps" work?
It works with urpmi (Mageia, openMandriva). It's actually the default there. I haven't tried it with zypper in probably over two years. I don't see much point unless space is limited, in which case as needed doesn't seem to make materially less sense. I like navigating the logs better with as needed.
Most of the time I use DownloadAsNeeded, as most of my installations are space limited. However, I normally start with a script that updates everything that might be package management-related before doing the rest:
zypper -v in --download-in-advance zypper libzypp libsolv-tools rpm libproxy1 libmodman1 curl libcurl openSUSE-release zypper -v in --download-in-advance device-mapper dmraid glibc multipath-tools mdadm systemd udev zypper -v up zypper -v dup # (if applicable, after doing zypper up)
On 06/24/2020 04:48 PM, Felix Miata wrote:
zypper -v in --download-in-advance zypper libzypp libsolv-tools rpm libproxy1 libmodman1 curl libcurl openSUSE-release zypper -v in --download-in-advance device-mapper dmraid glibc multipath-tools mdadm systemd udev zypper -v up zypper -v dup # (if applicable, after doing zypper up)
What about disabling non-openSUSE distro repos for the dup and then enabling them for a zypper up after the dup?
When I duped to 15.1 with all repos enable I had vendor changes that caused issues (specifically qt3 and others were pulled from packman instead of OSS/Update that caused fits until the change was discovered)
The intent being to dup to the next release with OSS/Update enabled (and any source/debug repos needed) and then update all the peripheral packages.
Necessary?
On 2020-06-24 8:19 p.m., David C. Rankin wrote:
On 06/24/2020 04:48 PM, Felix Miata wrote:
zypper -v in --download-in-advance zypper libzypp libsolv-tools rpm libproxy1 libmodman1 curl libcurl openSUSE-release zypper -v in --download-in-advance device-mapper dmraid glibc multipath-tools mdadm systemd udev zypper -v up zypper -v dup # (if applicable, after doing zypper up)
What about disabling non-openSUSE distro repos for the dup and then enabling them for a zypper up after the dup?
One of the URLs Carlos posted strongly recommends doing this, so from your experience, I'd suggest the answer is: Necessary? -- Yes.
I'm making decent progress in getting this sorted out; thanks to everyone who has contributed so far.
For Carlos: read paragraph 4. of the first url you posted: https://en.opensuse.org/SDB:System_upgrade You'll find it very enlightening re: zypper --releasever=xxxx dup :D
On 25/06/2020 04.45, Darryl Gregorash wrote:
On 2020-06-24 8:19 p.m., David C. Rankin wrote:
On 06/24/2020 04:48 PM, Felix Miata wrote:
zypper -v in --download-in-advance zypper libzypp libsolv-tools rpm libproxy1 libmodman1 curl libcurl openSUSE-release zypper -v in --download-in-advance device-mapper dmraid glibc multipath-tools mdadm systemd udev zypper -v up zypper -v dup # (if applicable, after doing zypper up)
What about disabling non-openSUSE distro repos for the dup and then enabling them for a zypper up after the dup?
One of the URLs Carlos posted strongly recommends doing this, so from your experience, I'd suggest the answer is: Necessary? -- Yes.
I'd leave packman enabled, or it will ask permission to change repo for a lot of packages.
I'm making decent progress in getting this sorted out; thanks to everyone who has contributed so far.
For Carlos: read paragraph 4. of the first url you posted: https://en.opensuse.org/SDB:System_upgrade You'll find it very enlightening re: zypper --releasever=xxxx dup :D
Ok, I'll read it tomorrow - 5 AM here now :-) I'm just having a quick look before hibernating.
On 25/06/2020 05.00, Carlos E. R. wrote:
On 25/06/2020 04.45, Darryl Gregorash wrote:
On 2020-06-24 8:19 p.m., David C. Rankin wrote:
On 06/24/2020 04:48 PM, Felix Miata wrote:
...
I'm making decent progress in getting this sorted out; thanks to everyone who has contributed so far.
For Carlos: read paragraph 4. of the first url you posted: https://en.opensuse.org/SDB:System_upgrade You'll find it very enlightening re: zypper --releasever=xxxx dup :D
Ok, I'll read it tomorrow - 5 AM here now :-) I'm just having a quick look before hibernating.
I almost forgot, so I just read it :-)
Yes, it is interesting. Still, I may keep using the manual mode of editing the repositories manually, because I take the chance to also edit names for consistency, disable some repos I really to not want to keep during the upgrade, whatever.
I noticed this warning:
Warning: It is strongly recommended that you run the upgrade outside the X-window graphical mode. Thus it is recommended you run the command from either runlevel 3 (text + network), or a virtual console. Unfortunately many times the WIFI connection is managed/available only in runlevel 5, so a virtual text console may be best while staying logged into the graphical console behind the scenes. People had their X session stopped/crashed during the upgrade, causing the upgrade to abort, which in turn left the system in an inconsistent state. To change to runlevel 3, see SDB:Switch_runlevel. To remain in runlevel 5, but use a "virtual console", type control-alt-F1 (as an example).
We should add instructions to recover the network in text mode, using nmcli or nmtui. If the package is not installed by default, install it prior to the dup.
David C. Rankin composed on 2020-06-24 21:19 (UTC-0500):
What about disabling non-openSUSE distro repos for the dup and then enabling them for a zypper up after the dup?
When I duped to 15.1 with all repos enable I had vendor changes that caused issues (specifically qt3 and others were pulled from packman instead of OSS/Update that caused fits until the change was discovered)
The intent being to dup to the next release with OSS/Update enabled (and any source/debug repos needed) and then update all the peripheral packages.
Necessary?
Probably depends on admin's experience level, and actual repos involved. URLs for those I typically have for /any/ dup are:
Enabled: http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSEblahblah/ Disabled: http://silk.apana.org.au/rpm-opensuseblahblah-unstable-dev fcl http://opensuse-guide.org/repo/openSUSEblahblah/ libdvdcss2
Any time I have something installed from outside openSUSE or Packman, I normally lock the package and/or disable its repo. All my most used web browsers come from their creators sites from single archive files and live in /usr/local/, so are usually unaffected by distribution upgrades.
I never have NVidia enabled, almost never Chrome, and rarely have any but the above enabled, so I really don't need to think about it as the times come. IMO, pretty much any other enabled would be cause to expect unnecessary trouble.
On 2020-06-24 10:02 p.m., Felix Miata wrote:
David C. Rankin composed on 2020-06-24 21:19 (UTC-0500):
those I typically have for /any/ dup are:
Enabled: http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSEblahblah/ Disabled: http://silk.apana.org.au/rpm-opensuseblahblah-unstable-dev fcl http://opensuse-guide.org/repo/openSUSEblahblah/ libdvdcss2
Why disable the libdvdcss2 repo?
Also, would you disable a local repo, eg. a directory containing a printer driver from the manufacturer? My printer has never been supported in Linux, so I downloaded the drivers from Brother and made a repo out of the directory they're in. I'd also very much appreciate if someone currently running the 15.2 RC could check in Yast/Printers to see if the Brother DCP-7040 is now supported. TIA.
Darryl Gregorash composed on 2020-06-25 09:10 (UTC-0600):
Why disable the libdvdcss2 repo?
Easier than making sure it even has the current version if the release is fresh. I've never had the current one uninstalled at upgrade time, or any other time.
Also, would you disable a local repo, eg. a directory containing a printer driver from the manufacturer? My printer has never been supported in Linux, so I downloaded the drivers from Brother and made a repo out of the directory they're in. I'd also very much appreciate if someone currently running the 15.2 RC could check in Yast/Printers to see if the Brother DCP-7040 is now supported.
I've never had a Brother printer driver uninstalled at upgrade time, or any other time. Both my current printers are Brother: HL5470DW & MFC8910DW. The 5470 was installed in 2016 on IP. I don't remember if it was any trouble or not to get to work. The MFC on IP I have yet to get recognized, which since I don't need it for printing I haven't found time to figure out.
On 2020-06-25 9:30 a.m., Felix Miata wrote:
Darryl Gregorash composed on 2020-06-25 09:10 (UTC-0600):
Why disable the libdvdcss2 repo?
Easier than making sure it even has the current version if the release is fresh. I've never had the current one uninstalled at upgrade time, or any other time.
Would zypper not complain if it could not find a valid repository for the new version? If so, then it would just ignore (or ask to ignore) that repo, would it not?
Also, would you disable a local repo, eg. a directory containing a printer driver from the manufacturer? My printer has never been supported in Linux, so I downloaded the drivers from Brother and made a repo out of the directory they're in. I'd also very much appreciate if someone currently running the 15.2 RC could check in Yast/Printers to see if the Brother DCP-7040 is now supported.
I've never had a Brother printer driver uninstalled at upgrade time, or any other time. Both my current printers are Brother: HL5470DW & MFC8910DW. The 5470 was installed in 2016 on IP. I don't remember if it was any trouble or not to get to work. The MFC on IP I have yet to get recognized, which since I don't need it for printing I haven't found time to figure out.
Are those 2 printers already supported in Linux, or did you have to download the necessary drivers from Brother? The DCP-7040 has never been supported in 15.1 or any previous version, so I have been using the drivers from Brother. If it is now supported, I would like to dispense with those drivers, if possible.
On 29/06/2020 20.30, Darryl Gregorash wrote:
On 2020-06-25 9:30 a.m., Felix Miata wrote:
Darryl Gregorash composed on 2020-06-25 09:10 (UTC-0600):
Why disable the libdvdcss2 repo?
Easier than making sure it even has the current version if the release is fresh. I've never had the current one uninstalled at upgrade time, or any other time.
Would zypper not complain if it could not find a valid repository for the new version? If so, then it would just ignore (or ask to ignore) that repo, would it not?
No, it will ask to remove the packages from that repo if it doesn't find them in another repo.
That's the reason to carefully inspect the list of active repositories, decide which to remove, which to upgrade.
29.06.2020 21:46, Carlos E. R. пишет:
On 29/06/2020 20.30, Darryl Gregorash wrote:
On 2020-06-25 9:30 a.m., Felix Miata wrote:
Darryl Gregorash composed on 2020-06-25 09:10 (UTC-0600):
Why disable the libdvdcss2 repo?
Easier than making sure it even has the current version if the release is fresh. I've never had the current one uninstalled at upgrade time, or any other time.
Would zypper not complain if it could not find a valid repository for the new version? If so, then it would just ignore (or ask to ignore) that repo, would it not?
No, it will ask to remove the packages from that repo if it doesn't find them in another repo.
No, it won't. If package is not present in enabled repositories, it won't be touched at all if possible. If package cannot be left on system due to dependencies, zypper will ask for user decision, and removing package will be one of presented choices. But that is not related to "doesn't find in another repo".
That's the reason to carefully inspect the list of active repositories, decide which to remove, which to upgrade.
On 2020-06-29 12:46 p.m., Carlos E. R. wrote:
On 29/06/2020 20.30, Darryl Gregorash wrote:
On 2020-06-25 9:30 a.m., Felix Miata wrote:
Darryl Gregorash composed on 2020-06-25 09:10 (UTC-0600):
Why disable the libdvdcss2 repo?
Easier than making sure it even has the current version if the release is fresh. I've never had the current one uninstalled at upgrade time, or any other time.
Would zypper not complain if it could not find a valid repository for the new version? If so, then it would just ignore (or ask to ignore) that repo, would it not?
No, it will ask to remove the packages from that repo if it doesn't find them in another repo.
That's the reason to carefully inspect the list of active repositories, decide which to remove, which to upgrade.
Which is why the instructions on one of the URLs you posted say to do this first:
zypper --releasever=15.2 refresh
That will catch a non-existent URL, will it not? If it still wants to remove the packages (apart from debug and devel packages, there is only one), can you not then tell it to leave the package alone? Anyway, libdvdcss is on an openSUSE site, so I am not expecting there to be any problems here -- and if there are, then I know of no other place to get those packages, except maybe on VideoLAN, which opens up a whole different bag of potential problems (eg. do you want VLC from VideoLAN, or from Packman?).
Note that first it is necessary to edit the file in /etc/zypp/repos.d for that repository: baseurl=http://opensuse-guide.org/repo/openSUSE_Leap_15.1/ and change that to read: baseurl=http://opensuse-guide.org/repo/openSUSE_Leap_$releasever/
The Packman repository must be similarly edited -- and I have verified with the Packman repo that this procedure works.
On 2020-06-29 1:18 p.m., Darryl Gregorash wrote:
Note that first it is necessary to edit the file in /etc/zypp/repos.d for that repository: baseurl=http://opensuse-guide.org/repo/openSUSE_Leap_15.1/ and change that to read: baseurl=http://opensuse-guide.org/repo/openSUSE_Leap_$releasever/
Those instructions you posted also said to do the above:
sudo sed -i 's/15.1/$releasever/g' /etc/zypp/repos.d/*.repo
On 29/06/2020 21.18, Darryl Gregorash wrote:
On 2020-06-29 12:46 p.m., Carlos E. R. wrote:
On 29/06/2020 20.30, Darryl Gregorash wrote:
On 2020-06-25 9:30 a.m., Felix Miata wrote:
Darryl Gregorash composed on 2020-06-25 09:10 (UTC-0600):
Why disable the libdvdcss2 repo?
Easier than making sure it even has the current version if the release is fresh. I've never had the current one uninstalled at upgrade time, or any other time.
Would zypper not complain if it could not find a valid repository for the new version? If so, then it would just ignore (or ask to ignore) that repo, would it not?
No, it will ask to remove the packages from that repo if it doesn't find them in another repo.
Andrei says this it not the case. Well, I don't remember. But I did have to lock a bunch of packages in the past, like for example, rekall.
That's the reason to carefully inspect the list of active repositories, decide which to remove, which to upgrade.
Which is why the instructions on one of the URLs you posted say to do this first:
zypper --releasever=15.2 refresh
That will catch a non-existent URL, will it not? If it still wants to remove the packages (apart from debug and devel packages, there is only one), can you not then tell it to leave the package alone?
Yes, you can.
Anyway, libdvdcss is on an openSUSE site,
No, it is external. For legal reasons.
so I am not expecting there to be any problems here -- and if there are, then I know of no other place to get those packages, except maybe on VideoLAN, which opens up a whole different bag of potential problems (eg. do you want VLC from VideoLAN, or from Packman?).
Note that first it is necessary to edit the file in /etc/zypp/repos.d for that repository: baseurl=http://opensuse-guide.org/repo/openSUSE_Leap_15.1/ and change that to read: baseurl=http://opensuse-guide.org/repo/openSUSE_Leap_$releasever/
I did not know that. It figures.
The Packman repository must be similarly edited -- and I have verified with the Packman repo that this procedure works.
Basically, I leave activated repositories that have packages not available on the base distro. If they are duplicated (for instance, a KDE repo), I remove the repo (but this will make zypper ask you a hundred times, one per package that changes repo, I think). Packman I leave active.
On 2020-06-29 1:44 p.m., Carlos E. R. wrote:
On 29/06/2020 21.18, Darryl Gregorash wrote:
Anyway, libdvdcss is on an openSUSE site,
No, it is external. For legal reasons.
I just assumed, since it has opensuse in the URL, that openSUSE must own it. Whois shows that not to be the case.
I just added a repository with the URI http://opensuse-guide.org/repo/openSUSE_Leap_15.2 and successfully refreshed it. A quick check in YaST package management shows all the same packages as in the 15.1 repo are present.
Would you happen to know, if the file /etc/zypp/vars.d/releasever does not exist, where zypper/YaST store the $releasever variable?
On 30/06/2020 02.08, Darryl Gregorash wrote:
On 2020-06-29 1:44 p.m., Carlos E. R. wrote:
On 29/06/2020 21.18, Darryl Gregorash wrote:
Anyway, libdvdcss is on an openSUSE site,
No, it is external. For legal reasons.
I just assumed, since it has opensuse in the URL, that openSUSE must own it. Whois shows that not to be the case.
But it is not opensuse.org domain name ;-)
I just added a repository with the URI http://opensuse-guide.org/repo/openSUSE_Leap_15.2 and successfully refreshed it. A quick check in YaST package management shows all the same packages as in the 15.1 repo are present.
Would you happen to know, if the file /etc/zypp/vars.d/releasever does not exist, where zypper/YaST store the $releasever variable?
That part is new to me. There is nothing in that directory in my machine. I suspect it is the call to "zypper --releasever=xxxx" which fills the variable. However, the current release number is in "/etc/os-release".
On 2020-06-29 7:01 p.m., Carlos E. R. wrote:
On 30/06/2020 02.08, Darryl Gregorash wrote:
Would you happen to know, if the file /etc/zypp/vars.d/releasever does not exist, where zypper/YaST store the $releasever variable?
That part is new to me. There is nothing in that directory in my machine. I suspect it is the call to "zypper --releasever=xxxx" which fills the variable. However, the current release number is in "/etc/os-release".
No, it isn't the --releasever option that fills it in. Here is the file for the main OSS repo:
# cat /etc/zypp/repos.d/repo-oss.repo [repo-oss] name=Main Repository enabled=1 autorefresh=1 baseurl=http://download.opensuse.org/distribution/leap/$releasever/repo/oss/ path=/ type=rpm-md keeppackages=0
If you go to the YaST repository manager, you will see that it shows the baseurl as above, along with the actual URL, with $releasever replaced by the current release version number.
Both zypper and YaST must be getting the version from /etc/os-release, but if /etc/zypp/vars.d/releasever exists, that will be used instead -- at least for zypper. Using --releasever option will also override any other stored version. Just my guess, though.
On 30/06/2020 03.19, Darryl Gregorash wrote:
On 2020-06-29 7:01 p.m., Carlos E. R. wrote:
On 30/06/2020 02.08, Darryl Gregorash wrote:
Would you happen to know, if the file /etc/zypp/vars.d/releasever does not exist, where zypper/YaST store the $releasever variable?
That part is new to me. There is nothing in that directory in my machine. I suspect it is the call to "zypper --releasever=xxxx" which fills the variable. However, the current release number is in "/etc/os-release".
No, it isn't the --releasever option that fills it in. Here is the file for the main OSS repo:
# cat /etc/zypp/repos.d/repo-oss.repo [repo-oss] name=Main Repository enabled=1 autorefresh=1 baseurl=http://download.opensuse.org/distribution/leap/$releasever/repo/oss/ path=/ type=rpm-md keeppackages=0
If you go to the YaST repository manager, you will see that it shows the baseurl as above, along with the actual URL, with $releasever replaced by the current release version number.
Both zypper and YaST must be getting the version from /etc/os-release, but if /etc/zypp/vars.d/releasever exists, that will be used instead -- at least for zypper. Using --releasever option will also override any other stored version. Just my guess, though.
Well, normally the version must be the current one. It should be the "next" one when upgrading to the next one, an override.
Hi,
Am Donnerstag, 25. Juni 2020, 04:19:53 CEST schrieb David C. Rankin:
On 06/24/2020 04:48 PM, Felix Miata wrote:
zypper -v in --download-in-advance zypper libzypp libsolv-tools rpm libproxy1 libmodman1 curl libcurl openSUSE-release zypper -v in --download-in-advance device-mapper dmraid glibc multipath-tools mdadm systemd udev zypper -v up zypper -v dup # (if applicable, after
doing
zypper up)
What about disabling non-openSUSE distro repos for the dup and then enabling them for a zypper up after the dup?
When I duped to 15.1 with all repos enable I had vendor changes that caused issues (specifically qt3 and others were pulled from packman instead of OSS/Update that caused fits until the change was discovered)
I actually always increase (by setting them to 90) the priority of the main openSUSE repos. This way I can leave all other repos active even during dup. At least that never caused me problems so far, as this way those repos will only be used for additional software or that which I actively pull from those.
Kind Regards, Matthias
On 03/07/2020 14.12, Matthias Bach wrote:
Hi,
Am Donnerstag, 25. Juni 2020, 04:19:53 CEST schrieb David C. Rankin:
On 06/24/2020 04:48 PM, Felix Miata wrote:
zypper -v in --download-in-advance zypper libzypp libsolv-tools rpm libproxy1 libmodman1 curl libcurl openSUSE-release zypper -v in --download-in-advance device-mapper dmraid glibc multipath-tools mdadm systemd udev zypper -v up zypper -v dup # (if applicable, after
doing
zypper up)
What about disabling non-openSUSE distro repos for the dup and then enabling them for a zypper up after the dup?
When I duped to 15.1 with all repos enable I had vendor changes that caused issues (specifically qt3 and others were pulled from packman instead of OSS/Update that caused fits until the change was discovered)
I actually always increase (by setting them to 90) the priority of the main openSUSE repos. This way I can leave all other repos active even during dup. At least that never caused me problems so far, as this way those repos will only be used for additional software or that which I actively pull from those.
I set the priority of packman to be higher (ie, by setting it to 80) than the main openSUSE repos, as obviously we want to keep using the packman version. But there are exceptions.
Darryl Gregorash schrieb am 24.06.20 um 21:03:
Can a version upgrade be done entirely within YaST? Specifically:
- amend all repositories from 15.1 to 15.2
- use Online Update to do a "force update all"
1) can be done semi-automatic by using URLs like
http://download.opensuse.org/repositories/Apache/openSUSE_Leap_$releasever/
instead of the hardcoded "15.1" or "15.2"
This also works with http://download.opensuse.org/distribution/leap/$releasever/repo/oss/
Also, can this be done from within a graphical session from a user account, should it be done when logged in as root, or should it be done strictly from a command line, but not logged into a graphical session?
Of course you cannot do this as a user. Managing packages requires root rights. Even when you are logged into your computer on a graphical interface as a user, you have to enter root's password to get into YaST (to get root's rights).
I prefer doing this from the command line on a console, not inside a graphical environment. When the old packages are removed and the new ones are installed, the envoronment may simply crash. That leaves you in a nasty inconsistent state, and you have to start from the beginning, hoping that zypper will not be too confused to really do what needs to be done...
Werner --
Hi,
Am Mittwoch, 24. Juni 2020, 21:03:22 CEST schrieb Darryl Gregorash:
Can a version upgrade be done entirely within YaST? Specifically:
- amend all repositories from 15.1 to 15.2
- use Online Update to do a "force update all"
Also, can this be done from within a graphical session from a user account, should it be done when logged in as root, or should it be done strictly from a command line, but not logged into a graphical session?
Having upgraded several systems last night, the to me easiest way is to follow the console instructions on https://en.opensuse.org/SDB:System_upgrade.
I have actually run this from the graphical session on two systems that otherwise would not have had network access. The two caveats I experienced are: * The lock-screen will break at some point so you will have to follow the instructions it displayed to unlock it from a terminal session. * Logout in KDE no longer worked in the end so I had to trigger the reboot from a terminal session. Thus, I'd recommend to actually run the upgrade from terminal but you should be fine doing it from the graphical session.
Kind Regards, Matthias
On 7/3/20 8:15 AM, Matthias Bach wrote:
Hi,
Am Mittwoch, 24. Juni 2020, 21:03:22 CEST schrieb Darryl Gregorash:
Can a version upgrade be done entirely within YaST? Specifically:
- amend all repositories from 15.1 to 15.2
- use Online Update to do a "force update all"
Also, can this be done from within a graphical session from a user account, should it be done when logged in as root, or should it be done strictly from a command line, but not logged into a graphical session?
I didn't see any posts talking about the "traditional upgrade" method "that has been available for ages, at least since version 5.2". I have used this primarily since 6.x, and for me this method works better than zypper.
https://en.opensuse.org/SDB:System_upgrade https://en.opensuse.org/SDB:Offline_upgrade
"It is safer and more versatile than the live upgrade (zypper dup), because the system is taken offline, the upgrade is done from a small live system running off the DVD. There is no need to stop and start services. There are no problems with changing in use, important, libraries."
And, "the zypper live upgrade does not do all of the cleanup and maintenance that an offline DVD Upgrade does." I have been bitten before by software only upgrades. As with the fresh install, I get a bit better visibility of the changes the upgrade will make and can deal with those before the fact.
Additionally, for me at least, I find that the graphical YaST software module included with the DVD to be more friendly and helpful in managing dependency issues because of its flexibility and ease of searching for/inside other packages. This is probably not much of an issue if one's system uses just the standard repo's + packman, but I always have ~dozen additional repo's like KDE:Extra or Community repo's from where I've fetched newer package versions.
Related, before an upgrade I also run the new KDE live DVD to check for potential hardware issues, and then a quick-n-dirty trial upgrade on a mirror.
Just my $.02.
-- DennisG MSI B450-A Pro, Ryzen 5 2400, 15GB, Leap 15.1, KDE 5.55/5.12.8, stock kernel
On 03/07/2020 17.44, DennisG wrote:
On 7/3/20 8:15 AM, Matthias Bach wrote:
Hi,
Am Mittwoch, 24. Juni 2020, 21:03:22 CEST schrieb Darryl Gregorash:
Can a version upgrade be done entirely within YaST? Specifically:
- amend all repositories from 15.1 to 15.2
- use Online Update to do a "force update all"
Also, can this be done from within a graphical session from a user account, should it be done when logged in as root, or should it be done strictly from a command line, but not logged into a graphical session?
I didn't see any posts talking about the "traditional upgrade" method "that has been available for ages, at least since version 5.2". I have used this primarily since 6.x, and for me this method works better than zypper.
https://en.opensuse.org/SDB:System_upgrade https://en.opensuse.org/SDB:Offline_upgrade
"It is safer and more versatile than the live upgrade (zypper dup), because the system is taken offline, the upgrade is done from a small live system running off the DVD. There is no need to stop and start services. There are no problems with changing in use, important, libraries."
Heh, I wrote most of that :-)
Unfortunately, for the 15.0 to 15.1 upgrade I could not use it. The upgrade aborted when it saw I have one reiserfs partition in use. For the first time in my life, I had to use the online upgrade method.
-
Andrei Borzenkov -
Carlos E. R. -
Darryl Gregorash -
David C. Rankin -
DennisG -
Felix Miata -
jdd＠dodin.org -
Matthias Bach -
Werner Flamme