Hello,
it is known that distribution upgrade must be done outside X Window. What are please risks of running distribution upgrade outside X Window and concurrent using some apps inside X Window ? For example using video player. I mean risks related to upgrade, not to X Window apps where crash can be expected.
it is known that distribution upgrade must be done outside X Window.
Where do you get this Information?
The nvidia.run must be installed in former named runlevel 3 (now multiuser.target)
I would not be so absolute to say “upgrade must be done outside X Windows”
But I’ve had had a few instances where an upgrade executed from within a windowed console did fail and become unbootable.
So, I would suggest “highly, highly recommended” although most upgrades I’ve done in a windowed console have been without incident.
It just depends on what you’re willing to risk, if there is a significant chance of failure I’m willing to trash the system and start over.
As for running any kind of application, not just graphical applications during an upgrade…
I wouldn’t recommend that.
It’s possible or perhaps even likely that the running process(es) will lock files which would at least prevent a successful upgrade, and possibly fail the upgrade as a whole. Depending on what is locked, it could even leave your system in an inconsistent state (partially upgraded, partially not) which could lead to a complex frankenstein situation.
An upgrade usually can complete in an hour or so, and depending on how the upgrade was done maybe a very large system update running another hour might be advisable, so IMO it shouldn’t be that much of burden to put a pause on your system’s workload for that amount of time.
IMO,
TSU
Eh, no offense meant, but this is nonsense. A dist upgrade is a dist upgrade and Tumbleweed does this all the time. I’ve never stopped the desktop / X from running to upgrade it. And, FWIW have done some 15.0 -> 15.1 upgrades from Konsole/Yakuake as well, where the only effect I saw was a short network disconnect on install of the networkmanager stack.
For the record:
I always do “zypper dup” within X on Tumbleweed.
I normally use an “xterm”. The important step, is that I then run “screen -L” in that “xterm” session, and do the “zypper dup” within there.
Occasionally (rarely) X crashes. In that case, I to go a terminal and run “tail -f” on the transcript created by “screen -L”. And the update might be still going on. I wait until it finishes before rebooting. The “screen” command isolates the update from the X environment.
I’ve had Plasma and GNOME freeze to the point that keyboard shortcuts and the power button didn’t work (I wasn’t upgrading). If that happens in your scenario, is the upgrade still happening in the virtual terminal? I have no idea.
I always log out of my desktop environment and run the upgrade while I do something away from the computer (e.g. eating, showering, cleaning, exercising, etc). Nothing desktop related can freeze the system, and my computer is almost completely focused on upgrading.
Yes, I have had that happen. But if I am running the update under “screen”, it continues. The “screen” command runs a terminal at a pretty basic level and keeps it running even when you cannot see the output.
https://en.opensuse.org/SDB:System_upgrade
Warning: It is strongly recommended that you run the upgrade outside the X-window graphical mode.
*
I should say "… distribution upgrade must be done outside X Window if you don’t want risk upgrade failure*"(which could lead to unbootable system)
I was doing distribution upgrade inside lxterminal until Leap 42.3 where it has crashed and system has become unbootable.
I’ve tried distribution upgrade of Leap 15.0 after logging out of the X Window. It has failed:
Removal of (98296)btrfsmaintenance-0.4.2-1.1.noarch(@System) failed:
Error: Subprocess failed. Error: RPM failed: error: can't create transaction
lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
Abort, retry, ignore? [a/r/i] (a): r
I had to
# init 3
# rm -rf /var/lib/rpm/.rpm.lock
Then I was able to finish distr. upgrade.
I would be glad if I know how to prevent it - it took considerable amount of time to resolve it.
Thank you, that’s interesting and maybe it could be mentioned in official documentation.
I was using lxterminal, distribution upgrade has just failed and ended before completing, all others including mouse and keyboard was working fine.
You can also read the “Discussion” behind the SDB (Discussion tab) for the experiences and reason why the recommendation exists today.
TSU
I remember having a similar problem with btrfsmaintenance during an upgrade; although, I don’t remember what I did to solve it.
I do remember reading this bugreport https://bugzilla.opensuse.org/show_bug.cgi?id=1110259
Currently, I uninstall btrfsmaintenance and perform maintenance manually approximately once a week.
zypper rm btrfsmaintenance
failed too.
Same problem with another package has appeared after
zypper al btrfsmaintenance
My current update procedure is:
zypper up btrfsmaintenance
zypper dup
As previously mentioned, I do this from a session running under “screen -L”.
The separate update of “btrfsmaintenance” is because I have learned the hard way that this package update can lockup. So it is easier to deal with that if I am only updating the one package at the time. And then I can update everything once that is done.
Well, thank you.