Ok, thanks for the info.
Didn’t notice because this cmd just shows one refresh output. It must know it was already refreshed at dup.
I agree, I don’t use Packman either but can you please explain what you use to handle codecs not included in VLC in the tw repos ?
Years ago I tried using the VLC repositories ( which have all the codecs I needed ) but occasionally zypper dup would have issues because of some library that tw was changing and the VLC repos were not updated to a newer version yet, so I switched back to the tw repos for VLC but i do run into some issues from time to time playing some videos.
I also have avoid flatpaks and basically get everything from the tw repos so I am really curious as to what you do regarding the codecs.
Thanks !
Flatpaks, a.o. VLC, Kdenlive, Ardour.
Thanks, appreciate it !
This is only GUI based programs. Several things for headless server will need packman or other repo or just another distro.
I use Tumbleweed on a aarch64 VM as server for its InfluxDB and Grafana and Telegraf. Of course there is no packman needed there. And Debian would need this ‘TIG-stack’ from other repos, so the integration from Tumbleweed is preferred.
For playing TV content in NL (KPN Digitenne public/FTA NPO 1 2 3 + 2 regional), one needs HEVC decoder. If from packman, it also plays content in browser, no other SW needed.
Back to topic, packman occasionally presents a dependency problem, but zypper options are offered to get it working, although that is not unattended, I need review and some thinking. But OK as it happens only once or twice a year or so is my experience and I do zypper dup about every 2 weeks on average. Sometimes every day and if you have an installation older than 2 years, forget updating is my experience, needed re-install ( or clone from existing up-to-date computer, that is what I usually do.
If one would use the flatpak Firefox or Chrome, there would be no need for Packman.
BTW and off-topic, it seems openSUSE has quite a dutch invasion going on …
There are configs for this, but basically (if autorefresh set for the repo), it will refresh, well “auto”, when longer then a certain time (10 mins?) ago. So in general no need do do that command first. It is one of those things that is copied again and again by people until everybody seems to believe it must be done. 
If flatpak is used you now have a two stage update process unless you use Discover which has been horribly buggy for me in the past. It’s alright now. If I’m a new user with a limited root partition it’s going to be installing everything in that with added bloat by default unless I specify a user installation. Then there’s flatpak overhead causing longer load times plus numerous other issues people have with flatpak. Plus they now have to familiarise themselves with all the quirks and particulars of flatpaks which in fairness they are probably going to do anyway at some stage…
All of this just to purge from your system the Packman repos which have been making Tumbleweed useful since before people even thought about Flatpaks.
Everything can be updated at once nightly. 
# /etc/systemd/system/bkupd.service
[Unit]
Description=Backup and atomic update
[Service]
Type=oneshot
ExecStartPre=/usr/local/bin/check-device
ExecStartPre=/usr/bin/borgmatic --verbosity 1 --syslog-verbosity 1
ExecStartPre=-/usr/bin/fwupdmgr -y refresh
ExecStartPre=/usr/bin/fwupdmgr -y update
ExecStartPre=/usr/bin/flatpak update --noninteractive
ExecStartPre=/usr/bin/zypper --non-interactive ref
ExecStartPre=-/usr/bin/zypper --non-interactive dup --download-only
ExecStart=/usr/bin/atomic-update --apply dup
# /etc/systemd/system/bkupd.timer
[Unit]
Description=Backup and atomic update
[Timer]
Unit=bkupd.service
OnCalendar=*-*-* 03:00:00
[Install]
WantedBy=timers.target
Thanks but since updates often break things(especially Nvidia drivers) I update when I’m around to see that everything is working properly and supervise the process. I’m not running a server and updates this frequent probably wouldn’t even be advisable on a server. I could also write a bash script to eliminate the two step update process but that doesn’t fix my issues with Flatpak. New users would now have to familiarise themselves with Flatpak as well as adding Systemd services.
The issue with Discover I had (and have) is that on lower-end systems that run from eMMC or even SD-card, it takes a lot of system resources at power-on or reboot. And all via GUI while I have all scripts in place to do updates unattended (and via remote ssh). So on one system I simply removed that whole Discover already, I thing more to follow.
The other thing is that it reminds me of Ubuntu’s snap, which I got rid of already long time ago and actually also whole Ubuntu as distro option since it is forced use of netplan.io even if you know perfectly well to manage complex networking via NetworkManager or systemd-networkd yourself via their respective config files.
Keeping loop-mounted images around on a Btrfs single subvol Zstd compressed rootfs volume is just a no-go for me.
1 Like
Thanks for the script, is indeed nice unattended. I know about nothing about flatpak, I think the only non-repo based binary package I use is linphone as the version included in the distros where unstable (just crashed immediately for the Tumbleweed one).
I use about the same strategy, at least for backup. I use snapper and direct btrfs commands to do backups (and a bit of rsync for non-Linux or the boot filesystems). For updating I at least initiate manually. For well-known x86_64, no problem, but various (older) ARM based computers are a real challenge every now and then, they sometime almost look like bricked because of bootloader and kernel issues.
A difference is that I sleep at night and so do most computers around. As all is Btrfs based, it can update in an atomic way for sure if you have planned so and setup things like that, so instead of at 03:00:00, I let it run at noon / lunchtime, or better when solar power / sun is at max.
I have done quite some effort to derive the perfect point in time throughout the year when that is, also depends on clouds etc. It also means for an off-grid system (solar powered) that no updating is done when not enough solar power. So another twist/aspect of ‘how often to do zypper dup’.
1 Like
“Buggy in the past” for me never has been a reason to hold something against some software in the present. For 3 months I’ve been doing this on my actual TW install:
- Update using Discover, copy zypper log away
- Rollback to previous snapshot and reboot
- Update using plain
zypper dup, copy zypper log away - Compare the 2 logs
This did not give any differences ( yeah, sure a google-chrome update hopped in between the 2 updates.
Another thing is that our KDE devs still setup a flatpak remote only for the system only. Kalpa f.e. does not, it sets up the flatpak remote only for the user.
With some recent flatpaks that did have issues, due to deltas being > allowed_compressed_size. So the safest would be to always use flatpak --user update --no-static-deltas
holy moly. I would never recommend this to anybody. Yes tech advanced to a point where most bios/firmware updates are not breaking anything. But I would never do this unsupervised. This is one of the quickest ways to get a paperweight
Hope you don’t recommend this to anybody.
2 Likes
And the usual redundant zypper ref before zypper dup…
1 Like
Aside from what @rrahl0 and @hui brought up, is that there is no health checking included, no failure notifications. One basically will not know what one gets after a reboot without continuous checking. This could even potentially cause corruption of the running system
Haven’t hit this bug yet! 
Could you elaborate on the risks? 
IIUC, fwupd has several guardrails built-in. It knows I’m running non-interactively so if interaction is required for something serious it shouldn’t proceed naively and brick the system! 
Not all repos are pre-configured with auto-refresh! 
It may occur that some repositories, when registered against the system, have not been configured to automatically look for new available updates during a
zypper-dup. For this reason it might be useful to accompany this command with another one forcing all repositories to check for new updates, resulting in the pair:
sudo zypper ref && sudo zypper dup
Some basic checks are included with check-device script. 
atomic-update makes sure bad updates aren’t applied. 
Since this is a pet machine, I check the service logs every morning. 
I have been running this setup for more than an year now without issues during which there were 2 major Gnome DE updates that were applied live without breaking the DE! 
Appreciate everyone’s thoughts & comments. 
You need to remember that most motherboards have only 1 copy of your bios/firmware. If anything goes wrong, your system won’t boot anymore (at all). So you would need to use external tools to reflash your bios/firmware, or replace your chip completely.
Yes fwupd has guardrails, but depending on what kind of hardware you have, it can still break stuff. Microsoft had issues with that (which uses the same technology to update). There are manufacturers who don’t fill in the correct information in the bios/firmware like Vendor ID, ID of the specific mainboard etc. So what happened in Windows “land”, Windows updated the bios/firmware and bricked the mainboard as the bios/firmware didn’t even check if a correct update is actually getting flashed. (These are mostly of chinese origin), but there are also issues with recognisable brands.
1 Like
“Buggy in the past” for me never has been a reason to hold something against some software in the present."
- usually I would agree with you and it sounds great. However Discover was touted as the solution in the past long before it became somewhat stable and was just part of the desktop by default regardless of the fact that it always crashed or did something cryptic.
That’s useful info. 
I would have to look into motherboards with a/b updates in the future - if I ever get to building a desktop PC! 
My current laptop doesn’t even get BIOS updates without booting from Windows. It was a whole ordeal I described in an older post! 
As for the non-interactive part, my thinking goes - if the firmware is bad it’s going to brick the system whether I run it interactively or not! 