Если у вас возникли проблемы с клонированием репозитория, рассмотрите эти распространенные ошибки.
Ошибки клонирования HTTPS
При использовании HTTPS с GIT распространен ряд ошибок. Обычно они указывают на то, что у вас старая версия GIT или нет доступа к репозиторию.
Ниже приведен пример возможной ошибки HTTPS:
> error: The requested URL returned error: 401 while accessing
> https://github.com/USER/REPO.git/info/refs?service=git-receive-pack
> fatal: HTTP request failed> Error: The requested URL returned error: 403 while accessing
> https://github.com/USER/REPO.git/info/refs
> fatal: HTTP request failed> Error: https://github.com/USER/REPO.git/info/refs not found: did you run git
> update-server-info on the server?Проверка версии GIT
Ограничений на минимальную версию GIT, требуемую для взаимодействия с GitHub, нет, но, по нашему опыту, версия 1.7.10 является удобной, стабильной версией, доступной на многих платформах. Последнюю версию всегда можно скачать на веб-сайте GIT.
Проверка правильности удаленного репозитория
Репозиторий, который вы пытаетесь получить, должен существовать в GitHub.com, а URL-адрес учитывает регистр.
Чтобы узнать URL-адрес локального репозитория, можно открыть командную строку и ввести git remote -v:
$ git remote -v
# View existing remotes
> origin https://github.com/ghost/reactivecocoa.git (fetch)
> origin https://github.com/ghost/reactivecocoa.git (push)
$ git remote set-url origin https://github.com/ghost/ReactiveCocoa.git
# Change the 'origin' remote's URL
$ git remote -v
# Verify new remote URL
> origin https://github.com/ghost/ReactiveCocoa.git (fetch)
> origin https://github.com/ghost/ReactiveCocoa.git (push)Кроме того, можно изменить URL-адрес с помощью приложения GitHub Desktop.
Предоставление маркера доступа
Чтобы получить доступ к GitHub, необходимо пройти проверку подлинности с помощью personal access token вместо пароля. Дополнительные сведения см. в разделе Создание личного маркера доступа.
Если вы обращаетесь к организации, которая использует единый вход SAML и используете personal access token (classic), вы также должны авторизовать personal access token для доступа к организации перед аутентификацией. Дополнительные сведения см. в разделах Сведения о проверке подлинности с помощью единого входа SAML и Авторизация личного токена доступа для использования с документами единого входа SAML.
Проверить свои разрешения
При появлении запроса на ввод имени пользователя и пароля используйте учетную запись с доступом к репозиторию.
Совет. Если вы не хотите вводить учетные данные при каждом взаимодействии с удаленным репозиторием, можно включить кэширование учетных данных. Если кэширование учетных данных уже используется, убедитесь в том, что на компьютере кэшированы правильные учетные данные. Неправильные или устаревшие учетные данные не позволят пройти проверку подлинности.
Использование SSH
Если вы ранее настроили ключи SSH, можно использовать URL-адрес клонирования SSH вместо HTTPS. Дополнительные сведения см. в разделе Сведения об удаленных репозиториях.
Ошибка: репозиторий не найден
Если вы видите эту ошибку при клонировании репозитория, это означает, что репозиторий не существует или у вас нет разрешения на доступ к нему. Существует несколько решений для этой ошибки в зависимости от причины.
Проверка правильности написания
Всегда есть вероятность опечатки. Кроме того, в именах репозиториев учитывается регистр символов. Если вы попытаетесь клонировать git@github.com:user/repo.git, но репозиторий на самом деле называется User/Repo, произойдет эта ошибка.
Чтобы избежать этой ошибки, при клонировании всегда копируйте URL-адрес клона со страницы репозитория, а затем вставляйте его. Дополнительные сведения см. в разделе Клонирование репозитория.
Сведения об обновлении удаленного репозитория см. в разделе Управление удаленными репозиториями.
Проверка разрешений
Если вы пытаетесь клонировать частный репозиторий, но не имеете разрешения на его просмотр, произойдет эта ошибка.
Убедитесь в том, что у вас есть один из следующих уровней доступа:
- владелец репозитория;
- участник совместной работы над репозиторием;
- участник команды, которая имеет доступ к репозиторию (если репозиторий принадлежит организации).
Проверка доступа по протоколу SSH
В редких случаях может отсутствовать доступ к репозиторию по протоколу SSH из-за неправильной настройки.
Убедитесь в том, что используемый ключ SSH связан с личной учетной записью на GitHub. Это можно проверить, введя в командную строку следующую команду:
$ ssh -T git@github.com
> Hi USERNAME! You've successfully authenticated, but GitHub does not
> provide shell access.Если репозиторий принадлежит организации и вы используете ключ SSH, созданный приложением OAuth, доступ к приложению может быть ограничен владельцем организации. Дополнительные сведения см. в разделе Сведения об ограничениях доступа к приложению OAuth.
Дополнительные сведения см. в разделе Добавление нового ключа SSH в учетную запись GitHub.
Проверка существования репозитория
Если все остальное не удается, убедитесь, что репозиторий действительно существует в GitHub.com!
Если вы пытаетесь выполнить отправку в несуществующий репозиторий, произойдет эта ошибка.
Ошибка: файл HEAD удаленного репозитория ссылается на несуществующую ветвь; не удалось выполнить извлечение
Эта ошибка возникает, если ветвь репозитория по умолчанию была удалена в GitHub.com.
Обнаружить эту ошибку легко: GIT предупредит вас при попытке клонировать репозиторий:
$ git clone https://github.com/USER/REPO.git
# Clone a repo
> Cloning into 'repo'...
> remote: Counting objects: 66179, done.
> remote: Compressing objects: 100% (15587/15587), done.
> remote: Total 66179 (delta 46985), reused 65596 (delta 46402)
> Receiving objects: 100% (66179/66179), 51.66 MiB | 667 KiB/s, done.
> Resolving deltas: 100% (46985/46985), done.
> warning: remote HEAD refers to nonexistent ref, unable to checkout.Чтобы устранить эту ошибку, необходимо быть администратором репозитория в GitHub.com.
Вам потребуется изменить ветвь по умолчанию репозитория.
После этого можно получить список всех доступных ветвей из командной строки:
$ git branch -a
# Lists ALL the branches
> remotes/origin/awesome
> remotes/origin/more-work
> remotes/origin/new-mainЗатем можно просто переключиться на новую ветвь:
$ git checkout new-main
# Create and checkout a tracking branch
> Branch new-main set up to track remote branch new-main from origin.
> Switched to a new branch 'new-main'Время на прочтение
4 мин
Количество просмотров 43K
Если вы когда-нибудь работали над большим проектом, в котором, помимо вас, участвуют и многие другие программисты, тогда вы, очевидно, применяли Git в роли системы контроля версий. В ходе использования чего-то, по уровню сложности похожего Git, все совершают ошибки.
Автор материала, перевод которого мы публикуем сегодня, собирается обсудить распространённые ошибки, которые совершают программисты при работе с Git, и поговорить о том, как с этими ошибками бороться.
Ошибка в сообщении последнего коммита
После нескольких часов хорошей работы легко допустить ошибку в сообщении коммита. К счастью, это легко исправить с помощью следующей команды:
git commit --amendЭта команда откроет редактор и позволит внести изменения в последнее сообщение коммита. Никому кроме вас не стоит знать, что вы написали «Initial commment» с тремя «m».
Ошибка в имени ветки
Предположим, что на часах почти 15:00, а вы ещё не обедали. В результате, терзаемые голодом, вы назвали новую ветку feature-brunch. Вкуснятина, ничего не скажешь.
Эту проблему тоже можно решить. Переименовать ветку можно так же, как переименовывают файлы с помощью команды mv. Речь идёт о перемещении её в новое место с правильным именем:
git branch -m feature-brunch feature-branchЕсли вы уже отправили эту ветку в репозиторий, вам, для её переименования, потребуется сделать ещё пару дел. Старую ветку надо удалить, а новую — отправить в репозиторий:
git push origin --delete feature-brunch
git push origin feature-branchСлучайный коммит изменений в ветку master
Предположим, вы работаете над некоей новой возможностью, и, в спешке, забыли создать для неё новую ветку. Вы закоммитили уже кучу файлов и всё это лежит в ветке master. Переместить все эти изменения в новую ветку можно с помощью следующих трёх команд. Обратите внимание на то, что если вы не воспользовались, в применении к изменениям, командами commit или stash, они будут утеряны.
git branch feature-branch
git reset HEAD~ --hard
git checkout feature-branch
В результате будет создана новая ветка, будет произведён откат изменений в ветке master, до состояния, в котором она была до внесения изменений, и будет осуществлён переход в новую ветку, которая будет содержать в себе все изменения, внесённые ранее в master.
Работа с файлами, которые забыли добавить в последний коммит
Ещё одна распространённая оплошность при работе с Git заключается в том, что коммиты делают слишком рано и в них не попадают нужные файлы. Скажем, вы пропустили некий файл, забыли его сохранить, или вам нужно внести небольшое изменение в файл для того, чтобы последний коммит имел смысл. В подобной ситуации вам снова пригодится команда --amend. Добавьте пропущенный файл в индекс репозитория и запустите эту команду:
git add missed-file.txt
git commit --amendПосле этого вы можете изменить сообщение коммита, либо оставить его таким же, каким оно было.
Добавление не того файла в репозиторий
Как быть, если ваша ошибка представляет собой полную противоположность предыдущей? Что если вы добавили в индекс файл, который не собираетесь коммитить? Это может быть какой-нибудь ENV-файл, директория сборки проекта, фото вашей собаки, которое вы случайно сохранили не в той папке. Всё это можно исправить.
Если ваши действия ограничиваются индексированием файла, но вы пока не закоммитили его, справиться с проблемой будет очень легко, воспользовавшись командой reset:
git reset /assets/img/misty-and-pepper.jpgЕсли вы продвинулись достаточно далеко и успели изменение закоммитить, то знайте, что и это поправимо. Придётся лишь воспользоваться ещё несколькими командами:
git reset --soft HEAD~1
git reset /assets/img/misty-and-pepper.jpg
rm /assets/img/misty-and-pepper.jpg
git commitВ результате последний коммит будет отменён, изображение будет удалено, после чего новый коммит будет помещён туда, где ему положено быть.
Что делать, если всё пошло не так?
Методика, которую мы сейчас обсудим, помогает в ситуациях, когда всё идёт не так, как надо. Например, такое происходит, когда вы слишком увлекаетесь копированием готовых решений со StackOverflow, и, после работы, ваш репозиторий оказывается в худшем состоянии чем он был в самом начале. В такую ситуацию, пожалуй, попадали все мы.
Команда git reflog показывает список всего, что вы сделали. Затем она позволяет воспользоваться инструментами Git для отката изменений, для возврата к одному из прошлых состояний репозитория. Стоит отметить, что этот метод стоит рассматривать как последнее средство, и, прежде чем им воспользоваться, стоит как следует подумать. Итак, вывести список того, что было сделано, можно следующей командой:
git reflogGit помнит все наши действия и в результате выполнения этой команд можно увидеть примерно следующее:
3ff8691 (HEAD -> feature-branch) HEAD@{0}: Branch: renamed refs/heads/feature-brunch to refs/heads/feature-branch
3ff8691 (HEAD -> feature-branch) HEAD@{2}: checkout: moving from master to feature-brunch
2b7e508 (master) HEAD@{3}: reset: moving to HEAD~
3ff8691 (HEAD -> feature-branch) HEAD@{4}: commit: Adds the client logo
2b7e508 (master) HEAD@{5}: reset: moving to HEAD~1
37a632d HEAD@{6}: commit: Adds the client logo to the project
2b7e508 (master) HEAD@{7}: reset: moving to HEAD
2b7e508 (master) HEAD@{8}: commit (amend): Added contributing info to the site
dfa27a2 HEAD@{9}: reset: moving to HEAD
dfa27a2 HEAD@{10}: commit (amend): Added contributing info to the site
700d0b5 HEAD@{11}: commit: Addded contributing info to the site
efba795 HEAD@{12}: commit (initial): Initial commit
Обратите внимание на самую левую колонку этого списка. Тут содержатся индексы. Если вам нужно вернуться назад, в некий момент прошлого, выполните следующую команду, заменив {index} соответствующей ссылкой, например — dfa27a2. Выглядит эта команда так:
git reset HEAD@{index}Итоги
Мы рассмотрели некоторые способы борьбы с ошибками, возникающими при работе с Git. Надеемся, вы подобных ошибок не допустите и вам эти приёмы работы с Git не пригодятся. А если что-то пойдёт не так — вы будете знать, что делать.
Уважаемые читатели! Знаете о каких-нибудь интересных приёмах работы с Git? Если так — просим ими поделиться.
| title | intro | redirect_from | versions | topics | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Troubleshooting cloning errors |
If you’re having trouble cloning a repository, check these common errors. |
|
|
Repositories |
HTTPS cloning errors
There are a few common errors when using HTTPS with Git. These errors usually indicate you have an old version of Git, or you don’t have access to the repository.
Here’s an example of an HTTPS error you might receive:
> error: The requested URL returned error: 401 while accessing > https://{% data variables.command_line.codeblock %}/USER/REPO.git/info/refs?service=git-receive-pack > fatal: HTTP request failed
> Error: The requested URL returned error: 403 while accessing > https://{% data variables.command_line.codeblock %}/USER/REPO.git/info/refs > fatal: HTTP request failed
> Error: https://{% data variables.command_line.codeblock %}/USER/REPO.git/info/refs not found: did you run git > update-server-info on the server?
Check your Git version
There’s no minimum Git version necessary to interact with {% data variables.product.product_name %}, but we’ve found version 1.7.10 to be a comfortable stable version that’s available on many platforms. You can always download the latest version on the Git website.
Ensure the remote is correct
The repository you’re trying to fetch must exist on {% data variables.location.product_location %}, and the URL is case-sensitive.
You can find the URL of the local repository by opening the command line and
typing git remote -v:
$ git remote -v # View existing remotes > origin https://github.com/ghost/reactivecocoa.git (fetch) > origin https://github.com/ghost/reactivecocoa.git (push) $ git remote set-url origin https://github.com/ghost/ReactiveCocoa.git # Change the 'origin' remote's URL $ git remote -v # Verify new remote URL > origin https://github.com/ghost/ReactiveCocoa.git (fetch) > origin https://github.com/ghost/ReactiveCocoa.git (push)
Alternatively, you can change the URL through our
{% data variables.product.prodname_desktop %} application.
Provide an access token
To access {% data variables.product.prodname_dotcom %}, you must authenticate with a {% data variables.product.pat_generic %} instead of your password. For more information, see “AUTOTITLE.”
{% data reusables.command_line.provide-an-access-token %}
Check your permissions
When prompted for a username and password, make sure you use an account that has access to the repository.
{% tip %}
Tip: If you don’t want to enter your credentials every time you interact with the remote repository, you can turn on credential caching. If you are already using credential caching, please make sure that your computer has the correct credentials cached. Incorrect or out of date credentials will cause authentication to fail.
{% endtip %}
Use SSH instead
If you’ve previously set up SSH keys, you can use the SSH clone URL instead of HTTPS. For more information, see “AUTOTITLE.”
Error: Repository not found
{% ifversion fpt or ghae or ghec %}If you see this error when cloning a repository, it means that the repository does not exist or you do not have permission to access it.{% else %}If you see this error when cloning a repository, it means that the repository does not exist, you do not have permission to access it, or {% data variables.location.product_location %} is in private mode.{% endif %} There are a few solutions to this error, depending on the cause.
Check your spelling
Typos happen, and repository names are case-sensitive. If you try to clone git@{% data variables.command_line.codeblock %}:user/repo.git, but the repository is really named User/Repo you will receive this error.
To avoid this error, when cloning, always copy and paste the clone URL from the repository’s page. For more information, see “AUTOTITLE.”
To update the remote on an existing repository, see “AUTOTITLE”.
Checking your permissions
If you are trying to clone a private repository but do not have permission to view the repository, you will receive this error.
Make sure that you have access to the repository in one of these ways:
- The owner of the repository
- A collaborator on the repository
- A member of a team that has access to the repository (if the repository belongs to an organization)
Check your SSH access
In rare circumstances, you may not have the proper SSH access to a repository.
You should ensure that the SSH key you are using is attached to your personal account on {% data variables.product.product_name %}. You can check this by typing
the following into the command line:
$ ssh -T git@{% data variables.command_line.codeblock %}
> Hi USERNAME! You've successfully authenticated, but GitHub does not
> provide shell access.
{% ifversion fpt or ghec %}
If the repository belongs to an organization and you’re using an SSH key generated by an OAuth App, OAuth App access may have been restricted by an organization owner. For more information, see “AUTOTITLE.”
{% endif %}
For more information, see Adding a new SSH key to your GitHub account.
{% ifversion ghes %}
Check if your instance is in private mode
If your site administrator has enabled private mode on your GitHub Enterprise instance, anonymous clones over git:// will be disabled. If you are unable to clone a repository, contact your site administrator.
{% endif %}
Check that the repository really exists
If all else fails, make sure that the repository really exists on {% data variables.location.product_location %}!
If you’re trying to push to a repository that doesn’t exist, you’ll get this error.
Error: Remote HEAD refers to nonexistent ref, unable to checkout
This error occurs if the default branch of a repository has been deleted on {% data variables.location.product_location %}.
Detecting this error is simple; Git will warn you when you try to clone the repository:
$ git clone https://{% data variables.command_line.codeblock %}/USER/REPO.git
# Clone a repo
> Cloning into 'repo'...
> remote: Counting objects: 66179, done.
> remote: Compressing objects: 100% (15587/15587), done.
> remote: Total 66179 (delta 46985), reused 65596 (delta 46402)
> Receiving objects: 100% (66179/66179), 51.66 MiB | 667 KiB/s, done.
> Resolving deltas: 100% (46985/46985), done.
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
To fix the error, you’ll need to be an administrator of the repository on {% data variables.location.product_location %}.
You’ll want to change the default branch of the repository.
After that, you can get a list of all the available branches from the command line:
$ git branch -a # Lists ALL the branches > remotes/origin/awesome > remotes/origin/more-work > remotes/origin/new-main
Then, you can just switch to your new branch:
$ git checkout new-main # Create and checkout a tracking branch > Branch new-main set up to track remote branch new-main from origin. > Switched to a new branch 'new-main'
Довольно часто при использовании сторонних PPA репозиториев во время обновления списка пакетов можно получить ошибку репозиторий не содержит файла release Ubuntu. Обычно она не мешает работе других репозиториев, но репозитории, которые выдают эту ошибку чаще всего не обновляются.
В этой небольшой статье мы разберем что означает эта проблема, а также пути ее решения. Статья ориентированна, в основном, на Ubuntu, но подойдет для Debian и всех основанных на нем или Ubuntu систем.
Файл Release – один из самых важных файлов для работы репозитория в Ubuntu. Когда утилита apt обновляет список пакетов, она открывает адрес репозитория и пытается прочитать файл Release. В нем содержится основная информация о репозитории, а также адреса файлов packages.gz, в которых находятся списки пакетов, ссылки где их можно найти и контрольные суммы. Если этого файла нет, то репозиторий подключить невозможно.
Причин этому может быть несколько. Либо репозиторий заброшен и больше не развивается, либо вы его неправильно настроили. В терминале эти ошибки обычно не мешают, а вот при попытке обновления через графический интерфейс могут возникнуть проблемы.
1. Нет ветки репозитория для вашей версии Ubuntu
Сначала убедитесь, что вы используете правильные репозитории для своего дистрибутива. Например, утилита apt-add-repository при добавлении PPA репозитория добавляет к его адресу кодовое имя дистрибутива. У репозитория нет отдельной ветки для вашей системы, то он не сможет быть добавлен. Нужно вручную указать то, кодовое имя, для которого есть ветка.
Например, если вы пытаетесь добавить репозиторий ubuntu-audio-dev стандартным способом в Ubuntu, то получите ошибку:
Зайдите на страницу этого PPA репозитория на Launchpad и проверьте есть ли версия для вашего дистрибутива. Как видите, здесь версии для Ubuntu 18.04 Bionic нет, есть только для Ubuntu 13.04 Raring:
Конечно, такое использование репозиториев не очень безопасно, но если вам очень нужно его добавить, то можно найти файл репозитория в /etc/apt/sources.list.d/ и заменить в нем bionic на raring:
ls /etc/apt/sources.list.d/
vi /etc/apt/sources.list.d/ubuntu-audio-dev-ubuntu-ppa-bionic.list
Теперь, репозиторий загружается нормально
sudo apt update
Система сообщает только что невозможно пройти проверку подлиности ключа, возможно, срок его действия уже истек. Чтобы игнорировать проверку подлинности репозитория по GPG добавить в строку конфигурации репозитория такой параметр:
[trusted=yes]
2. Вы используете старую версию системы
Также подобную ошибку вы можете получать если используете старую, уже не поддерживаемую версию Ubuntu. Дело в том, что после завершения срока поддержки, текущие репозитории пакетов переносятся на другой сервер – old-releases.ubuntu.com. Чтобы устанавливать программное обеспечение в этих дистрибутивах нужно добавить заменить все адреса archive.ubuntu.com и security.ubuntu.com на old-releases.ubuntu.com/ubuntu в файле /etc/apt/sources.list:
sudo vi /etc/apt/sources.list
Только тогда нужные пакеты будут доступны. Это все касается не только Ubuntu, но и других дистрибутивов, только кодовые имена там будут другими.
3. Удаление не работающих репозиториев
Если таким способом ошибку устранить не удалось, остается только удалить проблемный репозиторий, чтобы он не выводил каждый раз ошибки и не мешал обновлению через графический интерфейс. Отключить репозиторий можно через графический интерфейс. Для этого откройте окно “Программы и обновления”:
Затем перейдите на вкладку “Другое ПО”:
Здесь нужно снять галочки с проблемных репозиториев для их отключения.
Также можно удалить полностью репозиторий через терминал, выполнив команду:
sudo apt-add-repository --remove ppa://имя_репозитория/ppa
Например:
sudo apt-add-repository --remove ppa://ubuntu-audio-dev/ppa
Или еще можно удалить файл настроек репозитория из /etc/apt/sources.list.d/, но этот вариант не такой надежный, так, как в системе все еще останется ключ репозитория.
Выводы
В этой статье мы рассмотрели как исправить ошибку repository has no release file. Хоть это проблема не пользователя, а скорее самого репозитория, можно кое-что сделать чтобы ее исправить. Если у вас остались вопросы, спрашивайте в комментариях!
Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.
Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .
Об авторе
Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux, интересуюсь всем, что связано с информационными технологиями и современной наукой.
Недавно я установил Ubuntu Server на моей Raspberry Pi. Я подключился к Wi-Fi с терминала Ubuntu и продолжил делать то, что я делаю после установки любой системы Linux, которая должна обновлять систему.
Когда я использовал команду ‘sudo apt update‘, терминал выдал мне ошибку, которая была своего рода уникальной для меня. Он жаловался на то, что файл релиза для репозитория был недействителен в течение определенного периода времени.
E: Release file for http://ports.ubuntu.com/ubuntu-ports/dists/focal-security/InRelease is not valid yet (invalid for another 159d 15h 20min 52s). Updates for this repository will not be applied.
Вот полный вывод в терминале:
ubuntu@ubuntu:~$ sudo apt update
Hit:1 http://ports.ubuntu.com/ubuntu-ports focal InRelease
Get:2 http://ports.ubuntu.com/ubuntu-ports focal-updates InRelease [111 kB]
Get:3 http://ports.ubuntu.com/ubuntu-ports focal-backports InRelease [98.3 kB]
Get:4 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease [107 kB]
Reading package lists... Done
E: Release file for http://ports.ubuntu.com/ubuntu-ports/dists/focal/InRelease is not valid yet (invalid for another 21d 23h 17min 25s). Updates for this repository will not be applied.
E: Release file for http://ports.ubuntu.com/ubuntu-ports/dists/focal-updates/InRelease is not valid yet (invalid for another 159d 15h 21min 2s). Updates for this repository will not be applied.
E: Release file for http://ports.ubuntu.com/ubuntu-ports/dists/focal-backports/InRelease is not valid yet (invalid for another 159d 15h 21min 32s). Updates for this repository will not be applied.
E: Release file for http://ports.ubuntu.com/ubuntu-ports/dists/focal-security/InRelease is not valid yet (invalid for another 159d 15h 20min 52s). Updates for this repository will not be applied.Исправление ошибки “release file is not valid yet” в Ubuntu и других дистрибутивах ОС Linux.
Причина ошибки – разница во времени в системе и во времени в реальном мире.
Как видите, каждый файл репозитория подписан в какую-то дату, и вы можете увидеть эту информацию, просмотрев файл выпуска:
sudo head /var/lib/apt/lists/ports.ubuntu.com_ubuntu_dists_focal_InRelease
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Origin: Ubuntu
Label: Ubuntu
Suite: focal
Version: 20.04
Codename: focal
Date: Thu, 23 Apr 2020 17:33:17 UTC
Architectures: amd64 arm64 armhf i386 ppc64el riscv64 s390xПо каким-то причинам, время на моем сервере Ubuntu было в прошлом, и именно поэтому Ubuntu жаловался, что файл релиза пока не действителен в течение многих дней.
Если Вы подключены к Интернету, Вы можете подождать несколько минут, пока Ваша система синхронизирует время.
Если это не сработало, вы можете заставить систему использовать местное время как часы реального времени (аппаратные часы):
sudo timedatectl set-local-rtc 1Команда timedatectl позволяет настроить время, дату и изменение часового пояса в Linux.
Тебе не нужно перезагружаться. Команда сработает немедленно, и вы можете проверить это, снова обновив систему Ubuntu.
Если проблема решена, вы можете установить часы реального времени на использование UTC (как рекомендует Ubuntu).
sudo timedatectl set-local-rtc 0Эта статья помогла вам решить проблему?
Надеюсь, этот небольшой совет помог вам исправить эту ошибку. Если вы все еще сталкиваетесь с проблемой, дайте мне знать в разделе комментариев, и я постараюсь вам помочь.
