Unattended-upgrades

bcsol

Is it possible to do unattended-upgrades with Solus?
Much thanks!

inkbug

I was wondering that myself - I remember seeing posts about it, and went searching..

I haven't tried them yet myself, but I plan to, on the next Friday update.

check=1;while [[ check -eq 1 ]]; do sudo eopkg up; check=$?; done

from:
https://discuss.getsol.us/d/2116-updating-solus-4-0-hangs/7
and

until sh -c 'sudo eopkg up -y';do echo "Trying again";done

from:
https://discuss.getsol.us/d/3503-terminal-eopkg-commands-system-maintenance/6

WetGeek

inkbug I haven't tried them yet myself, but I plan to, on the next Friday update.

The unavoidable issue seems to be that if you use sudo, a password is needed. I've read a lot about bash scripts, but not yet seen a way to programmatically enter a password with an unattended script.

If it's started in a bash session that's already been elevated (i.e., using su), it would be a very simple script to write. Just call eopkg lu until success, theneopkg up.

brent

there's a sudo eopkg script or two in forums about how to keep an upgrade alive after launching it (in case of server error, hangs, stops, etc).

But a command you can schedule and don't have to manually start? Or an upgrade you autostart?
Appears the answer is no https://discuss.getsol.us/d/1421-auto-updates but this thread is over a year old..
edit: saw a typo

palto42

I will try to solve this with systemd services similar to the daily apt update/upgrade service on Ubuntu.
My idea is to start with to timers/services, one which runs an eopkg ur and second which updates important packages with eopkg up --security-only.
If this works, I may add a 3rd service for weekly full upgrades.

brent

palto42 call home/timer, trigger when upgrade available, download then install etc. That's a great start, and I hope you succeed. I'd love to "set it and forget" for Fridays myself. If you get that then you would have to build-in some kind of re-try loop for scenarios above.
***my digital vernacular is limited but I get the big idea

just

WetGeek The unavoidable issue seems to be that if you use sudo, a password is needed. I've read a lot about bash scripts, but not yet seen a way to programmatically enter a password with an unattended script.

That's true. But sudo password request in scripts, aliases, menu and shortcut commands, .desktop files may be bypassed if a user includes himself in sudo, wheel, another group and allows the members of that group to execute any command (including sudo) without asking for password.

inkbug

WetGeek I'll give it a try, thanks.

just Thanks - I haven't dealt with groups yet, but I'll look into it.

palto42

This is my current attempt for daily security upgrades:

If it works reliable, the normal output can be suppress with the >/dev/null, but for now I want to see all messages in the systemd journal.

brent

palto42 Slapping forehead now. Was in love with the idea of a full friday update on autopilot but I glossed over security-only tags for the scripts in your posts---I speed-read it, sign of the times. All on me.. Harvey is absolutely right. The danger of the partial update didn't occur to me til his post. Maybe experiment on your 'third service' option first?

Harvey

Not performing a full upgrade is not recommended an can cause breakages. The team has warned people of this many times and intends to remove the GUI option for it as people don't listen.

Also if you automate updates there exists the possibility you will reboot / shutdown / hibernate / suspend mid update which can cause breakages. Depending on what is broken it may not be easy to solve, i.e if the package manager is broken... good luck!

There have been several people wanting to do this in the past. One of which wanted to do it for an elderly family member. I warned them not to, they dismissed my warnings as unlikely an and came back a few months later full of piss and vinegar because the system would no longer boot. It was too difficult to instruct remotely for his elderly family member and he lived in another state.

Almost like I had warned him of this exact scenario occurring... 👀

Ultimately you can of course do what you want, but for anyone that does this, don't cry when it blows up in your face.

palto42

Harvey Thanks for your warning, I need to think a bit how this can be mitigated.

I understand the risk of interrupted upgrades since it causes some unexpected state. Except for hard-power off it should be possible to mitigate by features like systemd-inhibit which I already use for my automated backups. One issue with the systemd-inhibit is to properly notify the user, but this is a secondary issue for me.

What concerns me a bit is the other part of your warning about partial security-only updates. I understand that it's difficult to test and consider all possible dependencies, but is this risk really significant compared to not applying a security patch?
On the other hand, since non-security updates are usually only published on Friday, I might as well just do full upgrades on a daily base.

Is Ubuntu doing anything significantly different with their updates? I'm running a few servers and laptops with unattended updates for some years and never had any issues. (Main reason for still using Ubuntu on 2 of the laptops is that they are 32bit).

Harvey

palto42 What concerns me a bit is the other part of your warning about partial security-only updates. I understand that it's difficult to test and consider all possible dependencies, but is this risk really significant compared to not applying a security patch?

According to the developers and from personal experience helping users troubleshoot issues. Not performing a full upgrade causes a lot of breakages. If it was unlikely to occur I would not have mentioned it and the developers would not be looking to remove it from the software-center. You will eventually get breakages. Arch Linux also does not support partial updates (security updates only is still a partial update) an they explain it fairly well.

Arch Linux is a rolling release distribution. That means when new library versions are pushed to the repositories, the developers and Trusted Users rebuild all the packages in the repositories that need to be rebuilt against the libraries. For example, if two packages depend on the same library, upgrading only one package might also upgrade the library (as a dependency), which might then break the other package which depends on an older version of the library.

Source: https://wiki.archlinux.org/index.php/System_maintenance#Partial_upgrades_are_unsupported

As for Ubuntu, its not a rolling release. There are certain parts of the stack that will not or rarely see an update until the next release at which point most people reinstall instead of doing an in-place upgrade that their own documentation does not recommend.

palto42 On the other hand, since non-security updates are usually only published on Friday, I might as well just do full upgrades on a daily base.

All updates are pushed on Friday/Saturday depending on where you live. Sync's done on any other day are usually only to address important issues such as discord needing an update (this is really annoying) or security issues significant enough that waiting for next sync does not make sense. Most weeks there is only 1 sync.

DataDrake

Harvey As for Ubuntu, its not a rolling release. There are certain parts of the stack that will not or rarely see an update until the next release at which point most people reinstall instead of doing an in-place upgrade that their own documentation does not recommend.

Which is made even less likely to break by Ubuntu not making any major ABI changes until the next release. Compare that to us updating Qt5, detecting ABI removals, and needing to rebuild everything that uses Qt5 before the next sync.

palto42

Harvey & DataDrake Thanks for your detailed explanation.
Before giving up, I'm trying to mitigate the described issues by always doing full upgrade and preventing interruption with systemd-inhibit. What's still missing is some user notification about an on-going upgrade.