Здравствуйте.
При установке пакета из AUR столкнулся вот с этим:
:: Ключи PGP, требующие импорта:
-> 471B9FD45517A5ED101FC57DA72832072D525E41, требуется пакету:
:: Импортирование ключей с помощью gpg…
gpg: сбой при получении с сервера ключей: Нет данных
проблема импортирования ключей
Проделал такие действия:
# pacman-key —init
# pacman-key —populate archlinux
# pacman-key —populate manjaro
# pacman-key —refresh-keys
# gpg —search-keys 471B9FD45517A5ED101FC57DA72832072D525E41
gpg: data source: hkps.pool.sks-keyservers.net:443
gpg: ключ «471B9FD45517A5ED101FC57DA72832072D525E41» на сервере ключей не найден
gpg: сбой при поиске на сервере ключей: Не найдено
# gpg —recv-keys 471B9FD45517A5ED101FC57DA72832072D525E41
gpg: сбой при получении с сервера ключей: Нет данных
Как с этим справиться?
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.
|
# (отредактировано 6 лет, 1 месяц назад) |
|
|
Темы: 3 Сообщения: 81 Участник с: 16 июня 2016 |
Проблема такая: Я не могу импортировать любой ключ из сети.
gpg —keyserver pgp.mit.edu —recv-keys B4322F04D67658D8 Пробовал другой сервер и удалять директорию ключей (он создавал новую базу и результат тотже. Чего ему не хватает? |
|
redix |
# |
|
Темы: 34 Сообщения: 3432 Участник с: 11 марта 2013 |
Сначала выполните эти команды, потом попробуйте импортировать. In Tux We Trust |
|
Ulin |
# |
|
Темы: 3 Сообщения: 81 Участник с: 16 июня 2016 |
pacman-key —refresh-keys gpg: обновление 91 ключа из hkp://pool.sks-keyservers.net gpg: сбой при обновлении с сервера ключей: Нет такого файла или каталога ==> ОШИБКА: Не удалось обновить указанный локальный ключ с сервера ключей. |
|
redix |
# |
|
Темы: 34 Сообщения: 3432 Участник с: 11 марта 2013 |
Выполните еще это:
In Tux We Trust |
|
Ulin |
# |
|
Темы: 3 Сообщения: 81 Участник с: 16 июня 2016 |
Интересно. dirmngr[14818]: ошибка открытия ‘/home/denis/.gnupg/dirmngr_ldapservers.conf’: Нет такого файла или каталога dirmngr[14818.0]: постоянно загруженных сертификатов: 161 dirmngr[14818.0]: сертификатов в буфере времени исполнения: 0 dirmngr[14818.0]: достоверных сертификатов: 161 (160,0,0,1) # Home: /home/denis/.gnupg # Config: /home/denis/.gnupg/dirmngr.conf OK Dirmngr 2.1.20 at your service |
|
Ulin |
# |
|
Темы: 3 Сообщения: 81 Участник с: 16 июня 2016 |
От рута (не заметил значка) dirmngr[15408]: ошибка открытия ‘/root/.gnupg/dirmngr_ldapservers.conf’: Нет такого файла или каталога dirmngr[15408.0]: постоянно загруженных сертификатов: 161 dirmngr[15408.0]: сертификатов в буфере времени исполнения: 0 dirmngr[15408.0]: достоверных сертификатов: 161 (160,0,0,1) dirmngr[15408.0]: не могу открыть файл буферного каталога ‘/root/.gnupg/crls.d/DIR.txt’: Нет такого файла или каталога dirmngr[15408.0]: создание каталога ‘/root/.gnupg/crls.d’ dirmngr[15408.0]: создан новый файл буферного каталога ‘/root/.gnupg/crls.d/DIR.txt’ # Home: /root/.gnupg # Config: /root/.gnupg/dirmngr.conf OK Dirmngr 2.1.20 at your service |
|
Ulin |
# |
|
Темы: 3 Сообщения: 81 Участник с: 16 июня 2016 |
touch /home/denis/.gnupg/dirmngr_ldapservers.conf touch /root/.gnupg/dirmngr_ldapservers.conf Проблему не решил. dirmngr < /dev/null sudo pacman-key —refresh-keys |
|
redix |
# |
|
Темы: 34 Сообщения: 3432 Участник с: 11 марта 2013 |
Если у вас установлена манжара, делайте так:
In Tux We Trust |
|
Ulin |
# |
|
Темы: 3 Сообщения: 81 Участник с: 16 июня 2016 |
Archlinux |
|
redix |
# |
|
Темы: 34 Сообщения: 3432 Участник с: 11 марта 2013 |
pacman/Package signing (Русский)
In Tux We Trust |
Как правильно задавать вопросы
Правильно сформулированный вопрос и его грамотное оформление способствует высокой вероятности получения достаточно содержательного и по существу ответа. Общая рекомендация по составлению тем: 1. Для начала воспользуйтесь поиском форума. 2. Укажите версию ОС вместе с разрядностью. Пример: LM 19.3 x64, LM Sarah x32 3. DE. Если вопрос касается двух, то через запятую. (xfce, KDE, cinnamon, mate) 4. Какое железо. (достаточно вывод inxi -Fxz в спойлере (как пользоваться спойлером смотрим здесь)) или же дать ссылку на hw-probe 5. Суть. Желательно с выводом консоли, логами. 6. Скрин. Просьба указывать 2, 3 и 4 независимо от того, имеет ли это отношение к вопросу или нет. Так же не забываем об общих правилах Как пример вот
-
ELForcer
- Сообщения: 15
- Зарегистрирован: 19 июл 2018, 11:07
- Благодарил (а): 4 раза
- Контактная информация:
gpg: сбой при получении с сервера ключей: Недопустимый аргумент
13 фев 2020, 00:42
В последнее время возникли проблемы со сторонними репозиториями. Они перестали обновляться и добавляться.
sudo add-apt-repository ppa:pypy/ppa
Вы хотите добавить следующие PPA:
The latest release of PyPy packaged for stable Ubuntu releases.
This PPA also contains builds of CFFI for cPython — python-cffi.
Больше информации:
https://launchpad.net/~pypy/+archive/ubuntu/ppa
Нажмите Enter, чтобы продолжить или Ctrl+C для отмены
Executing: /tmp/apt-key-gpghome.N2GsRxqPIP/gpg.1.sh —keyserver hkps://keyserver.ubuntu.com:443 —recv-keys 2862D0785AFACD8C65B23DB0251104D968854915
gpg: сбой при получении с сервера ключей: Недопустимый аргумент
Пробовал переустановить pgp и ubuntu-keyring , без толку. Как временное решение, это искать ключи непосредственно на сервере через браузер, и скачивать их вручную оттуда и вручную импортировать. Но хотелось бы найти нормальное решение.
Текущая ОС:
System: Kernel: 5.3.0-28-generic x86_64 bits: 64 compiler: gcc v: 7.4.0
Desktop: Cinnamon 4.4.8 wm: muffin dm: LightDM Distro: Linux Mint 19.3 Tricia
base: Ubuntu 18.04 bionic
-
Сотрудник
- Сообщения: 285
- Зарегистрирован: 22 янв 2020, 09:04
- Решено: 2
- Благодарил (а): 5 раз
- Поблагодарили: 79 раз
- Контактная информация:
gpg: сбой при получении с сервера ключей: Недопустимый аргумент
#2
13 фев 2020, 04:48
ELForcer, откройте «Центр управления» — «Источники приложений». Здесь можно исправить проблемы с ключами и репозиториями, только не меняйте «оффициальные репозитории»
-
ELForcer
- Сообщения: 15
- Зарегистрирован: 19 июл 2018, 11:07
- Благодарил (а): 4 раза
- Контактная информация:
gpg: сбой при получении с сервера ключей: Недопустимый аргумент
#3
13 фев 2020, 16:18
Сотрудник писал(а): ↑
13 фев 2020, 04:48
— «Источники приложений».
Так первый скрин оттуда. Это не помогает.
-
symon2014
- Сообщения: 5378
- Зарегистрирован: 16 дек 2017, 21:59
- Решено: 31
- Откуда: Феодосия
- Благодарил (а): 32 раза
- Поблагодарили: 662 раза
- Контактная информация:
gpg: сбой при получении с сервера ключей: Недопустимый аргумент
#4
13 фев 2020, 16:24
ELForcer, apt update , и полный вывод сюда под спойлер.
Добрый день!
Не получается подключить репозиторий Debian 9. Нужна последняя версия Гимпа.
Действовал по инструкции находящейся в Справочном центре Astra Linux.
Подключение репозиториев с пакетами в ОС Astra Linux и установка пакетов
пакет debian-archive-keyring установить не удается.
После команды:
wget https://dl.astralinux.ru/astra/test…ol/main/d/debian-archive-keyring/debian-archi
ve-keyring_2021.1.1_all.deb
пишет:
—2021-11-16 20:50:32— https://dl.astralinux.ru/astra/test…ain/d/debian-archive-keyring/debian-archive-k
eyring_2021.1.1_all.deb
Распознаётся dl.astralinux.ru (dl.astralinux.ru)… 141.105.66.226
Подключение к dl.astralinux.ru (dl.astralinux.ru)|141.105.66.226|:443… соединение установлено.
HTTP-запрос отправлен. Ожидание ответа… 404 Not Found
2021-11-16 20:50:32 ОШИБКА 404: Not Found.
После команды:
sudo apt install ./debian-archive-keyring_2021.1.1_all.deb
пишет:
sudo: unable to resolve host localhost.localdomain
Чтение списков пакетов… Готово
E: В командной строке указан не поддерживаемый файл
После команды:
sudo apt-key adv —recv-keys —keyserver keys.gnupg.net EF0F382A1A7B6500
пишет:
sudo: unable to resolve host localhost.localdomain
Executing: /tmp/apt-key-gpghome.C3c80CXSVf/gpg.1.sh —recv-keys —keyserver keys.gnupg.net EF0F382A1A7B6500
gpg: сбой при получении с сервера ключей: No name
Последняя рекомендация — Временно изменить настройки DNS.
Но как это делать — не знаю. Прошу, подскажите, как действовать?
Добрый день!
Не получается подключить репозиторий Debian 9. Нужна последняя версия Гимпа.
Действовал по инструкции находящейся в Справочном центре Astra Linux.
Подключение репозиториев с пакетами в ОС Astra Linux и установка пакетов
пакет debian-archive-keyring установить не удается.
После команды:
wget https://dl.astralinux.ru/astra/test…ol/main/d/debian-archive-keyring/debian-archi
ve-keyring_2021.1.1_all.deb
пишет:
—2021-11-16 20:50:32— https://dl.astralinux.ru/astra/test…ain/d/debian-archive-keyring/debian-archive-k
eyring_2021.1.1_all.deb
Распознаётся dl.astralinux.ru (dl.astralinux.ru)… 141.105.66.226
Подключение к dl.astralinux.ru (dl.astralinux.ru)|141.105.66.226|:443… соединение установлено.
HTTP-запрос отправлен. Ожидание ответа… 404 Not Found
2021-11-16 20:50:32 ОШИБКА 404: Not Found.
После команды:
sudo apt install ./debian-archive-keyring_2021.1.1_all.deb
пишет:
sudo: unable to resolve host localhost.localdomain
Чтение списков пакетов… Готово
E: В командной строке указан не поддерживаемый файл
После команды:
sudo apt-key adv —recv-keys —keyserver keys.gnupg.net EF0F382A1A7B6500
пишет:
sudo: unable to resolve host localhost.localdomain
Executing: /tmp/apt-key-gpghome.C3c80CXSVf/gpg.1.sh —recv-keys —keyserver keys.gnupg.net EF0F382A1A7B6500
gpg: сбой при получении с сервера ключей: No name
Последняя рекомендация — Временно изменить настройки DNS.
Но как это делать — не знаю. Прошу, подскажите, как действовать?
в сетевом соединении на вкладке ipv4 укажите dns гугла 8.8.8.8 или яндекса 77.88.8.8 (как вам удобно), потом перезапустите подключение
*в сторону*
Для начала стоит почитать выхлоп первой команды, подумать над выражением «404 Not Found» и не вводить остальные, пока эта проблема (отсутствие источника по причине явно некорректно скопированного адреса) не будет решена…
А лучше почитать про пакет debian-keyring и про понятие ключей репозитория (для общего развития, ага). Или хотя бы в той же инструкции найти пример подключения репозитория Debian 9 без keyring, но через trusted=yes…
пакет debian-archive-keyring установить не удается.
Так он же в Синаптике есть, чего мудрить-то? Я, помнится, оттуда и установил.
Так он же в Синаптике есть, чего мудрить-то? Я, помнится, оттуда и установил.
Спаси Бог, за отклик! Увидел, обрадовался, нашел в Синаптике debian-archive-keyring, стал устанавливать, и вот что в итоге:
W: Download is performed unsandboxed as root as file ‘/root/.synaptic/tmp//tmp_sh’ couldn’t be accessed by user ‘_apt’. — pkgAcquire::Run (13: Отказано в доступе)
Вот перевод (яндекс-переводчик):
W: Загрузка выполняется в незашифрованном виде как корневой файл, так как файл «/root/.synaptic/tmp//tmp_sh» не может быть доступен пользователю «_apt». — pkg Получить::Выполнить (13: Отказано в доступе)
Не знаю, что с этим делать.
Но, несмотря на это теперь в Синаптике дело обстоит так:
Означает ли это, что debian-archive-keyring все таки установился?
Последнее редактирование: 17.11.2021
Перезагрузил компьютер, попробовал обновить Синаптик. Вот такой результат:
Может быт, лучше провести всю процедуру заново?
Удалить Дебиановский репозиторий и потом снова подключить?
Если так, то как поступать с debian-archive-keyring? Тоже удалить и потом заново установить?
Гимп 2.10 так в Синаптике и не появился.
Перезагрузил компьютер, попробовал обновить Синаптик. Вот такой результат:
Что-то непонятное у вас происходит. Синаптик же с повышением прав запускается, требует пароль. Или у вас не требует?
Перезагрузил компьютер, попробовал обновить Синаптик. Вот такой результат:
Посмотреть вложение 1833
Может быт, лучше провести всю процедуру заново?
Удалить Дебиановский репозиторий и потом снова подключить?
Если так, то как поступать с debian-archive-keyring? Тоже удалить и потом заново установить?
Гимп 2.10 так в Синаптике и не появился.
Похожая проблема у меня была здесь. Как то она разрешилась. Нужно пожалуй посмотреть дату и время в системном трее и если они отличаются от текущй то исправить их. Мне например часто приходиться это делать вручную, потому что не знаю как синхронизировать их постоянно. Кроме того ссылка команды wget у Вас выдает ошибку как будто она битая. Впрочем, как уже было сказанно, лучше устанавливать в таком случае из Синаптика.
Последнее редактирование: 17.11.2021
В общем, как никогда ясно, что первая программа, которую нужно установить в системе — это Timeshift. И тут же сделать снимок системы. А потом уже мудрить с репозиториями и прочей фигнёй. А то зайдёшь не пойми куда и не знаешь, как выйти.
В общем, как никогда ясно, что первая программа, которую нужно установить в системе — это Timeshift. И тут же сделать снимок системы. А потом уже мудрить с репозиториями и прочей фигнёй. А то зайдёшь не пойми куда и не знаешь, как выйти.
Вам удавалось поставить ее на Астру Орла? Если не трудно то опишите процесс установки. Я вчера покопался но так еще и не понял. Я правда начинающий, поэтому очень быстро путаюсь когда приходиться что то такое делать. К тому же в интернете тоже многое пишут на слэнге и поди разбери.
Вам удавалось поставить ее на Астру Орла? Если не трудно то опишите процесс установки.
Так я же в другой теме вам ответил: скачайте не последнюю, а предпоследнюю версию, в виде deb-файла. https://github.com/teejee2008/timeshift/releases/download/v20.11.1/timeshift_20.11.1_amd64.deb. На виртуалке я из него и установил, проблем не помню. По-моему, просто открыл в менеджере файлов, все зависимости нашлись. На дисковой Астре я её собрал из исходника, чисто из интереса к процессу, но это ведь необязательно. А последнюю версию я собрать не смог, ошибки какие-то лезли. Похоже, нужен компилятор более новой версии.
to Юрий В. Лангинен
Primo, в репозитории Debian 9 лежит далеко не последний GIMP…
Secundo, если Debian-репозиторий нужен на один раз, то проще добавить его через правку /etc/apt/sources.list с опцией [trusted=yes]. Что делает репозиторий «доверенным» и отключает обязательную проверку ключей подписи репозитория (для чего, собственно, нужен debian-keyring)…
Подскажите пожалуйста, мне пришло на ум, а уменьшится ли вероятность ошибок при манипуляциях с тем или иным репозиторием, если перед тем как устанавливать новый репозиторий, пользователь снимет флажок «Разрешен» в приложении «Проверка обновлений-Настройки» и, в дальнейшем, будет работать с этим репозиторием лишь тогда, когда флаг «Разрешен» снят со всех остальных репозиториев?
А перед тем как воспользоваться любым другим репозиторием, пользователь будет снимать этот флаг со всех остальных и оставлять лишь на том, которым в данный момент планирует воспользоваться. Или это не принципиально? Я новичек, поэтому спрашиваю.
Просто в той же инструкции по установке репозиториев в Astra Linux написано, что не рекомендуется одновременно устанавливать даже два родных астровских репозитория: тестинг и экспериментал.
В данный момент подключено целых 4 репозитория.
Так я же в другой теме вам ответил: скачайте не последнюю, а предпоследнюю версию, в виде deb-файла. https://github.com/teejee2008/timeshift/releases/download/v20.11.1/timeshift_20.11.1_amd64.deb. На виртуалке я из него и установил, проблем не помню. По-моему, просто открыл в менеджере файлов, все зависимости нашлись. На дисковой Астре я её собрал из исходника, чисто из интереса к процессу, но это ведь необязательно. А последнюю версию я собрать не смог, ошибки какие-то лезли. Похоже, нужен компилятор более новой версии.
Я скачал то что Вы говорили еще вчера но я не знаю как устанавливать. Где установочный файл? В общем как в файловом менеджере ее установить?
Подскажите пожалуйста, мне пришло на ум, а уменьшится ли вероятность ошибок при манипуляциях с тем или иным репозиторием, если перед тем как устанавливать новый репозиторий, пользователь снимет флажок «Разрешен» в приложении «Проверка обновлений-Настройки» и, в дальнейшем, будет работать с этим репозиторием лишь тогда, когда флаг «Разрешен» снят со всех остальных репозиториев?
А перед тем как воспользоваться любым другим репозиторием, пользователь будет снимать этот флаг со всех остальных и оставлять лишь на том, которым в данный момент планирует воспользоваться. Или это не принципиально? Я новичек, поэтому спрашиваю.
Просто в той же инструкции по установке репозиториев в Astra Linux написано, что не рекомендуется одновременно устанавливать даже два родных астровских репозитория: тестинг и экспериментал.
Посмотреть вложение 1843
В данный момент подключено целых 4 репозитория.
приоритет репозиториев настроен в орле, поэтому можно не убирать галки. ну, а новичку лезть в тестинг и эскпериментал не нужно. и вообще экспериментал давно не обновлялся, а тестинг последнее время обновляется одновременно со стейбл, поэтому смысла в них 0
*в сторону, устало*
Каждый применяемый репозиторий содержит некий перечень пакетов, представляющих собой (условно) готовые к употреблению программы или части поддержки более «комплексных» программ. В разных репозиториях могут встречаться одни и те же пакеты разной версии. И при равных прочих выполнение команд apt upgrade или apt install имя_пакета (то же самое выполняет Synaptic или иная визуальная оболочка пакетного менеджера apt) по умолчанию приведет к попытке установки наиболее «свежей» версии пакета. Что, в большинстве своем, может окончиться плачевно: от банального останова процесса установки/обновления в связи с неразрешимыми зависимостями (большинство пакетов зависят от других), до глобальных сбоев всей ОС в целом. Так что играть в эту увлекательную игру следует только тогда, когда понимаешь, что делаешь…
В рамках одного и того же дистрибутива (той же ALCE) репозитории типа stable содержат в себе перечень пакетов, опробированных авторами дистрибутива — стабильных и не создающих проблем в ОС при их инсталляции/использовании (ну почти, ага). Остальные репозитории (как видно из их названия) содержат «нестабильные», но, как правило, более «свежие» версии тех же пакетов. И использование exprerimental/testing/unstable репозиториев предназначено исключительно для энтузиастов, которые понимают, что и зачем они делают…
В рамках разных дистрибутивов дело осложняется неполной бинарной и конфигурационной совместимостью как самих дистрибутивов, так и перечней пакетов, хранящихся в их репозиториях. Поэтому смешивание репозиториев Debian 9 (и для текущей версии ALCE только 9) с ALCE также повышает вероятность сбоя ОС в целом или каких-либо программных средств в ее составе. Поэтому, при подключении таких репозиториев, опять-таки нужно понимать (и далее по тексту)…
И, главное, если уже был подключен какой-то сторонний репозиторий и с его помощью были обновлены какие-либо компоненты ОС или используемого ПО, то отключать при дальнейших обновлениях этот репозиторий крайне опасно. Потому что весьма вероятно, что проявятся проблемы с зависимостями пакетов из отключенного репозитория, ошибки взаимосвязи и т.д., и т.п. Если, конечно, полностью не понимаешь и не осознаешь, что делаешь…
*в сторону, устало*
Каждый применяемый репозиторий содержит некий перечень пакетов, представляющих собой (условно) готовые к употреблению программы или части поддержки более «комплексных» программ. В разных репозиториях могут встречаться одни и те же пакеты разной версии. И при равных прочих выполнение команд apt upgrade или apt install имя_пакета (то же самое выполняет Synaptic или иная визуальная оболочка пакетного менеджера apt) по умолчанию приведет к попытке установки наиболее «свежей» версии пакета. Что, в большинстве своем, может окончиться плачевно: от банального останова процесса установки/обновления в связи с неразрешимыми зависимостями (большинство пакетов зависят от других), до глобальных сбоев всей ОС в целом. Так что играть в эту увлекательную игру следует только тогда, когда понимаешь, что делаешь…
В рамках одного и того же дистрибутива (той же ALCE) репозитории типа stable содержат в себе перечень пакетов, опробированных авторами дистрибутива — стабильных и не создающих проблем в ОС при их инсталляции/использовании (ну почти, ага). Остальные репозитории (как видно из их названия) содержат «нестабильные», но, как правило, более «свежие» версии тех же пакетов. И использование exprerimental/testing/unstable репозиториев предназначено исключительно для энтузиастов, которые понимают, что и зачем они делают…
В рамках разных дистрибутивов дело осложняется неполной бинарной и конфигурационной совместимостью как самих дистрибутивов, так и перечней пакетов, хранящихся в их репозиториях. Поэтому смешивание репозиториев Debian 9 (и для текущей версии ALCE только 9) с ALCE также повышает вероятность сбоя ОС в целом или каких-либо программных средств в ее составе. Поэтому, при подключении таких репозиториев, опять-таки нужно понимать (и далее по тексту)…
И, главное, если уже был подключен какой-то сторонний репозиторий и с его помощью были обновлены какие-либо компоненты ОС или используемого ПО, то отключать при дальнейших обновлениях этот репозиторий крайне опасно. Потому что весьма вероятно, что проявятся проблемы с зависимостями пакетов из отключенного репозитория, ошибки взаимосвязи и т.д., и т.п. Если, конечно, полностью не понимаешь и не осознаешь, что делаешь…
Да, установку и работу программ, особенно из сторонних репозиториев, лучше сначала пробовать на виртуальной машине. Я так и делаю с тех пор как у меня начались первые проблемы. Вы правы.
Последнее редактирование: 17.11.2021
Usually when you have a non default DNS configuration in your system, for example if you’re using dnsmasq or another DNS service, other than systemd-resolve, it’s possible that dirmngr used by gpg fails to get the resolved name for keyserver.ubuntu.com, then, you need to check your name resolution software.
In my case, I have installed dnsmasq for name resolution in a Zimbra mail server. In this case it is important that you prevent that the resolvconf software controls dnsmasq, this is editing the /etc/default/dnsmasq file and uncommenting this line: IGNORE_RESOLVCONF=yes. Then you have to restart the dnsmasq and try to resolve with the local dns server with this command:
:~$ host -v keyserver.ubuntu.com 127.0.0.1
If it is ok, you will see something like this:
Trying "keyserver.ubuntu.com"
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13994
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;keyserver.ubuntu.com. IN A
;; ANSWER SECTION:
keyserver.ubuntu.com. 417 IN A 162.213.33.8
keyserver.ubuntu.com. 417 IN A 162.213.33.9
Received 70 bytes from 127.0.0.1#53 in 14 ms
Trying "keyserver.ubuntu.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33907
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;keyserver.ubuntu.com. IN AAAA
Received 38 bytes from 127.0.0.1#53 in 1 ms
Trying "keyserver.ubuntu.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45211
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;keyserver.ubuntu.com. IN MX
;; AUTHORITY SECTION:
ubuntu.com. 1748 IN SOA ns1.canonical.com. hostmaster.canonical.com. 2018053167 10800 3600 604800 3600
Received 99 bytes from 127.0.0.1#53 in 16 ms
Even if you’re not using some DNS server, try to ask to systemd-resolve if it can resolve the URL with this:
:~$ host -v keyserver.ubuntu.com 127.0.0.53
If not, let us know what you get.