I thought I had removed Discover as I do not use it and do not need it.
Now after the update to Plasma 6 I get a popup in my taskbar but this is now a Discover popup and it keeps popping up with updates which I do not get with zypper dup.
Is there a simple guide to explain which are the “correct” updates to accept. I would rather stay with zipper dup and drop Discover for updates. Is this possible. Can I get rid of Discover?
Some day, you may want to use Discover.
As far as the pop-up in the System Tray, go to its settings, Entries, and for whichever entry you don’t want to see, set it to Always Hidden.
Hi myswtest, I hope your sw testing is working and thanks for your reply.
I may wish to use Discover but you will note it is a “Store” as in shop. When I shop I wish to look for what I want, not have stuff brought to my attention without my asking. The way Discover is working for me at present that it is asking me to upload stuff which is updating apps I do not even have installed.
Having explained, do you have answers to my questions?
Yes, you can uninstall Discover. It won’t hurt anything.
Yep, uninstalled it in my TW KDE VM as I too find it annoying having GUI programs locking zypp(er). The package to remove is discover6.
In Gnome I have removed gnome-software and locked it. Maybe you want to lock all discover* packages after removing it so it’s not added back again in the future with updates.
If you have installed applications in flatpak, these will not be updated with zypper dup, but you will also have to give flatpak update.
Discover updates everything.
Have systemd take care of daily backups and updates:
# /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/zypperoni ref
ExecStartPre=-/usr/bin/zypperoni --no-confirm dup-download
ExecStartPre=-/usr/bin/flatpak update --noninteractive
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
On Tumbleweed - yes. In general on openSUSE:
bor@tw:~> zypper se --requires-pkg -x discover6-notifier
Repository 'openSUSE-20221216-0 (20240329)' is out-of-date. You can run 'zypper refresh' as root to update it.
Repository 'openSUSE-Tumbleweed-Non-Oss (20240329)' is out-of-date. You can run 'zypper refresh' as root to update it.
Repository 'openSUSE-Tumbleweed-Update' is out-of-date. You can run 'zypper refresh' as root to update it.
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
--+------------------------------+----------------------------+--------
| patterns-kalpa-base | openSUSE Kalpa | package
| patterns-microos-desktop-kde | MicroOS KDE Plasma Desktop | package
bor@tw:~>
You can also just uninstall discover-notifier to get rid of the tray notifier while leaving discover in place to be run manually.
Yes, it’s in the patterns, you can still uninstall it, tell zypper to do it anyway, and then add a package lock, it won’t hurt anything.
Default for zypper dist-upgrade is option --recommends. Using this option would install some additional packages on infamous host erlangen:
erlangen:~ # zypper --non-interactive dist-upgrade --dry-run --recommends
Loading repository data...
Reading installed packages...
The following 2270 NEW packages are going to be installed:
Mesa-demo-egl NetworkManager-bluetooth NetworkManager-dns-bind NetworkManager-dns-dnsmasq NetworkManager-tui NetworkManager-wwan PackageKit PackageKit-backend-zypp PackageKit-branding-openSUSE PackageKit-gstreamer-plugin
...
xscreensaver xscreensaver-data xscreensaver-lang yast2-auth-client yast2-auth-server yast2-iscsi-client yast2-nfs-client yast2-sudo yast2-theme-breeze yast2-vpn yt-dlp-bash-completion
2270 new packages to install.
Overall download size: 911.7 MiB. Already cached: 31.5 KiB. After the operation, additional 2.5 GiB will be used.
Backend: classic_rpmtrans --dry-run
Continue? [y/n/v/...? shows all options] (y): y
Checking for file conflicts: (1 skipped) .............................................................................................................................................................................................[done]
Warning: 2269 packages had to be excluded from file conflicts check because they are not yet downloaded.
Note: Checking for file conflicts requires not installed packages to be downloaded in advance in
order to access their file lists. See option '--download-in-advance / --dry-run --download-only'
in the zypper manual page for details.
erlangen:~ #
As I don’t use these packages I tweaked the defaults:
erlangen:~ # grep ^solver /etc/zypp/zypp.conf
solver.onlyRequires = true
solver.allowVendorChange = true
solver.dupAllowVendorChange = true
solver.cleandepsOnRemove = true
erlangen:~ #
solver.onlyRequires = true prevents recommended packages I don’t use from being installed by zypper dist-upgrade.
Currently I don’t use any of the following:
erlangen:~ # zypper search discover6
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
--+------------------------------+-------------------------------------------+--------
| discover6 | Software store for the KDE Plasma desktop | package
| discover6-backend-flatpak | Flatpak Backend for Discover | package
| discover6-backend-fwupd | fwupd Backend for Discover | package
| discover6-backend-packagekit | PackageKit Backend for Discover | package
| discover6-lang | Translations for package discover6 | package
| discover6-notifier | Update notifier for KDE Software Manager | package
erlangen:~ #
Hi and very many thanks. This is exactly what I needed. I have uninstalled discover6 packages and set up the systemd app as you suggest. I think I have it right but failed when I ran it to test. I have:-
alastair@HP-Z640-1:~> systemctl status bkupd.service
× bkupd.service - Backup and atomic update
Loaded: loaded (/etc/systemd/system/bkupd.service; enabled; preset: disabled)
Active: failed (Result: exit-code) since Thu 2024-04-11 17:30:04 BST; 9min ago
Process: 16388 ExecStartPre=/usr/local/bin/check-device (code=exited, status=203/EXEC)
CPU: 737us
alastair@HP-Z640-1:~>
I assume this is because I ran it at 17:30 and I was not at the system time. Is that right?
Further to this I read your comments in the openchat
In my ignorance it is clear I have missed quite a bit from your suggested bkupd.service, namely info on /usr/bin/zipperoni (? a well know Pizza?!) and atomic-update among others.
Please could you steer me in the right direction because I think what you are suggesting fits my needs.
It was meant as a template, please modify it for your own use 
The first one is to check if device is not on metered network and has AC power, there are systemd native ways to check if the device is on AC power, perhaps you want to use that.
# /usr/local/bin/check-device
#!/usr/bin/env python3
########################################################
# Script to check the device stats to see if
# we can proceed with offsite backup and udpate
########################################################
import sys
import json
import subprocess
# Function to get output of shell command
def shell_exec(command):
res = subprocess.run(command, shell=True, capture_output=True, encoding="utf8", errors="replace")
output = res.stdout + res.stderr
return output.strip()
# Check if device is using metered network connection
command = "busctl --json=short get-property org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager Metered"
res = shell_exec(command)
res = json.loads(res)
if res.get("data") in [1, 3]:
print("Check failed. Currently using metered network connection.")
sys.exit(1)
# Check if device is on battery power
command = "busctl --json=short get-property org.freedesktop.UPower /org/freedesktop/UPower org.freedesktop.UPower OnBattery"
res = shell_exec(command)
res = json.loads(res)
if res.get("data") is True:
print("Check failed. Currently using battery power.")
sys.exit(2)
# If we're here, it means none of the checks failed
print("Checks passed. Proceeding...")
sys.exit()
borgmatic is only necessary if you plan on performing a backup prior to daily dup, highly recommended!
Packages to install: borgbackup borgmatic
Here’s my borgmatic config for backing up to a remote server using ssh:
# /etc/borgmatic/config.yaml
source_directories:
- /rootfs.latest
- /home.latest
- /opt.latest
- /root.latest
- /srv.latest
- /usr-local.latest
- /var.latest
repositories:
- ssh://borg@ml1.mymailcheap.com/./suse-pc
encryption_passphrase: "<your-borg-repo-password>"
retention:
keep_daily: 7
keep_weekly: 4
hooks:
before_backup:
- btrfs subvolume snapshot -r / /rootfs.latest
- btrfs subvolume snapshot -r /home /home.latest
- btrfs subvolume snapshot -r /opt /opt.latest
- btrfs subvolume snapshot -r /root /root.latest
- btrfs subvolume snapshot -r /srv /srv.latest
- btrfs subvolume snapshot -r /usr/local /usr-local.latest
- btrfs subvolume snapshot -r /var /var.latest
after_backup:
- btrfs subvolume delete /rootfs.latest
- btrfs subvolume delete /home.latest
- btrfs subvolume delete /opt.latest
- btrfs subvolume delete /root.latest
- btrfs subvolume delete /srv.latest
- btrfs subvolume delete /usr-local.latest
- btrfs subvolume delete /var.latest
on_error:
- btrfs subvolume delete /rootfs.latest
- btrfs subvolume delete /home.latest
- btrfs subvolume delete /opt.latest
- btrfs subvolume delete /root.latest
- btrfs subvolume delete /srv.latest
- btrfs subvolume delete /usr-local.latest
- btrfs subvolume delete /var.latest
Validate borgmatic config file:
borgmatic config validate
Initialize borg repo:
borgmatic rcreate -e repokey
Perform a backup (this may take a while as it’s a first time sync):
borgmatic --verbosity 2
List all backups:
borgmatic list
Get information about backups:
borgmatic info
zypperoni is optional, it makes downloading packages faster. Not very important for non interactive dup.
atomic-update is an alternative to transactional-update for read-write root filesystems and recommended to prevent waking up to a broken/inconsistent system after the nightly non-interactive dup. I will try to write up a more detailed guide on this sort of setup when I have some time and try to submit atomic-update to OBS. For now, you would have to grab it from Github and not implicitly trust me or the code, it’s just 500 SLOC so give it a read 
Hi and many thanks for instant reply. In short;
I do use AC power with UPS supplies on critical elements including switches and routers and broadband connections but even these can fail! (We live on a hill in Highland Perthshire and longer power cuts are not unusual) My working assumption is that I am OK for 99% of the time.
I am reviewing my backup policy including NAS devices and cloud. I do not do overnight backups yet and my systems are not critical, only the data. I am using both approaches on an ad hoc basis for now. All critical work related stuff is now on line. Changing times!!!
I would appreciate some more help editing your template. All my systems are now on btrfs. All my raid arrays are hardware raids and getting too old. The NAS boxes are all OK and have raid. I don’t think I need the atomic-update until I understand more about what the options are. I do want to get the zypper up done overnight and have sorted out my repo priorities and removed discover6.
When you have time please could you suggest edits.
Regards,
Budgie2
You should perform zypper dup on Tumbleweed (TW) and not up, assuming TW here because this thread is tagged as such.
Here’s a trimmed down version of the update systemd service/timer but without backups or other protections:
# /etc/systemd/system/dup.service
[Unit]
Description=Distribution upgrade
[Service]
Type=oneshot
ExecStartPre=/usr/bin/flatpak update --noninteractive
ExecStartPre=/usr/bin/zypper --non-interactive --no-cd refresh
ExecStart=/usr/bin/zypper --non-interactive --no-cd dist-upgrade --auto-agree-with-licenses
# /etc/systemd/system/dup.timer
[Unit]
Description=Distribution upgrade
[Timer]
Unit=bkupd.service
OnCalendar=*-*-* 03:00:00
[Install]
WantedBy=timers.target
Many thanks, will see how it goes.
Regarding the backups and protections I am slowly working through how to get borg packup to work on Qnap but meanwhile I shall see how this works for me in the cut down version.
Thanks again,
Budgie2
Hi,
I checked this out today to see it was working. Seems I have made an error as this is what I have:-
alastair@HP-Z640-1:~> sudo systemctl status dup.service
[sudo] password for root:
× dup.service - Distribution upgrade
Loaded: loaded (/etc/systemd/system/dup.service; enabled; preset: disabled)
Active: failed (Result: exit-code) since Sat 2024-04-13 10:48:09 BST; 1 day 7h ago
Process: 1311 ExecStartPre=/usr/bin/flatpak update --noninteractive (code=exited, status=0/SUCCESS)
Process: 1379 ExecStartPre=/usr/bin/zypper --non-interactive --no-cd refresh (code=exited, status=4)
CPU: 270ms
Apr 13 10:48:09 HP-Z640-1 zypper[1379]: - [|] Error trying to read from 'http://codecs.opensuse.org/openh264/openSUSE_Tumblewe>
Apr 13 10:48:09 HP-Z640-1 zypper[1379]: - Download (curl) error for 'http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed/c>
Apr 13 10:48:09 HP-Z640-1 zypper[1379]: Error code: Connection failed
Apr 13 10:48:09 HP-Z640-1 zypper[1379]: Error message: Could not resolve host: codecs.opensuse.org
Apr 13 10:48:09 HP-Z640-1 zypper[1379]: Please check if the URIs defined for this repository are pointing to a valid repository.
Apr 13 10:48:09 HP-Z640-1 zypper[1379]: Skipping repository 'Open H.264 Codec (openSUSE Tumbleweed)' because of the above error.
Apr 13 10:48:09 HP-Z640-1 zypper[1379]: Could not refresh the repositories because of errors.
Apr 13 10:48:09 HP-Z640-1 systemd[1]: dup.service: Control process exited, code=exited, status=4/NOPERMISSION
Apr 13 10:48:09 HP-Z640-1 systemd[1]: dup.service: Failed with result 'exit-code'.
Apr 13 10:48:09 HP-Z640-1 systemd[1]: Failed to start Distribution upgrade.
lines 1-17/17 (END)
I can understand the permissions problem but not the issue with the codec. Sadly I have no idea why this did not run as root. Hope you can help.
Budgie2
Could you provide the outputs of:
dig a codecs.opensuse.org
zypper lr -dP
sudo journalctl --no-pager -u dup.service
sudo zypper -vvv refresh
I was recently made aware of an official openSUSE package to handle dup automatically: os-update. Perhaps you want to use it for more safety, this trimmed down version lacks any sort of safety mechanisms to prevent applying faulty update or to warn when a an update fails.
Hi,
Too many lines for here. Should be on paste:-
(https://paste.opensuse.org/pastes/cc24f13c61b1)
Hope that is right.