Thanks for your replies and patience @joekamprad. I found a workaround to the problem without actually solving it, so I’m going to mark this solved. Here’s what I did in case anyone else might have been affected by something in an updated nvidia video driver:
(1) At the grub menu, I pressed E to get into a screen to edit boot parameters. I went down to the line “linux” and entered “nomodeset” after “quiet”. CTRL-X to continue booting. This let me get to a login prompt.
(2) I logged in, installed the antergos nvidia-installer package in pacman, and then installed the nouveau drivers instead of the nvidia proprietary driver.
(3) Rebooted and was able to log into my system, and it’s functional, even though it doesn’t look as pretty as when I was using the nvidia driver. But something borked on the nvidia driver, and I don’t know how to fix that, so I will be content.
Thanks for your help. This was at least a learning experience.
Thanks for your reply @joekamprad. I did as you instructed (and I learned something else) and got the following output here: link text. If you (or anyone else) has time and inclination to look at it, perhaps it will mean more than it does to me (mostly gibberish). Thank you.
tl;dr possible nvidia driver issue after upgrade resulting in blank screen during boot; Xorg.0.log file has possible clues(?)
Hello. I am a very happy Antergos user, and am looking forward to the possibility of its legacy continuing through Endeavour or some similar project.
After the initial installation in January, 2019, I have not encountered any system-wide problems until earlier this week. I did the regular update/upgrade with no obvious problems.
I shut down my laptop for the night, and when I went to reboot the next morning, I saw the normal boot procedure start, the little systemd message that displays the version, and the disk check (the one that says file system is clean or something similar), and a few seconds later, a blank screen. Nothing else.
I tried to access a login screen by trying to get one of the tty sessions by pressing CTRL-F1, F2, etc., to no result.
CTRL-ALT-DEL reboots, and I can reproduce the above scenario endlessly, apparently.
WHAT I’VE DONE SO FAR
(1) After searching online, I came across a suggestion to use a live Antergos instance to mount my normal root partition, arch-chroot into that partition, and run a regular Pacman update/upgrade. It indicated success, but had no impact on the problem.
(2) I thought maybe the boot process had progressed far enough to generate some logs (at least I hoped so), so I looked through the log folder, and it appeared that the Xorg log file was the only possible candidate for relevance.
After looking at it, even though I didn’t understand most of it, I believe that the possible issue causing this problem is something to do with the Nvidia driver or a kernel module relating to the video card somehow.
I am motivated to have this be a learning experience (as it already has - I had never used arch-chroot before. That was cool to be able to run commands that way.)
However, I don’t want to just try random things from various Google searches, and risk breaking my system more seriously, so I’m asking for some suggestions about possible next steps to take in troubleshooting this issue.
I know Antergos isn’t active any longer, but I hesitate to ask for help on an Arch forum because the reception to such requests is not what I would call friendly from my lurking there.
I didn’t see a facility to attach a file (even though the sticky topic for attaching log files talks about doing so after zipping all the relevant files together), so I’m using a link to to hastebin for the Xorg.0.log file on my system.
Thanks for any help or suggestions.
@judd Thanks for the information. Since all indicators point to the likelihood that I’ve been digging the wrong (rabbit) hole, I’m going to mark this solved (which in this case means “closed”). At least I’ve learned something. Thanks to everyone who replied and/or read this topic.
@judd I think my system is using NetworkManager (I say that because it’s always high in the list of processes using CPU resources when I’m running BOINC). If there is a definite disconnect between the networkd daemon and the timesyncd daemon (i.e., timesyncd should work even if networkd isn’t running), I suppose I can mark this topic SOLVED and start a new topic along the lines of Network Time Sync. I’ll wait a little while to see if anyone has more possibilities.
@BlaiseD Thanks for your reply. The only reason I made the connection between the timesyncd daemon and the networkd daemon was a sentence in the Arch Wiki description for systemd-timesyncd (itself a quote from the systemd mailing list) that implies such a dependence. “The daemon runs with minimal privileges, and has been hooked up with networkd to only operate when network connectivity is available.”
Even though systemd-networkd isn’t running on my system, I definitely have network connectivity.
So it could be that there is some other problem. I will do some more looking into this – maybe I’m looking at the wrong thing totally (of course, the only reason I’m looking at Network Time Sync is because of a problem in KDE I’m having).
@karasu Thanks so much for your reply.
Here is the output of the first two items (neither showed anything except the message below):
‘’’[[email protected] ~]$ sudo networkctl > 20190209-Terminal-Output.txt
WARNING: systemd-networkd is not running, output will be incomplete.
[[email protected] ~]$ sudo networkctl status >> 20190209-Terminal-Output.txt
WARNING: systemd-networkd is not running, output will be incomplete.’’’
And here is the output of ‘ls -lh’ for ‘/etc/systemd/network’ with specific network information purged:
‘’‘IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback n/a unmanaged
2 enp60s0 ether n/a unmanaged
3 enp0s20f0u5u3 ether n/a unmanaged
4 wlp61s0 wlan n/a unmanaged
5 tun0 none n/a unmanaged ‘’’
SUMMARY: I need help to troubleshoot Network Time Synchronization failure at boot on my Antergos system as well as the failure of the systemd network service. Thanks for any suggestions or insights about where to start looking for a solution
BACKGROUND CONTEXT: I am on a two-week-old install of Antergos (my first experience with an Arch-based system) using Plasma/KDE as a primary environment.
The original problem I was trying to solve was the fact that in the Kontact/KOrganizer application, times associated with To-Do’s (e.g., with a task due date) keep changing from my system time (which is Eastern US) to UTC, which makes any assignment of a date and time useless. (This is the only instance of such behavior – my system time is correct, and the time settings in other contexts works with no problem – e.g., the dates and times of events in the calendar of the same application.)
My original attempt to solve this was to enable the setting in KDE to automatically adjust the time (via NTP or whatever protocol KDE uses for that setting). I went through the motions of enabling this feature, was asked to authenticate the change via password, and every time, it would revert back. Some digging online revealed that this is seemingly a common issue dating back a long time.
By pure coincidence, on a system boot shortly after I began searching for a solution, I noticed a message at boot-time scroll up the screen that indication that starting Network Time Synchronization failed – and this message was displayed several times. I learned that this failure was the repeated attempts of the systemd-timesyncd.service to start at boot. I thought that that might be why the setting in KDE didn’t work, so my focus moved to the systemd-timesyncd problem.
At some point in my search for fixes, I read that systemd-timesyncd is dependent upon systemd-networkd.service, so I looked at that, and discovered that it also failed to start, both at boot-time and subsequently when I would try to start it from a terminal.
So the problem snowballed thusly: KDE auto-time-sync setting --> systemd-timesyncd failure --> systemd-networkd failure
WHAT I HAVE DONE so far (not in the order I did them since I can’t remember) from various possible solutions online:
–> changed permissions from 777 to 700 on /var/lib/private
–> removed NTP (as a separate application – apparently timesyncd implements some version of NTP itself, independently of the NTP application)
–> edited timesyncd.conf (to comment out the “NTP” section to manually choose servers to use)
–> enabled NTP via timedatectl
When I found out that the systemd-networkd.service also wasn’t working, I decided to ask for some help, because (1) there is a evidently a larger problem with systemd on my system and (2) I didn’t want to just try random things without understanding better what the hell I was doing and end up making things worse (which I might have done with my attempts to diagnose and fix the systemd-timesyncd issue, but if so it’s not visible to me yet).
LOGS: portions of the output of
journalctl -xerelative to trying to start systemd-networkd.service. I’m not including anything related to systemd-timesyncd because I need to work on one thing at a time since I’m in this rabbit hole so far.
-- Subject: A start job for unit systemd-networkd.service has begun execution -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- A start job for unit systemd-networkd.service has begun execution. -- -- The job identifier is 3380. Feb 08 09:40:45 Area51-Alien systemd: systemd-networkd.service: Failed to determine user credentials: No such process Feb 08 09:40:45 Area51-Alien systemd: systemd-networkd.service: Failed at step USER spawning /usr/lib/systemd/systemd-networkd: No such process -- Subject: Process /usr/lib/systemd/systemd-networkd could not be executed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- The process /usr/lib/systemd/systemd-networkd could not be executed and failed. -- -- The error number returned by this process is ERRNO. Feb 08 09:40:45 Area51-Alien systemd: systemd-networkd.service: Main process exited, code=exited, status=217/USER -- Subject: Unit process exited -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- An ExecStart= process belonging to unit systemd-networkd.service has exited. -- -- The process' exit code is 'exited' and its exit status is 217. Feb 08 09:40:45 Area51-Alien systemd: systemd-networkd.service: Failed with result 'exit-code'. -- Subject: Unit failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- The unit systemd-networkd.service has entered the 'failed' state with result 'exit-code'. Feb 08 09:40:45 Area51-Alien systemd: Failed to start Network Service. -- Subject: A start job for unit systemd-networkd.service has failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- A start job for unit systemd-networkd.service has finished with a failure. -- -- The job identifier is 3380 and the job result is failed. Feb 08 09:40:45 Area51-Alien audit: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-networkd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Feb 08 09:40:45 Area51-Alien systemd: systemd-networkd.service: Service has no hold-off time (RestartSec=0), scheduling restart. Feb 08 09:40:45 Area51-Alien systemd: systemd-networkd.service: Scheduled restart job, restart counter is at 1. -- Subject: Automatic restarting of a unit has been scheduled -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Automatic restarting of the unit systemd-networkd.service has been scheduled, as the result for -- the configured Restart= setting for the unit. Feb 08 09:40:45 Area51-Alien sudo: pam_unix(sudo:session): session closed for user root Feb 08 09:40:45 Area51-Alien systemd: Stopped Network Service. -- Subject: A stop job for unit systemd-networkd.service has finished -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- A stop job for unit systemd-networkd.service has finished. -- -- The job identifier is 3386 and the job result is done.```
Hello everyone . . . and thank you to everyone who develops and uses Antergos for being such a welcoming and open community.
The longer-version intro:
Context: I started using Linux with Linux Mandrake back in 2001. I reverted to Windows in 2006 when I got a laptop that I couldn’t get Mandrake to run on.
In 2008, I was able to install Ubuntu on another laptop and used some version of Ubuntu (the latest with the Cinammon desktop which was - and is - a great and stable system) until a few weeks ago.
I first heard about Antergos last year on a podcast that I listen to, and installed it in a VM to see how the rolling-release thing would work. Everything ran smoothly, although I didn’t do very much with it in the VM other than update it to see if it would break. It did a couple of times, but both times, I found a solution in seconds by searching Google or DuckDuckGo.
Installing Antergos: After I decided to take the plunge and install Antergos as my main daily-use system, I didn’t have much luck in the beginning with a straight-forward install using the normal Antergos media. I experienced the commonly-reported errors with booting the live media and/or various problems with the Cnchi installer.
I almost gave up since I wasn’t having any problems with my old Ubuntu setup, but the idea of using an Arch-based rolling-release system was appealing to me.
I finally used an Antergos-derived installer I found referenced on this forum somewhere when I was searching for solutions for my installation issues called “Portergos”. There is an offline-installation option that worked perfectly for me, and I ended up with a working installation I could use to get to the system I wanted (using Plasma and KDE for the first time in years).
It was worth the effort and the time.
Experience so far. I have been using this new Antergos (or Antergos-based) system for a couple of weeks now and loving it. I haven’t even booted into my old Ubuntu system (though it’s still present as an option in grub along with Windows 10 which I use for games I can’t play on Linux yet), and I’m enjoying this latest incarnation of KDE (last time I used it was in the 3.xx series, and it became clunky as hell and unusable after a while).
I have found the Antergos community that I’ve interacted with so far to be welcoming and helpful, as I noted above. I must say that it’s nice to have an alternative to the rather off-putting (or so it seems to me) attitude the Arch Forums seem to have (that’s just from spending a lot of time reading it lately and not from any direct interaction).
If you bothered to read this far, thanks for being here and I’m sure I will be posting some questions as I try to get various things working (but nothing major).