☰

Linux Mint 19.2 DNS не разрешается после перемещения домой на свой собственный раздел

tag-icon • tag-icon dns linux-mint
Linux Mint 19.2 DNS не разрешается после перемещения домой на свой собственный раздел

Немного истории, чтобы объяснить мою проблему: я недавно установил Linux Mint 19.2 MATE 64bit на новый ноутбук.

После установки я хотел переместить домашний каталог на отдельный раздел. Я следовал этиминструкции

Я накосячил на шаге посередине, так как в итоге застрял на цикле входа (возврат к экрану входа после ввода учетных данных). Мне удалось это исправить:

  • /etc/psswd указывал на неправильный путь для моего профиля
  • Домашний каталог принадлежал пользователю root, изменение его имени на мое помогло

Проблема в том, что у меня больше нет доступа к интернету (Wi-Fi). Я подозреваю, что где-то есть проблемы с правами доступа, но не знаю, с чего начать поиски. ls -l / показывает все папки с root в качестве владельца, кроме моей домашней папки, которую я вручную изменил.

Теперь о самой проблеме:

Я могу пинговать IP-адреса в терминале, но пинг доменного имени возвращает

ping: google.com: Name or service not known

Вот несколько результатов команд, которые я использовал, чтобы сузить круг проблем:

~$ 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.**

Я гуглил последние 4 часа, но не могу найти причину проблемы.

Спасибо за любую информацию.

ОБНОВЛЯТЬ:

  • Я пробовал загрузиться со старым ядром, но безуспешно.
  • Я попробовал загрузиться с Live USB, все работает как надо.
  • Я заметил, что если я перезагружу слишком рано после загрузки, у меня появится сообщение о том, что mate-settings-daemon не отвечает. Google пока не помог определить причину, но это повторяющаяся проблема, с которой многие люди сталкивались на протяжении многих лет.
  • время загрузки значительно увеличилось. systemd-analyze blame показывает, что NetworkManager.service и NetworkManager-wait-online.service используют 31 из 32 секунд, необходимых для загрузки. Я предполагаю, что это из-за тайм-аута при попытке доступа к определенному домену.

временное решение

разрыв символической ссылки resolv.conf и использование простого файла с сервером имен решает эту задачу, но я не уверен, что это подразумевает в цепочке обхода resolvconf

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

решение1

Несколько каталогов ОС принадлежатне- учетные записи root, поскольку они используются для хранения данных непривилегированными демонами, которые сами используют выделенную учетную запись службы, а не учетную запись root.

Попробуйте полностью удалить /var/lib/private/systemd/каталог. Его подкаталоги принадлежат службам, имеющим DynamicUser=yes в своем файле .service, а владение каталогом фактически используется в качестве основы для UID учетной записи службы.

Связанный контент