I have a script that updates and synchronizes a bunch of things on my machine. One of the things it does is running sudo pamac upgrade --no-confirm to upgrade Manjaro and AUR packages.
Right now I have issues with PGP signature verification on some AUR packages when using sudo, but maybe they’ll go away.
In general, I don’t want to be forced to oversee the pamac upgrade command so that I can input my password when needed.
I’d like to either know how to stop the signature verification errors with sudo, or find another good way of upgrading pamac without having to watch it.
A solution I’ve seen in the past for managing AUR packages without using sudo was to create a dedicated Unix user that doesn’t require a password for running sudo, and do the package upgrades/installation with that user.
Does anybody practice this approach?
As for the risk of automatic package upgrades: yes, I know that sometimes things can break, and require manual intervention. But I’m willing to do the fixes if something really brakes.
For me that only happens 2-4 a year, I think.
Also, I’m planning on switching to BTRFS and doing snapshots before the upgrade, so I could rollback my system if there are issues.
No, it is a bad thing. pamac must be used without sudo, because otherwise the ownership and the permissions on the database will end up wrong. pamac will prompt one for a password when higher privileges are needed, but will run with lowered privileges when they are not needed.
What if pamac was always used as root? Would it mess up the permissions then? Are there any files that it must keep under the ownership of the regular (non-root) user? I don’t understand why package installation would have to deal with the regular user.
Also, would those incorrect permissions explain my PGP errors? They probably could.
Do you know what DB files would be the ones with messed up permissions?
Ah… true. Running the PKGBUILD as root is a bad idea. Would be cool if you could tell pamac what user to impersonate for the build.
For anybody who’ll have a similar usecase as I have in the future, this is what I’ll do to automatically sync AUR packages (the code will be running as root, and it’ll be somewhere around here):
stop using pamac install with sudo
pull the packages from AUR as a regular user: sudo -u <my user> git clone <aur package>
install their dependencies as root with pacman -S --asdeps
build the package as a regular user: sudo -u <my user> makepkg
install the built package as root: pacman -U <package file>
Does anybody know if some AUR helper can install the dependencies as root and build the package as regular user, as separate commands? Or in one go? Then I wouldn’t need to write it myself
My obsession is with not wasting my time watching over processes that are reliable enough to be run on their own
I’ve been using Manjaro for 3 years and I’ve noticed that running upgrades automatically doesn’t cause me issues often, so I don’t see a reason to stop doing it. The only hiccup was with some of the AUR packages (the reason behind this post).
Is that sentiment shared by the team that maintains Manjaro?
Automation is a great feature of Linux. I have 4 machines running pretty much the same Manjaro setup (only my Raspberry PI is a bit different, I still need to figure out a couple of things on it, but the package parity is amazing), and automation saves me a lot of time.
Of course, no one can force you to stop doing something with your own system. I wrote what I wrote just so that any new user reading this don’t get an idea that this is OK and safe thing to do.
I wonder how did you automate merging .pacnew files, checking if initramfs images were succesfully generated and such before rebooting, how did you automate ‘manual intervention’, occasionally needed by some changes in some packages, etc.
You didn’t? Then here you go… either you have to go over logs afterwards, or it’s just a matter of time before some reboot doesn’t boot anymore.
I’m sure it is. But even if El Presidente of Archlinux said it’s safe and ok, it wouldn’t matter. It’s how pacman and updates on arch work.
Yes and yes. There’s just not a safe way to do it when updating arch-based distros.
Yes. They don’t provide an “unattended-upgrade” service like Ubuntu and they provide a support thread for each available update.
Surely, it doesn’t happen that often but from time to time there are breaking changes in the updates. (E.g. tmux, kitty, i3, and picom changed the layout in their config files. An unsupervised upgrade will render your system inusable.)
That can very well be the case, but I don’t remember whether it happened yet. I do appreciate the risk, though, and I wholeheartedly agree that my approach is not suitable for anyone that can’t afford to mess up their system briefly.
I did make my system unbootable a couple of times (not with updates, I think), so I do have scripts (this and that) usable from a Live USB that chroot into my system, recreate initramfs and GRUB. So I could work with that if there was a failed update.
Also, my update script doesn’t run on its own - I choose when to fire (and forget) it. I don’t run when I couldn’t afford issues. Another thing that’s mitigating the risk for me is the fact that I have multiple laptops with the same configuration (synced with the script) and with important files synced with Syncthing at any given time. So if one gets borked and I really need to do some work, I can just grab another one.
I do want to make the firing of my script automated, though. But before that I want to experiment with BTRFS. Seems like with it, I could just snapshot the OS files before the update and automatically rollback, undoing the update, if there are any issues, making the automated approach quite safe.
When it comes to automating updates - my opinion has always been and will be onwards - don’t.
IMO - automating your updates - is a recipe for disaster - you can do it - and I wouldn’t say you shouldn’t.
Take the latest couple of stable updates where the forum is flooded with topics on python2, ceph, gtk2, openssl-1.1 - and there is likely more.
Then there is all those who like to tinker and tweak - on stable branch - using AUR packages - another recipe for disaster.
Then there is all those who manage to get kde-looks.org theme working - just to discover that next iteration of Plasma and Qt framework breaks their theme - causing sddm to lock up and plasma refuses to load.
So yes - I would NEVER recommend automation when it comes to updates.
Automation is good I use it everyday … but not my system syncs … NEVER.
You can find packages - like kernel-alive which works great until it don’t and you have no kernel on restart.
You can find automation in AUR which automates replacing running kernel - but there’s a reason you won’t find it in Arch repo - not even community.
