Failed to start network name resolution ubuntu причины
Обновлено: 06.07.2024
Я следую учебнику по докеру и нахожусь на той части, где у меня есть собрать приложение, используя:
Доходит до шага 4, где после паузы я получаю эту ошибку:
Я не совсем уверен, что означает эта ошибка и как я могу ее решить.
Спасибо за вашу помощь!
Этот пост работал и для меня!
У меня возникла та же проблема с Ubuntu 16.04 и версией Docker 17.09.0-ce. Я не думаю, что отключение маски DNS является правильным решением.
Вот как я это решил:
Для Ubuntu
Отредактируйте /etc /default /docker и добавьте свой DNS-сервер в следующую строку:
Пример DOCKER_OPTS="--dns 8.8.8.8 --dns 10.252.252.252"
У меня та же проблема с машиной Ubuntu 16.04.1 для docker-ce 17. Это было исправлено отключением маски DNS в сети.
Нажмите Ctrl + O и нажмите Enter , чтобы выйти Ctrl + X
Перезапустите сетевую службу, выполнив приведенную ниже команду.
После этого, если вы запустите команду docker build, все будет работать нормально.
Эта ошибка означает, что ваш Docker-контейнер не может получить доступ к вашей сети. Начиная с версии 220 systemd, настройка пересылки для данной сети (net.ipv4.conf..forwarding) по умолчанию отключена. Этот параметр запрещает пересылку IP. Это также противоречит поведению Docker по включению настройки net.ipv4.conf.all.forwarding в контейнерах.
Если вашему контейнеру необходимо разрешить хосты, которые являются внутренними для вашей сети, общедоступных серверов имен будет недостаточно. У вас есть два варианта:
- Вы можете указать DNS-сервер, который будет использовать Docker, или
- Вы можете отключить dnsmasq в NetworkManager. Если вы сделаете это, NetworkManager добавит ваш истинный DNS-сервер имен в /etc/resolv.conf, но вы потеряете возможные преимущества dnsmasq. Вам нужно использовать только один из этих методов.
вы можете прочитать о том, как выполнить эти шаги здесь
Ответ bkasap меняет функциональность системы, я бы сказал, преувеличена. Далее, потому что в Docker есть варианты сделать это. Новый способ сделать это -
Собрал генту, загрузился, нет инета, в liveCD был. ifconfig выдает только lo. ifconfig -a выдает bond0, enp0s31f6, lo. Все они выдавались в liveCD, когда писал просто ifconfig, а тут нет. Ядро компилировал через genkernel. lspci -k и в установленной системе, и в liveCD одинаковые. Что сделать чтобы все заработало?
как сеть настраивал?
ifconfig -a покажи
Что-то не то с неймсерверами. Посмотри /etc/resolv.conf
Выше сказали про /etc/resolv.conf
Он у тебя пустой скорее всего. Пинги ходят по сети?
этот файл пустой, хз что писать туда
Там по-моему надо настроить параметры в /etc/conf.d/net и создать в /etc/init.d/ рядом симлинк на net по примеру net.lo. Там net.enp0s31f6 или типа того. Хотя по dhcp сеть должна цепляться и так.
См кстати bzcat /usr/share/doc/netifrc*/README*
А симлинк /etc/init.d/net.enp0s31f6 и в уровень загрузки ?
В идеале в /etc/resolv.conf должны быть DNS-сервера твоего провайдера. Но для теста(если интернет у тебя прямой, а не через прокси) может прописать туда например DNS-сервера гугла.
Стоит, ещё раз попробовал, написал rc-update: net.enp0s31f6 already installed in runlevel 'default'; skipping
Там nameserver 192.168.1.1 стояло, заменил, перезагрузился, не помогло
Ну и как выше подсказали - убедись что init-скрипт твоего сетевого интерфейса добавлен в автозапуск и реально запущен
Update: судя по ошибке выше - в автозапуск он добавлен. Тогда ждем еще выхлоп
в довесок к предыдущим командам
Pinkbyte ★★★★★ ( 29.04.19 21:46:49 )Последнее исправление: Pinkbyte 29.04.19 21:49:17 (всего исправлений: 3)
Выхлоп ip link дай. Пока что кажется сеть у тебя просто выключена
А вы сам-то dhcp клиент собрали?
По умолчанию его нет.
По умолчанию в Gentoo уже довольно давно используется dhcp-клиент из состава busybox(если других dhcp-клиентов не установлено). Который в свою очередь является часть @system - то есть есть всегда.
Но да, согласен, я еще помню те времена, когда это было не так.
Pinkbyte ★★★★★ ( 29.04.19 21:50:57 )Последнее исправление: Pinkbyte 29.04.19 21:51:54 (всего исправлений: 2)
Rc-status пишет " Runlevel:sysinit [ok], sysfs пустой, а devfs, udev, cgroups, kmod-static-nodes, dmesg, opentmpfiles-dev, dmesg, udev-trigger все [stopped], Dynamic Runlevel: hotplugged, Dynamic Runlevel: needed/wanted, Dynamic Runlevel: manual тоже [stopped]
Так это уже с загруженной системы ты пишешь? Или из chroot? Похоже на выхлоп из chroot, когда openrc не запущен.
Если из загруженной системы - значит она загрузилась не до конца. Врубай отладку в /etc/rc.conf и смотри логи.
В системе уже, как отладку врубить хз
Открывай /etc/rc.conf, читай описание настройки rc_logger, включай ее, перегружайся, смотри в лог
Pinkbyte ★★★★★ ( 29.04.19 21:59:22 )Важно При поиске неисправностей сети взгляните на /var/log/rc.log. В данном лог файле можно найти информацию об активности при загрузке системы, если только переменная rc_logger не установлена в значение NO в файле /etc/rc.conf.
Последнее исправление: Pinkbyte 29.04.19 22:00:17 (всего исправлений: 2)
Честно говоря я уже давно Gentoo не ставил, но помнится раньше мне всегодя приходилось ставить dhcp клиент.
И всё же я бы посоветовал ТС собрать клиент, ибо если у него система видит интерфейс и в conf.d всё правильно и сделана символьная ссылка, то всё должно работать.
Он может либо руками вызвать dhcp клиент из состава busybox, либо руками назначить правильные параметры сети, уже IP адрес-то шлюза и адресное пространство своей сети он должен знать, после чего пинговать шлюз.
ТС, вызов busybox без параметров:
и найди там аплет со словом dhcp в составе имени, возможно что-то вроде udhcp. И далее выполни:помнится раньше мне всегодя приходилось ставить dhcp клиент.
Да, изменение это где-то году в 2013 сделали, но учитывая что в busybox достаточно простенький dhcp-клиент, я по привычке везде где мне нужен DHCP ставлю dhcpcd или dhclient.
А у ТСа там судя по всему даже до сети дело не доходит, если всё застревает на sysinit runlevel - чинить надо это в первую очередь ИМХО.
К слову, а покажи-ка еще /proc/cmdline, может ты систему грузишь с опцией init=/bin/sh, а мы тут голову ломаем :-)
Через вим открыл, BOOT_IMAGE=/kernel-genkernel-x86_64-4.19.27-gentoo-r1 root=UUID=переписыватьлень ro
Эта опция здесь зачем? Ты понимаешь что она делает и как может повлиять на загрузку(подсказка: может вызвать такие симптомы как у тебя)?
initrd имеется? Что в /etc/fstab? Если там не правильно указан корень - никто не перемонтирует его на запись, соответственно никто не сможет ничего записать, в том числе и логи
Pinkbyte ★★★★★ ( 29.04.19 22:09:20 )Последнее исправление: Pinkbyte 29.04.19 22:12:40 (всего исправлений: 3)
Read only, знаю, но я там не трогал ничего, она сама там появилась, причем, кстати, я в fstab опечатался пару часов назад, вся система в readonly была, поменял везде uuid на partuuid В /proc/cmdline не заходил ниразу, в нем есть смысл uuid на partuuid заменить? ro уберу
Например, когда вы пытаетесь проверить связь с веб-сайтом , вы можете столкнуться с показанной ошибкой:
Обычно это ошибка разрешения имен, которая показывает, что ваш DNS- сервер не может преобразовать доменные имена в соответствующие IP-адреса. Это может стать серьезной проблемой, поскольку вы не сможете обновлять, обновлять или даже устанавливать какие-либо программные пакеты в вашей системе Linux.
В этой статье мы рассмотрим некоторые причины ошибки « Temporary failure in name resolution» и решения этой проблемы.
такие же пролблемы возникают если попытаться обновить или установить чтото
Пути решения проблемы
1. Отсутствующий или неправильно настроенный файл resolv.conf
Этот /etc/resolv.conf файл является файлом конфигурации преобразователя в системах Linux. Он содержит записи DNS, которые помогают вашей системе Linux преобразовывать доменные имена в IP-адреса.
Если этот файл отсутствует или существует, но ошибка разрешения имени все еще возникает, создайте его и добавьте общедоступный DNS-сервер Google, как показано
Сохраните изменения и перезапустите службу systemd-resolved, как показано.
Также разумно проверить состояние резолвера и убедиться, что он активен и работает должным образом:
Затем попробуйте проверить связь с любым веб-сайтом, и проблема должна быть решена.
Однако в убунту 20 этот файл скоррее всего перезатрется и ДНС будует 127.0.0.53
2. Ограничения брандмауэра
Если первое решение не помогло вам, ограничения брандмауэра могут мешать вам успешно выполнять DNS-запросы. Проверьте свой брандмауэр и убедитесь, что порт 53 (используется для DNS - разрешение доменного имени) и порт 43 (используется для поиска whois ) открыты. Если порты заблокированы, откройте их следующим образом:
Для брандмауэра UFW (Ubuntu / Debian и Mint)
Чтобы открыть порты 53 и 43 на брандмауэре UFW, выполните следующие команды:
Для firewalld (RHEL / CentOS / Fedora)
Для систем на основе Redhat, таких как CentOS, выполните следующие команды:
3 Особенности настрокий ДНС в убунту 20
/etc/resolv.conf основной файл конфигурации для DNS имя распознавателя библиотеки. Сопоставитель - это набор функций в библиотеке C, которые обеспечивают доступ к системе доменных имен Интернета ( DNS ). Функции настроены для проверки записей в файле /etc/hosts или нескольких DNS-серверов имен, или для использования базы данных хоста сетевой информационной службы ( NIS ).
В современных системах Linux, использующих systemd (менеджер системы и служб), службы DNS или разрешения имен предоставляются локальным приложениям через службу с разрешением systemd . По умолчанию эта служба имеет четыре различных режима для обработки разрешения доменных имен и использует файл-заглушку systemd DNS ( /run/systemd/resolve/stub-resolv.conf ) в режиме работы по умолчанию.
Файл-заглушка DNS содержит локальную заглушку 127.0.0.53 в качестве единственного DNS-сервера и перенаправляется в файл /etc/resolv.conf, который использовался для добавления серверов имен, используемых системой.
Если вы запустите следующую команду ls в /etc/resolv.conf , вы увидите, что этот файл является символической ссылкой на файл /run/systemd/resolve/stub-resolv.conf .
К сожалению, поскольку /etc/resolv.conf косвенно управляется службой systemd-resolved , а в некоторых случаях сетевой службой (с помощью сценариев инициализации или NetworkManager ), любые изменения, сделанные пользователем вручную, не могут быть сохранены навсегда или только длиться какое-то время.
В этой статье мы покажем, как установить и использовать программу resolvconf для установки постоянных серверов имен DNS в файле /etc/resolv.conf в дистрибутивах Debian и Ubuntu Linux.
Зачем вам редактировать файл /etc/resolv.conf?
Основная причина может заключаться в том, что системные настройки DNS неправильно настроены или вы предпочитаете использовать определенные серверы имен или свои собственные. Следующая команда cat показывает сервер имен по умолчанию в файле /etc/resolv.conf в моей системе Ubuntu.
В этом случае, когда локальные приложения, такие как диспетчер пакетов APT, пытаются получить доступ к полным доменным именам ( полные доменные имена ) в локальной сети, результатом является ошибка « Temporary failure in name resolution », как показано на следующем снимке экрана.
Устранение временных сбоев
То же самое происходит, когда вы запускаете команду ping .
Поэтому, когда пользователь пытается вручную настроить серверы имен, изменения сохраняются недолго или отменяются после перезагрузки. Чтобы решить эту проблему, вы можете установить и использовать утилиту reolvconf, чтобы сделать изменения постоянными.
Чтобы установить пакет resolvconf , как показано в следующем разделе, вам нужно сначала вручную установить следующие серверы имен в файле /etc/resolv.conf , чтобы вы могли получить доступ к FQDM серверов репозитория Ubuntu в Интернете.
Установка resolvconf в Ubuntu и Debian
Сначала обновите пакеты системного программного обеспечения, а затем установите resolvconf из официальных репозиториев, выполнив следующие команды.
После завершения установки resolvconf systemd инициирует автоматический запуск и включение службы resolvconf.service . Чтобы проверить, работает ли он, выполните следующую команду.
Если служба не запускается и не включается автоматически по какой-либо причине, вы можете запустить и включить ее следующим образом.
Проверить статус службы Resolvconf
Установите постоянные DNS-серверы имен в Ubuntu и Debian
Затем откройте файл конфигурации /etc/resolvconf/resolv.conf.d/head .
и добавьте в него следующие строки:
Установите постоянные серверы имен DNS в Resolvconf
Сохраните изменения и перезапустите службу resolvconf. или перезагрузите систему.
Теперь, когда вы проверяете файл /etc/resolv.conf , записи сервера имен должны храниться там постоянно. Отныне вы не столкнетесь с какими-либо проблемами, связанными с разрешением имен в вашей системе.
Я надеюсь, что эта краткая статья помогла вам настроить постоянные DNS-серверы имен в ваших системах Ubuntu и Debian. Если у вас есть какие-либо вопросы или предложения, поделитесь ими с нами в разделе комментариев ниже.
См. также
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Network Manager - удобная утилита для управления сетевыми подключениями в Linux, используется по умолчанию во всех основных графических оболочках, что предоставляет пользователю простой и единообразный интерфейс настройки сети. Также Network Manager поддерживает Wi-Fi, 3G и VPN подключения, позволяя легко создавать их в графическом режиме. Но бывают ситуации, когда Network Manager неожиданно ломается, оставляя непривычного к консоли пользователя буквально без связи с внешним миром. В данной статье мы рассмотрим некоторые типовые проблемы, которые достаточно легко устраняются, но при этом могут серьезно испортить жизнь начинающим.
Network Manager - устройство не управляется
Достаточно простая неисправность, точнее даже не неисправность, которая проявляется в том, что Network Manager не может управлять вашим сетевым устройством.
Причина такого поведения лежит в том, что Network Manager не является единственным способом управления сетевыми подключениями в Linux и если он видит, что сетевой адаптер был настроен другим методом, то перестает управлять им. Это вполне корректное поведение, предоставляющее администратору всю полноту власти над системой и обеспечивающее приоритет ручных настроек над автоматическими.
Удалим из этого файла все строки кроме:
На скриншоте выше как раз видны ручные настройки для сетевого адаптера ens33, которые и блокировали работу Network Manager с этим интерфейсом.
После чего перезапустим службу командой:
После чего Network Manager снова возьмет контроль над сетевым интерфейсом.
Для недопущения подобной ситуации в дальнейшем следует внимательно относиться к ручным настройкам сети и не допускать подобных изменений, если вы желаете и далее использовать Network Manager.
Network Manager не видит сеть
Более сложная неисправность, которая заключается в том, что Network Manager вообще не видит сетевых адаптеров, причины ее возникновения нам неизвестны, но приходилось достаточно часто сталкиваться с ней на промежуточных выпусках Ubuntu.
Кстати, данная неисправность может послужить причиной ручной настройки сетевого интерфейса, которое в последствии будет блокировать работу Network Manager, но ее также несложно вылечить, для этого нужно создать пустой файл:
И перезапустить службу:
Для дальнейшей работы Network Manager наличие данного файла необязательно, т.е. вы можете его удалить, но Network Manager продолжит работать нормально.
Как видим, предложенные нами способы восстановления здоровья Network Manager просты и, надеемся, помогут вам сэкономить время и нервы, когда вы столкнетесь с подобной проблемой.
Читайте также: