0

A bit of history to explain my issue: I freshly installed Linux Mint 19.2 MATE 64bits on a new laptop.

After the installation I wanted to move the home directory on its own partition. I followed these instructions

I messed up a step in the middle as I ended up stuck on a login loop (back to the login screen after typing credentials). I managed to fix it:

  • /etc/psswd was pointing at the wrong path for my profile
  • home directory was own by root, changing it to my username helped

Problem is that I no longer have access to internet (Wifi). I'm suspecting some permissions problems somewhere but don't know where to start my searches. ls -l / shows all folders with root as owner except my home folder that I manually changed.

Now for the problem itself:

I can ping IP addresses in the terminal but pinging a domain name returns

ping: google.com: Name or service not known

Here are a few command results I used to narrow the problem down:

~$ ll /etc/resolv.conf
lrwxrwxrwx 1 root root 27 Nov 17 13:15 /etc/resolv.conf -> /run/resolvconf/resolv.conf
~$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#    DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
~$ systemd-resolve --status
Failed to get global data: Failed to activate service 'org.freedesktop.resolve1': timed out (service_start_timeout=25000ms)
~$ systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
   Active: **failed** (Result: resources) since Sun 2019-11-17 13:13:14 GMT; 5min ago
   Docs: man:systemd-resolved.service(8)
       https://www.freedesktop.org/wiki/Software/systemd/resolved
       https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
       https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
       Nov 17 13:13:14 y systemd[1]: systemd-resolved.service: Service has no hold-off time, scheduling restart.
       Nov 17 13:13:14 y systemd[1]: systemd-resolved.service: Scheduled restart job, restart counter is at 5.
       Nov 17 13:13:14 y systemd[1]: Stopped Network Name Resolution.
       Nov 17 13:13:14 y systemd[1]: systemd-resolved.service: Start request repeated too quickly.
       Nov 17 13:13:14 y systemd[1]: systemd-resolved.service: **Failed** with result 'resources'.
       Nov 17 13:13:14 y systemd[1]: **Failed to start Network Name Resolution.**

I've been googling for the past 4h but cannot find what is causing the problem.

Thanks for any information.

UPDATE:

  • I tried booting with an older kernel with no success
  • I tried booting from a live USB, everything works as expected
  • I noticed that if I restart too early after booting, I have a message saying mate-settings-daemon is not responding. Google hasn't helped so far to identify why but it is a recurring problem many people encountered over the years.
  • the time to boot increased quite a lot. systemd-analyze blame reveals that NetworkManager.service and NetworkManager-wait-online.service are using 31s out of the 32s needed to boot. I'm assuming this is because of a timeout while trying to reach a specific domain.

temporary workaround

breaking the symbolic link of resolv.conf and use a simple file with a nameserver does the job but I'm not sure what it implies down the chain to bypass resolvconf

rm -rf /etc/resolv.conf
echo "namesever 8.8.8.8" > /etc/resolv.conf
chattr +i /etc/resolv.conf
0

Several OS directories are owned by non-root accounts, as they're used to store data by unprivileged daemons that themselves are using a dedicated service account and not the root account.

Try fully removing the /var/lib/private/systemd/ directory. Its subdirectories belong to services which have DynamicUser=yes in their .service file, and the directory's ownership is actually used as the basis for the service account's UID.

1
  • Hi, thanks for your suggestion. I've tried removing that directory but it did not help, even after rebooting. – whyoji Nov 17 '19 at 17:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.