I have relied on Tumbleweed for some months now, update exclusively with zypper dup, and am curious about the practices of others with this command.
Three questions:
(1) Do you boot to console to run zypper dup, or run it in a terminal window with the desktop loaded?
I now press ‘e’ at the grub menu to boot to console before running the command, but wonder if I’m being overly cautious. **
** (2) How long have you waited between invocations of zypper dup?
I run zypper dup several times a week on the machine I use daily. I also installed it on a couple of laptops that get little use. I now worry that Tumbleweed could choke on the number of packages to be downloaded/updated if I let one of these laptops sit in mothballs for several months.
Has anyone let a Tumbleweed machine sit for many months (or longer) between zypper dup commands?**
** (3) Dealing with problem messages.
Problem: nothing provides cinnamon-settings-daemon >= 3.6.0 needed by cinnamon-settings-daemon-lang-3.6.1-1.1.noarch
Problem: nemo-3.4.7-1.3.x86_64 requires cinnamon-translations, but this requirement cannot be provided
Problem: nemo-3.4.7-1.3.x86_64 requires cinnamon-translations, but this requirement cannot be provided
Problem: nemo-3.4.7-1.3.x86_64 requires cinnamon-translations, but this requirement cannot be provided
Solution 1: deinstallation of cinnamon-settings-daemon-lang-3.4.4-1.3.noarch
Solution 2: keep obsolete cinnamon-settings-daemon-lang-3.4.4-1.3.noarch
Solution 3: break cinnamon-settings-daemon-lang-3.6.1-1.1.noarch by ignoring some of its dependencies
I am not as sophisticated as other Tumbleweed users, and often scratch my head about what to do. Usually, I take the first suggested option, and hope for the best. I’m curious about what others do.
Hi
I usually run a zypper dup via ssh to my Tumbleweed systems (Laptop and RPI3), just run the standard GNOME DE on the laptop plus a few extra repos eg hamradio. The RPI3 is a JeOS release. Run the screen command if on the DE of the laptop before a zypper dup.
Updates as per the ML notification of a new snapshot, but do miss the occasional one.
Don’t seem to hit many these days, if it’s a lang one, usually delete the offending package and run with --no-recommends.
I run it from a terminal window under the desktop.
However:
I first do:
screen -L
That way, if the desktop crashes, screen keeps running and my “zypper dup” keeps running. After a desktop crash or restart, I can use:
tail -f screenlog.0
to monitor the progress, and reboot when done.
I should add that, before the “zypper dup”, I use
rm screenlog.0
to remove the log from the previous update. Otherwise they are cumulative.
Desktop crashes are rare. I think the last one was more than a year ago. With the “screen -L”, I’m reasonably well protected from the effects.
(2) How long have you waited between invocations of zypper dup?
I am updating once or twice per week.
(3) Dealing with problem messages.
I can usually figure out what’s a suitable choice. Sometimes I look at the factory mailing list for hints. Occasionally, I skip an update if I can’t work it out.
Occasionally, I’ll cancel the update, then use Yast to explore why there’s a problem. That can give me hints on what to do.
For the first several weeks after migrating to TW [May/June this year] i dup’d daily or every other day, but over time i grew rebellious at the constant interruptions to my workflow [not from the dups per se, but from the need to then logout/in or more likely reboot each time afterwards]. Consequently i now dup ~weekly [ideally it’d be fortnightly, but my Tower has proven pathologically incapable of exceeding 6 days’ Uptime before freezing or auto-rebooting (the next one is “due” to occur tomorrow), after which i sometimes dup in the wan hope that maybe this time the underlying fault might be fixed]. I do review the Mailing List daily, & if i see any important security updates, or a Plasma update, then i’ll usually bring fwd my dup.
(1) Do you boot to console to run zypper dup, or run it in a terminal window with the desktop loaded?
Done thru Konsole in session though nickrets way has me intrigued
(2) How long have you waited between invocations of zypper dup?
Usually every 2 days at 100AM my time US CST I’m nocturnal so if it goes badly for me an inconvenience not a problem.
(3) Dealing with problem messages.
For me it depends some were for packages I no longer use or never did in these cases (the most recent xine) I’ll hit the deinstallation
If it’s a Packman Package being obsolete I’ll exit and wait sometimes TW gets away from them.
If it says something about i586 do I want the lower architecture I’ll just exit then wait a couple days.
So far in my experience with TW letting go of those obsolete packages has been good when it an opensuse package.
This is also where BTRFS and Snapper comes in handy (2x for me) however there was a time when Snapper didn’t work for me(only been once)
That’s why I go to the TW download site get the latest version if it works and make boot stick or a disc. This is my last resort if things go REALLY WRONG!!
1-I don’t remember ever doing dup while logged into any X session, reasons among which: a-I want to take expeditious advantage of all newly updated packages X uses; b-I don’t want to risk settings corruption that could result from a crash or forced app or X restart during the dup.
2-2 to 3 months between dups on TW are typical here, but they vary between as little as a day, and upwards of 6 months. I have one operable 32bit machine whose TW was last updated 101 weeks ago. I don’t download in advance either: commit.downloadMode = DownloadAsNeeded in zypp.conf.
3-problem messages I deal with ad hoc, seat of the pants, often retrying after tweaking mirror specifications in repos.d/
Thanks for the replies, one and all! I hadn’t known about the screen command (perhaps more evidence of how little I still know about Linux). I’ll experiment. And I’m relieved to learn that a regular user is able to go two to three months between dups. I may let my little-used laptops collect more dust before I haul them out for dup updates.
I have taken a ‘play it by ear’ approach to the problem messages, guess I’ll keep doing so.
I always run zypper dup --auto-agree-with-licenses in a terminal
**
**
(2) How long have you waited between invocations of zypper dup?
I have two machines. One is updated whenever modifications are pending, the other every two months. There is no difference between the two.
Dealing with problem messages.
You may use the following heuristic to reduce the number of messages. Most installations have several thousand packages installed from the main repository and several dozens from others such as packman and others. Get a sane installation by disabling all but #3, #4 and 5#:
Run zypper ref -f, zypper dup, zypper packages --unneeded, zypper packages --orphaned. Delete packages listed if appropriate. Enable the additional repositories one at a time and run zypper dup --from repo-name.
Thanks for the suggestions, Karl. zypper packages --unneeded and zypper packages --orphaned were new to me. Time for me to study zypper, now that I’m in the Tumbleweed camp. https://en.opensuse.org/SDBZypper_manual_(plain)
Use those two with care, it’s quite easy to accidentally remove a wanted package
For example:
The repository “http://opensuse-guide.org/repo/openSUSE_Tumbleweed/” is added to enable the installation of “libdvdcss”. As there is no subsequent need to update that package the repository is then disabled. Zypper will then regard “libdvdcss” as an orphaned package…
I normally use Yast for that. The “Package groups” view has entries for those.
Note that “unneeded” is not the same as “unwanted”. I have seen wanted packages listed there.
Removing an orphaned package sometimes brings up a conflict dialog (some other package has a dependency that would be broken). So I usually check those out carefully before removing.
The point I was making was not whether the package, in the example libdvdcss, was needed; but that if a package is installed and the repository from which it came is either disabled or removed, that package then becomes an orphan.
paul@Orion-15:~$ sudo zypper packages --orphaned
[sudo] password for root:
Loading repository data...
Reading installed packages...
S | Repository | Name | Version | Arch
---+------------+------------+------------+-------
il | @System | libdvdcss2 | 1.4.0-1.15 | x86_64
paul@Orion-15:~$
On your own system (as shown in post #10) the repository for that package (#7) is enabled, so it’s not orphaned.
I’ve no idea what package (on your system) requires it. Which raises another point; define “unneeded”, but VLC, k3b, and likely other media players, loose some “functionality” without it.
The bottom line is each user decides what’s “needed”…
It was a problem for me that after a long time before running the update, the amount of download size would reach some GBs and that would take me a lot of my time to download the updates…
So, for this case, I made a simple script for root that runs
zypper --gpg-auto-import-keys dup --download-only
. I’ve put this script to run once every two days using anacron, so it would download the updates when my father uses the computer (he is just surfing the web), saving me a lot of time if I cannot update the computer for a whole week.**
(1) Do you boot to console to run zypper dup… I’ve been using the terminal with desktop loaded or the “Update Manager” that pops near the desktop. I’m still not sure if the “update manager” does only a regular update or a dup. I was pretty sure that it was only regular updates, but I’ve seen some kernel updates that I think regular zypper update don’t do.**
**(2) How long have you waited between invocations of zypper dup? When possible, I try to update it every day I use my computer/notebook. I’d say at least once a week for my desktop, but my notebook is not used so often, or is used away from home or is running on batteries/slow connection, so it is dist-updated once a month or longer.
****(3) Dealing with problem messages.
**********I try to read and understand the message before choosing one. Usually the first solution is the best for me (like when it asks to change repo or something like that). When it generates more conflict, like uninstallation of more packages, I use YaST to check for more hints and do the least changes on other packages… I avoid “breaking” the packages.
