ping отображает имя или службу неизвестно
Сохраните резервную копию всех файлов конфигурации grub.
Есть два метода, которые я использовал в прошлом:
1) Установите ntfs-3g (который должен позволить вашей установке автоматически видеть раздел windows) с помощью менеджера пакетов. Для меня он был доступен в репозитории EPEL, но вам придется найти другой репозиторий для него на Arch.
Затем sudo grub2-mkconfig. Это сработало для меня, когда я пытался заставить мой centos7 dual boot работать с windows.
2) В качестве альтернативы лучше всего добавить пользовательскую запись, добавив файл в /etc/grub.d/
Например, на моей текущей системе с двойной загрузкой Centos7 + Windows 10:
$ sudo cat /etc/grub.d/40_custom
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry "Windows 10" {
set root='(hd0,1)'
chainloader +1
}
Где параметр menuentry - это имя, которое будет отображаться в меню grub. (hd0,1) будет меняться в зависимости от того, на каком жестком диске и на каком разделе у вас установлена windows.
Хотя у меня никогда не было проблем с другими моими x86 _64 ПК, работающими под управлением Arch Linux, до сих пор это часто происходит с Arch Linux ARM при запуске NetworkManager.
Проблема в том, что вы подключены к Wi-Fi, но не можете проверить связь или использовать Интернет, но вы можете получить доступ ко всем компьютерам в локальной сети и даже использовать программное обеспечение для удаленного доступа к рабочему столу.
Существует высокая вероятность того, что что-то пошло не так, когда ваш ping или ваш браузер пытается разрешить хост. Я могу придумать 3 решения:
Решение 1
Я считаю, что это проблема тысяч систем Raspberry Pi, работающих под управлением Archlinux ARM и использующих NetworkManger.
В моем случае /etc/resolv.conf был неработающей символической ссылкой на ../run/systemd/resolve/stub-resolv.conf.
NetworkManager не может заполнить символическую ссылку, а файл /etc/resolv.conf пуст. Мы должны:
- Удалить неработающую символическую ссылку:
# rm /etc/resolv.conf
- Создайте файл
/etc/NetworkManager/conf.d/dns.confс содержимым:
[main]
dns=none
main.systemd-resolved=false
- Перезапустите NetworkManager:
sudo systemctl restart NetworkManager
Это должно решить проблему, если не следовать Решению 2.
Решение 2
Если описанное выше не помогло вам решить проблему, вы можете временно заполнить файл /etc/resolv.conf:
sudo systemctl restart systemd-resolved && sudo systemctl stop systemd-resolved
Причина, по которой это работает, заключается в том, что, возможно, что-то не так с файлом /etc/resolv.conf. Приведенная выше команда должна перезаписать содержимое, но опять же, вы должны посмотреть, что вызывает проблему.
Решение 3
Если вы не можете вернуть свой /etc/resolv.conf,просто создайте новый/etc/resolv.conf(удалите, если существует пустой старый или символическая ссылка )и вставьте код:
search domain.name
nameserver 8.8.8.8
nameserver 1.1.1.1
nameserver 1.0.0.1
Обратите внимание, что в первой строке вы также можете использовать IP-адрес вашего маршрутизатора, например(nameserver 192.168.43.1в моем случае ), что сделает доступными для проверки связи другие системы в той же сети. Не очень хорошая идея генерировать resolv таким образом, но у меня были плохие времена с автоматически сгенерированным NetworkManager -resolv. Systemd -resolvd также генерирует неправильные файлы даже на моем ПК.
Немного странно, здесь я использую основной DNS Google и основной DNS Cloudflare, вы можете использовать 8.8.8.8 с 8.8.4.4 или 1.1.1.1 с 1.0.0.1.
Хотя этот шаг работает, вы можете запретить NetworkManager перезаписывать файл при его перезапуске:
Добавить эту запись в/etc/NetworkManager/NetworkManager.conf
[main]
dns=none
systemd-resolved=false
Они работали для моих установок на Raspberry Pi 3 модели B. Надеюсь, это сработает и для вас.
У меня только что была проблема с такими же эффектами. Проверьте, правильно ли установлено время. DNSSEC, по-видимому, включен по умолчанию и блокирует запросы из-за «просроченных» сертификатов.
Некоторые другие проблемы, связанные с этим, можно диагностировать с помощью journalctl -u systemd-resolved -b -0.
У меня была эта проблема на Raspberry Pi 4 под управлением Arch Linux.
Симптомы заключались в том, что не было DNS, что приводило к сообщению об ошибке ping.
Я заметил, позвонив date, что время сильно отставало, около двух дней назад.
Я убедился, что синхронизация времени была включена с systemctl status systemd-timesyncd, но из вывода timedatectl timesync-statusзаметил, что у службы нет IP-адреса для NTP-сервера (, он сказал Server: Null).
Воспользовавшись подсказкой jaku255 по проверке journalctl -u systemd-resolved -b -0, я увидел, что синхронизация времени не работает из-за сбоя DNS:
DNSSEC validation failed for question ntp.org IN DS: signature-expired
Это что-то вроде тупиковой ситуации. :DNS не работает, потому что время неправильное, а время неправильное, потому что DNS не работает.
При попытке установить время вручную выдал
timedatectl set-time "2020-02-29 10:51:55"
, но это привело к ошибке:
Failed to set time: Automatic time synchronization is enabled
Чтобы исправить это, я временно (хе-хе^^ )отключил синхронизацию времени с
timedatectl set-ntp 0
и снова позвонил timedatectl set-time, на этот раз успешно.
После этого я повторно активировал синхронизацию времени с timedatectl set-ntp 1и с помощью timedatectl timesync-statusубедился, что синхронизация теперь работает:
Server: 212.69.166.153 (0.arch.pool.ntp.org)
Кроме того, pingи curlтеперь нормально работают с DNS.
Хотел добавить еще одно в список решений Госвами.
Я сталкиваюсь с той же проблемой куриного -и -яйца между DNSSEC и NTP на моих крошечных портативных серверах под управлением Debian 10. Иногда они остаются обесточенными в течение довольно долгого времени и буквально теряют чувство времени, в то время как мир меняется вокруг. их, поэтому я не мог просто создать статическую горячую -конфигурацию исправления (с ). В то же время, они должны самостоятельно подключаться к сети при питании, так как у меня нет к ним физического доступа. Я решил вырваться из петли, сначала исправив время, и пока этот метод кажется достаточно надежным.
Решение 4
Получить список надежных IP-адресов надежных и надежных NTP-серверов. Давайте воспользуемся этим, например:https://tf.nist.gov/tf-cgi/servers.cgi. Вот несколько образцов оттуда:
time-a-g.nist.gov 129.6.15.28
time-b-g.nist.gov 129.6.15.29
time-c-g.nist.gov 129.6.15.30
...
time-a-wwv.nist.gov 132.163.97.1
time-b-wwv.nist.gov 132.163.97.2
time-c-wwv.nist.gov 132.163.97.3
time-d-wwv.nist.gov 132.163.97.4
...
Поскольку я использую chronydдля синхронизации времени, я просто добавил эти IP-адреса в его конфигурацию:(ПРИМЕЧАНИЕ :, которая также работает для конфигурации ntpd, обычно находится по адресу/etc/ntp.conf)
nano /etc/chrony/chrony.conf
добавлены строки:
...
pool time.nist.gov
server 132.163.97.1
server 132.163.97.2
server 132.163.97.3
server 132.163.97.4
...
Теперь хрони проходит по всем указанным адресам, пока не сможет подключиться и получить время. И с этого момента все остальное начинает работать правильно.
На моем мэйнфрейме есть скрипт, который периодически проверяет, активны ли все IP-адреса в списке, и уведомляет, если какой-либо из них отключается, чтобы я мог при необходимости обновлять удаленные конфигурации,в то время как серверы находятся в сети, и срок действия не всех серверов NTP истек.
Вероятно, лучше всего иметь резервные -конфигурации для обоих концов, DNS и NTP.