[06:09] <jakefb> Hi I have just upgrade to 18.04 but I am having an issue with systemd-modules-load
[06:10] <jakefb> when running systemctl status systemd-modules-load I get this:
[06:10] <jakefb> could not open moddep file '/lib/modules/4.14.135-rh164-20190731212002.xenU.x86_64/modules.dep.bin'
[06:10] <jakefb> anyone know why this is happening?
[06:12] <jakefb> I also get this error: Failed to lookup alias 'acpiphp': Function not implemented
[06:12] <lotuspsychje> jakefb: you might wanna idle a bit here, weekend & US wakeup might take a while
[06:13] <jakefb> lotuspsychje: okay thanks I'll wait and see if anyone can help
[13:11] <Greyztar> hello,when i do timedatectl list-timezones it only finds UTC, how do i get all the other zones or if so is there a way to install other timezones or to reinstall the whole timedatectl stuff?
[13:12] <Greyztar> also might mention zoneinfo directory isnt present in usr directory that might be it?
[13:35] <tomreyn> Greyztar: that's unusual, it should notmally list all the known time zones. you may want to install / reinstall tzdata
[13:36] <Greyztar> tomreyn: cheers ill try that,recently migrated server so its probably missing some stuff (,")
[13:39] <Greyztar> tomreyn: that worked like a charm,seems it was missing something from that package
[13:39] <tomreyn> Greyztar: migrated from what? you can "apt install ubuntu-server^"  (the ^ is NOT a typo) to ensure you have all the relevant packages installed.
[13:41] <tomreyn> the above command won't reinstall already installed packages nor restore configuration files for packages with dpkg-tracked configurations, though.
[13:42] <Greyztar> tomreyn: its an vps so i suspect they have slimmed down the image or so ,never had this problem at other providers though or my own regular installed server
[13:42] <Greyztar> tomreyn: but reinstalling that tzdata package added the missing timezones atleast so all good now cheers
[13:52] <tomreyn> Greyztar: servers are often set to UTC, so it's not too unusual, i guess, but, at least to me, it still seems wrong to delete files of installed packages in an image installation.
[13:53] <tomreyn> this and other reasons make me not want to use hosting companies' images at all.
[13:59] <Greyztar> tomreyn: yeah its abit odd, they also have a bunch of scripts running,couldnt at all figure out what was happening after i setup my iptables rules i couldnt log on anymore,after much research i managed to find the culprit,an ssh key import script was made so that the ssh service wouldnt start if that script failed none of them at support could tell me that before hand so that got a little spicy
[14:01] <tomreyn> you wih they'd all have proper documentation on the diff between a default ubuntu image and their customizations, so that you could easily cherry pick from those.
[14:02] <Greyztar> that would be great indeed (,")
[14:02] <tomreyn> unfortunately pretty much none offers this. you either go with their images or you are on your own, guessing, hoping things will work.
[14:03] <tomreyn> what i usually do is to boot into an imaged system, take notes on how it's setup, then do my own fresh install and redo the config as needed.
[14:04] <Greyztar> yeah that seems nice,although some only provide images and not like Vultr where one could install from your own iso thats a great feature though
[14:04] <tomreyn> so network configs, network mounts (if any), /root/.ssh/authorized_keys, /root/.ssh/config, /etc/hosts, /etc/hostname is usually what you need, but there can be more.
[14:07] <Greyztar> really happy i got time functioning again thank you very much!
[14:10] <tomreyn> you're welcome.
[23:21] <foo> This should not prompt for password if git user tries to run this command as dev user, correct? git ALL=(dev) NOPASSWD: /home/dev/deploy.sh
[23:21] <foo> It worked in a previous ubuntu installation but not another system, my error likely exists somewhere else
[23:22] <foo> oh, actually, it doesn't work on the old system either when I do... sudo -u dev /home/dev/deploy-shannon.sh ... hmm.
[23:23] <foo> err, well, old system had a different path for command, which is in visudo, and that did not prompt for password. /me investigates what is going on here
[23:26] <foo> ah, I know the problem. service changed