رفع خطای duplicate apt sources در اوبونتو و دبیان

خطای duplicate apt sources به چه معناست

خطای duplicate apt sources به این معنی است که یک مخزن (repository) دو بار و در دو فایل متفاوت تعریف شده است و APT (ابزار پیشرفته بسته‌ها) هر دو نسخه را پیدا کرده است. در Ubuntu 24.04 و نسخه‌های جدیدتر، این اتفاق تقریباً همیشه به این دلیل رخ می‌دهد که یک اسکریپت نصب شخص ثالث، یک فایل قدیمی تک‌خطی .list ایجاد کرده است، در حالی که یک فایل deb822 .sources برای همان مخزن از قبل روی دیسک وجود داشته است. هیچ خرابی رخ نداده و هیچ بسته‌ای در معرض خطر نیست. یکی از این دو تعریف را حذف کنید تا پیام خطا برطرف شود.

این همان خطی است که کاربران در کادر جستجو کپی می‌کنند:

W: Target Packages (stable/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/docker.list:1 and /etc/apt/sources.list.d/docker.sources:1

آن را از انتها بخوانید. دو فایل، که هر کدام دارای یک شماره خط هستند، یک مورد مشابه را اعلام می‌کنند. Target Packages ایندکسی است که apt دانلود می‌کند تا بداند هر مخزن چه بسته‌هایی ارائه می‌دهد، و stable/binary-amd64/Packages نام کامپوننت (stable) و معماری (amd64) آن ایندکس را مشخص می‌کند. بنابراین apt به شما می‌گوید که ایندکس amd64 برای کامپوننت stable در فایل docker.list در خط 1 و دوباره در فایل docker.sources در خط 1 پیکربندی شده است.

در apt 3.0 و نسخه‌های جدیدتر، یعنی Ubuntu 25.04 به بعد و Debian 13، همین پیام به جای W: با Warning: شروع می‌شود. متن بعد از پیشوند یکسان است.

آن هشدار حالت خفیف است. apt دو تعریف را با هم ادغام می‌کند و عملیات update همچنان اجرا می‌شود، زیرا هر دو، یک آرشیو واحد را با یک کلید یکسان توصیف می‌کنند. حالت سخت، همه چیز را متوقف می‌کند:

E: Conflicting values set for option Signed-By regarding source https://download.docker.com/linux/ubuntu/ noble: /usr/share/keyrings/docker-archive-keyring.gpg != /etc/apt/keyrings/docker.asc
E: The list of sources could not be read.

در اینجا apt از ادامه کار خودداری می‌کند زیرا دو تعریف، کلیدهای امضای متفاوتی را برای یک آرشیو نام می‌برند. apt دو تعریف کاملاً یکسان را ادغام می‌کند، اما بین دو مقدار Signed-By متفاوت انتخاب نمی‌کند، زیرا انتخاب اشتباه به این معنی است که امضای بسته‌ها با کلیدی بررسی می‌شود که مالک آرشیو هرگز با آن امضا نکرده است. بنابراین apt هیچ منبعی را نمی‌خواند. دستورات apt update و apt install هر دو با همان دو خط خطا مواجه می‌شوند تا زمانی که فایل‌ها را به‌صورت دستی ویرایش کنید.

چگونگی ایجاد فایل‌های تکراری

این دو فرمت در فایل‌های جداگانه‌ای با پسوندهای متفاوت ذخیره می‌شوند، بنابراین هیچ محدودیتی در سطح دیسک برای وجود همزمان آن‌ها وجود ندارد. ابزار apt این هم‌پوشانی را با تأخیر شناسایی می‌کند؛ یعنی زمانی که تمام فایل‌های منبع را به لیست اهداف ایندکسی که قصد دریافت آن‌ها را دارد، گسترش می‌دهد. تا پیش از آن لحظه، docker.list و docker.sources دو فایل کاملاً بی‌ارتباط هستند.

چهار رویداد عادی باعث ایجاد این جفت فایل می‌شوند:

• اسکریپت نصب یک فروشنده (vendor)، یا دستوری که از یک پست قدیمی کپی شده است، فایل /etc/apt/sources.list.d/vendor.list را با یک خط tee ایجاد می‌کند.
• بستهٔ نرم‌افزاری خودِ فروشنده بعداً فایل /etc/apt/sources.list.d/vendor.sources را ارائه می‌دهد و آن را برای شما نصب می‌کند.
• ابزار add-apt-repository در اوبونتو 24.04 و نسخه‌های جدیدتر، فایل‌های .sources با فرمت deb822 می‌نویسد؛ بنابراین یک PPA (آرشیو بسته شخصی) که زمانی به‌صورت دستی به شکل .list اضافه کرده بودید، اکنون به شکل .sources بازمی‌گردد.
• ارتقای نسخهٔ توزیع (release upgrade)، فایل‌های منبع خودِ توزیع را به فرمت deb822 بازنویسی کرده و فایل .list که شما به‌صورت دستی نوشته بودید را در کنار آن‌ها دست‌نخورده باقی گذاشته است.

هر یک از این مسیرها به‌تنهایی منطقی هستند. فایل تکراری نتیجهٔ وقوع دو مورد از این رویدادها روی یک سیستم واحد است که اغلب با فاصلهٔ چند ماه از یکدیگر رخ می‌دهند.

مقایسه دو فرمت در کنار یکدیگر

فرمت قدیمی به صورت یک خط برای هر مخزن است و تمام بخش‌های آن بر اساس موقعیت قرارگیری تعریف می‌شوند.

deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu noble stable

ترتیب ثابت است: نوع (deb برای بسته‌های باینری، deb-src برای بسته‌های سورس)، سپس گزینه‌ها در داخل کروشه، سپس URI (شناسه منبع یکپارچه) آرشیو، سپس suite و در نهایت یک یا چند کامپوننت. از آنجا که معنای هر بخش از موقعیت آن استخراج می‌شود، یک فضای خالی نابجا باعث تغییر در نحوه خواندن apt می‌شود.

فرمت deb822 همان اطلاعات را در قالب یک stanza از فیلدهای نام‌گذاری‌شده بیان می‌کند. نام این فرمت از RFC 822 گرفته شده است؛ همان سبک هدر ایمیل که دبیان پیش‌تر برای فایل‌های کنترل بسته از آن استفاده می‌کند.

Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: noble
Components: stable
Architectures: amd64
Signed-By: /etc/apt/keyrings/docker.asc

همان مخزن، همان کلید، بدون هیچ تغییر اضافی. نگاشت مستقیم است: deb به Types تبدیل می‌شود، آدرس آرشیو به URIs، بخش suite به Suites، کامپوننت‌ها به Components و هر گزینه داخل کروشه به فیلد اختصاصی خود تبدیل می‌شود؛ بنابراین signed-by= به Signed-By: و arch= به Architectures: تبدیل می‌گردد.

نام تمام فیلدها به صورت جمع است، زیرا هر فیلد یک لیست جدا شده با فاصله را می‌پذیرد. Suites: noble noble-updates noble-backports در یک stanza جایگزین سه خط مجزای deb می‌شود. یک خط خالی پایان یک stanza را مشخص می‌کند، بنابراین یک فایل .sources واحد می‌تواند چندین مخزن را در خود جای دهد. فرمت deb822 همچنین تنظیماتی را مدیریت می‌کند که فرمت تک‌خطی در انجام آن‌ها ضعیف است: Enabled: no برای غیرفعال کردن یک مخزن، Trusted، Check-Valid-Until و یک کلید درون‌خطی که مستقیماً در Signed-By قرار می‌گیرد، به طوری که هر خط با یک فاصله تورفتگی داشته باشد و خطوط خالی به صورت یک نقطه نوشته شوند.

محل قرارگیری فایل‌ها

• /etc/apt/sources.list: فایل اصلی و تکی. در Ubuntu 24.04 و نسخه‌های جدیدتر، این فایل معمولاً خالی است یا فقط شامل یک توضیح است که به محل جدید اشاره می‌کند.
• /etc/apt/sources.list.d/*.list: ورودی‌های تک‌خطی؛ معمولاً برای هر مخزن یک فایل در نظر گرفته می‌شود.
• /etc/apt/sources.list.d/*.sources: استنزاهای deb822. در Ubuntu 24.04 و نسخه‌های جدیدتر، مخازن پیش‌فرض توزیع در اینجا و در فایل ubuntu.sources نگهداری می‌شوند.
• /etc/apt/keyrings/: محل قرارگیری کلیدهایی که شما اضافه می‌کنید. فایل /usr/share/keyrings/ شامل کلیدهایی است که از طریق یک بسته (package) نصب شده‌اند.

ابزار apt فقط فایل‌هایی را می‌خواند که با .list یا .sources ختم شوند. نام فایل می‌تواند شامل حروف، اعداد، زیرخط، خط تیره و نقطه باشد. فایل‌هایی با هر پسوند دیگری نادیده گرفته می‌شوند و یک اعلان (notice) صادر می‌شود؛ این موضوع برای اصلاحی که در ادامه آمده، اهمیت دارد.

یافتن جفت تکراری

با لیست کردن دایرکتوری شروع کنید:

ls -l /etc/apt/sources.list.d/

-rw-r--r-- 1 root root  195 Aug  3 09:12 docker.list
-rw-r--r-- 1 root root  254 Aug  9 14:40 docker.sources
-rw-r--r-- 1 root root 2683 Jun 11 08:02 ubuntu.sources

دو فایلی که نام پایه یکسان و پسوندهای متفاوت دارند، جفت رایج هستند، اما به نام‌ها اعتماد نکنید. محتویات را بخوانید، زیرا یک فایل تکراری می‌تواند با هر نامی پنهان شده باشد:

grep -rn -E '^(deb |deb-src |Types:|URIs:|Suites:|Signed-By:)' /etc/apt/sources.list /etc/apt/sources.list.d/

/etc/apt/sources.list.d/docker.list:1:deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu noble stable
/etc/apt/sources.list.d/docker.sources:1:Types: deb
/etc/apt/sources.list.d/docker.sources:2:URIs: https://download.docker.com/linux/ubuntu
/etc/apt/sources.list.d/docker.sources:3:Suites: noble
/etc/apt/sources.list.d/docker.sources:6:Signed-By: /etc/apt/keyrings/docker.asc

این جفت، دو ورودی با host یکسان و suite یکسان هستند. هر دو به https://download.docker.com/linux/ubuntu و suite noble اشاره دارند، بنابراین آن‌ها یک مخزن (repository) هستند که دو بار نوشته شده است. مسیرهای Signed-By آن‌ها نیز با هم تفاوت دارند، که همین موضوع باعث ایجاد خطای Conflicting values نمایش داده شده در قبل می‌شود.

برای این مرحله، به‌جای دستور apt از grep استفاده کنید. هنگامی که apt به دلیل تداخل متوقف می‌شود، نمی‌تواند منابع شما را لیست کند، بنابراین apt-cache policy به‌جای پاسخی که می‌خواهید، همان خطا را چاپ می‌کند.

اصلاح: فایل deb822 را نگه دارید و فایل قدیمی را حذف کنید

فایل .sources را نگه دارید. این فرمتی است که ابزارهای apt اکنون می‌نویسند و مسیری است که هم Debian و هم Ubuntu در پیش گرفته‌اند. پیش از حذف هر چیزی، بررسی کنید کدام‌یک از دو مسیر کلید روی دیسک موجود است:

ls -l /etc/apt/keyrings/ /usr/share/keyrings/ | grep -i docker

-rw-r--r-- 1 root root 4813 Aug  9 14:40 docker.asc

تنها /etc/apt/keyrings/docker.asc موجود است، بنابراین فایل deb822 همان فایلی است که اطلاعات صحیح را دارد و فایل .list به کلیدی اشاره می‌کند که حذف شده است. اگر مشخص شد فایلی که قصد نگهداری آن را دارید به کلید مفقود اشاره می‌کند، ابتدا مسیر صحیح را در آن کپی کنید و سپس فایل دیگر را حذف نمایید.

فایل قدیمی را به‌جای حذف مستقیم، از دایرکتوری خارج کنید:

sudo mkdir -p /root/apt-sources-backup
sudo mv /etc/apt/sources.list.d/docker.list /root/apt-sources-backup/
sudo apt update

تغییر نام آن به docker.list.bak و باقی گذاشتن آن در همان مسیر نیز کارساز است، زیرا apt پسوندهای ناشناس را نادیده می‌گیرد، اما در این صورت هر بار اجرای apt این پیام را چاپ می‌کند:

N: Ignoring file 'docker.list.bak' in directory '/etc/apt/sources.list.d/' as it has an invalid filename extension

انتقال فایل به مکانی دیگر باعث می‌شود آن اعلان از صفحه شما حذف شود و در عین حال نسخه پشتیبان نیز حفظ گردد. یک apt update سالم پس از این تغییرات به این شکل است و هیچ خطی که به دو فایل اشاره کند در آن دیده نمی‌شود:

Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 https://download.docker.com/linux/ubuntu noble InRelease [48.8 kB]
Get:3 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
Fetched 175 kB in 1s (146 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

اکنون تأیید کنید که مخزن پس از این ویرایش همچنان فعال است:

apt-cache policy | grep download.docker.com

 500 https://download.docker.com/linux/ubuntu noble/stable amd64 Packages
     origin download.docker.com

اگر مستندات یک فروشنده همچنان فرض را بر فایل تک‌خطی می‌گذارد، می‌توانید آن را نگه دارید و به‌جای آن فایل .sources را حذف کنید. یک قانون کلی برای هر دو حالت وجود دارد: دقیقاً یک فایل باید یک آرشیو و suite مشخص را تعریف کند.

چرا یک منبع شخص ثالثِ معیوب، فرآیند apt update را متوقف می‌کند

خطای مشابه دیگری وجود دارد که ریشه آن یکسان است: یک منبع شخص ثالث که apt نمی‌تواند از آن استفاده کند. نسخه اول این مشکل، فقدان یک کلید است:

Err:5 https://download.docker.com/linux/ubuntu noble InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7EA0A9C3F273FCD8
E: The repository 'https://download.docker.com/linux/ubuntu noble InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

فیلد Signed-By وجود ندارد یا به فایلی اشاره می‌کند که کلید معتبری نیست؛ بنابراین apt نمی‌تواند امضای فایل InRelease مخزن را تأیید کند. در نتیجه، apt به‌جای اعتماد به لیست بسته‌هایی که قابل بررسی نیستند، کل آن مخزن را کنار می‌گذارد. فایل کلید را بررسی کنید:

ls -l /etc/apt/keyrings/docker.asc
gpg --show-keys /etc/apt/keyrings/docker.asc

یک کلید سالم، یک خط pub شامل شناسه کلید و یک خط uid که نام فروشنده را ذکر می‌کند، نمایش می‌دهد. خروجی gpg: no valid OpenPGP data found. به این معنی است که فایل اصلاً کلید نیست؛ این معمولاً یعنی دانلود، یک صفحه خطا را ذخیره کرده است زیرا آدرس URL کلید تغییر کرده است. کلید را دوباره دریافت کنید، فایل را بررسی کنید و سپس دستور apt update را اجرا کنید.

نسخه دوم پس از ارتقای نسخه توزیع (release upgrade) رخ می‌دهد:

Err:6 https://ppa.launchpadcontent.net/ondrej/php/ubuntu plucky InRelease
  404  Not Found [IP: 10.0.0.80 443]
E: The repository 'https://ppa.launchpadcontent.net/ondrej/php/ubuntu plucky Release' does not have a Release file.

آن PPA هیچ محتوایی برای آن نسخه از توزیع منتشر نکرده است، بنابراین مسیر مربوطه روی سرور وجود ندارد و درخواست، خطای 404 برمی‌گرداند. سایر مخازن شما همچنان به‌روزرسانی می‌شوند و بسته‌هایی که از قبل دارید دست‌نخورده باقی می‌مانند. با این حال، اجرای دستور با کد خروجی غیرصفر پایان می‌یابد؛ بنابراین هر اسکریپتی که وضعیت خروجی apt update را بررسی می‌کند، اکنون هر بار گزارش خطا می‌دهد. به همین دلیل است که پاک‌سازی یک منبع ازکارافتاده در سیستمی که ارتقاهای امنیتی خودکار روی آن تنظیم شده، ضروری است: هشدارهای روزانه بی‌مورد، باعث پنهان ماندن خطاهای واقعی می‌شوند.

غیرفعال‌سازی یک منبع بدون ایجاد اختلال در سایر بخش‌ها

برای یک فایل با فرمت deb822، یک فیلد به stanza اضافه کرده و آن را ذخیره کنید:

Types: deb
URIs: https://ppa.launchpadcontent.net/ondrej/php/ubuntu
Suites: plucky
Components: main
Signed-By: /etc/apt/keyrings/ondrej-php.asc
Enabled: no

راهنمای apt این روش را به جای کامنت کردن تک‌تک خطوط stanza توصیه می‌کند و بازگرداندن آن نیز ساده‌تر است. برای فایلی که تنها یک خط دارد، در ابتدای خط یک # قرار دهید. برای هر دو فرمت، انتقال فایل به خارج از مسیر /etc/apt/sources.list.d/ نیز کارساز است و این گزینه‌ای است که باید هنگام حذف دائمی یک مخزن انتخاب کنید.

دستور sudo apt update را دوباره اجرا کنید. بلوک Err: مربوط به آن مخزن ناپدید می‌شود و وضعیت خروجی به 0 برمی‌گردد که می‌توانید آن را با echo $? در خط بعدی بررسی کنید.

هرگز یک منبع خراب را با sudo rm /etc/apt/sources.list.d/* تعمیر نکنید. در Ubuntu 24.04 و نسخه‌های جدیدتر، این کار باعث حذف ubuntu.sources می‌شود که حاوی مخازن اصلی توزیع است؛ در نتیجه apt هیچ لیست بسته‌ای نخواهد داشت و برای نرم‌افزارهایی که به‌وضوح وجود دارند، خطای E: Unable to locate package curl گزارش می‌دهد. اگر قبلاً این دستور را اجرا کرده‌اید، فایل را بازنویسی کنید:

Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

آن را با نام /etc/apt/sources.list.d/ubuntu.sources ذخیره کنید، در حالی که noble با نام release خودتان از lsb_release -cs جایگزین شده باشد، سپس sudo apt update را اجرا کنید.

تبدیل فایل‌های قدیمی .list به فرمت deb822

از اوت 2026، نسخه 3.0 و جدیدتر apt شامل یک مبدل برای این کار است. Debian 13 و همچنین Ubuntu 25.04 و تمامی نسخه‌های پس از آن، از جمله 26.04، این قابلیت را دارند. ابتدا نسخه را بررسی کرده و سپس دستور زیر را اجرا کنید:

apt --version
sudo apt modernize-sources

این دستور فایل‌های تک‌خطی موجود در مسیر /etc/apt/sources.list.d/ را به فایل‌های deb822 در مسیر .sources بازنویسی می‌کند. خروجی چاپ‌شده را مطالعه کنید، سپس محتویات دایرکتوری را شخصاً بررسی کرده و پیش از اعتماد به نتیجه، دستور apt update را اجرا کنید. Ubuntu 24.04 از نسخه قدیمی‌تری از apt استفاده می‌کند که فاقد این زیردستور است و در آن نسخه، دستور مذکور خطای E: Invalid operation modernize-sources را برمی‌گرداند. در آن نسخه، تبدیل را باید به‌صورت دستی و با استفاده از نگاشت فیلدهای ذکرشده در بالا انجام دهید.

تبدیل فرمت در حال حاضر اختیاری است، زیرا apt همچنان هر دو فرمت را می‌خواند. انجام این کار برای سروری که قصد نگهداری طولانی‌مدت آن را دارید توصیه می‌شود، چرا که تمامی ابزارهایی که امروزه منابع (sources) را می‌نویسند از فرمت deb822 استفاده می‌کنند و سیستمی که فقط دارای فایل‌های .sources باشد، دچار این نوع تکرار نخواهد شد.

مرتب نگه‌داشتن منابع شخص‌ثالث در سرور

مخازن شخص‌ثالث بخشی از سرور هستند که سریع‌تر از سایر بخش‌ها قدیمی می‌شوند. هر مخزن، تعهدی از سوی شخص دیگری است که بسته‌ها را برای نسخه توزیع Ubuntu شما منتشر کند؛ ارتقای نسخه توزیع، تمام این تعهدات را در یک بعدازظهر به چالش می‌کشد.

• تنها زمانی یک مخزن شخص‌ثالث اضافه کنید که بسته‌های توزیع اصلی پاسخگوی نیاز شما نباشند. یک پشته LAMP روی Ubuntu 24.04 ساده به هیچ‌کدام نیاز ندارد: آرشیو Ubuntu تمام بسته‌های مورد نیاز را به همراه به‌روزرسانی‌های امنیتی برای کل طول عمر آن نسخه ارائه می‌دهد.
• کلیدها را در /etc/apt/keyrings/ نگهداری کنید؛ برای هر فروشنده یک فایل جداگانه با دسترسی 644 ایجاد کنید. کاربر غیرمجاز _apt وظیفه دانلود را بر عهده دارد و باید بتواند کلید را بخواند؛ بنابراین کلیدی که فقط توسط root قابل خواندن باشد، در هر بار دریافت از آن مخزن، خطای مجوز ایجاد می‌کند.
• در هر stanza، فایل Signed-By را دقیقاً به همان فایل کلید ارجاع دهید. کلیدی که در /etc/apt/trusted.gpg یا /etc/apt/trusted.gpg.d/ قرار دارد، برای تمام مخازن موجود در سیستم معتبر شناخته می‌شود؛ این یعنی کلید یک فروشنده که سال‌ها پیش اضافه شده، می‌تواند بسته‌های دریافتی از هر منبعی را تأیید کند.
• پیش از ارتقای نسخه توزیع، منابع خود را بررسی کنید و مطمئن شوید که هر فروشنده، بسته‌ها را برای نسخه‌ای که قصد مهاجرت به آن را دارید، منتشر کرده است.

کلیدی که در keyring سراسری قدیمی قرار دارد، در هر بار به‌روزرسانی این هشدار را نمایش می‌دهد:

W: https://download.docker.com/linux/ubuntu/dists/noble/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

آن کلید خاص را به یک فایل مجزا صادر کنید و سپس stanza مربوطه را به آن ارجاع دهید:

gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --export 7EA0A9C3F273FCD8 | sudo tee /etc/apt/keyrings/docker.gpg > /dev/null
sudo chmod 644 /etc/apt/keyrings/docker.gpg

عبارت Signed-By: /etc/apt/keyrings/docker.gpg را به stanza مخزن اضافه کرده و sudo apt update را اجرا کنید. هنگامی که هیچ مخزنی به keyring قدیمی وابسته نباشد، هشدار متوقف می‌شود و می‌توانید آن ورودی را با sudo gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --delete-key 7EA0A9C3F273FCD8 حذف کنید.

یک عادت دیگر بیشترین دردسر را کاهش می‌دهد. do-release-upgrade منابع شخص‌ثالث را برای ارتقا غیرفعال می‌کند و پس از آن نیز آن‌ها را خاموش نگه می‌دارد؛ فعال‌سازی دستی و تک‌به‌تک آن‌ها دقیقاً همان نقطه‌ای است که باعث ایجاد تعاریف تکراری می‌شود. پیش از شروع، راهنمای ارتقای Ubuntu 24.04 به 26.04 را مطالعه کنید و یادداشت کنید که به کدام مخازن همچنان نیاز دارید. در ماشینی که به‌تازگی راه‌اندازی کرده‌اید، بهترین زمان برای تنظیم صحیح منابع، ده دقیقه اول در یک VPS جدید است، یعنی زمانی که تنها ورودی‌های موجود در سیستم، همان‌هایی هستند که Ubuntu به‌صورت پیش‌فرض ارائه داده است.

FAQ

چرا apt می‌گوید یک هدف چندین بار پیکربندی شده است؟

زیرا دو فایل در /etc/apt/sources.list.d/ یک مخزن، suite و component یکسان را تعریف کرده‌اند. این پیام هر دو فایل را به همراه شماره خط، مانند docker.list:1 و docker.sources:1، مشخص می‌کند. apt آن‌ها را ادغام کرده و به کار خود ادامه می‌دهد، بنابراین عملیات به‌روزرسانی همچنان انجام می‌شود. با این حال، بهتر است این مورد تکراری را پاک کنید: به محض اینکه دو فایل، کلیدهای امضای متفاوتی را معرفی کنند، apt با خطای E: Conflicting values set for option Signed-By متوقف شده و از خواندن هرگونه منبعی خودداری می‌کند، که این امر باعث مسدود شدن apt install نیز می‌شود.

آیا باید فایل .list را نگه دارم یا فایل .sources را؟

فایل .sources را نگه دارید. فرمت deb822 همان چیزی است که add-apt-repository در Ubuntu 24.04 و نسخه‌های جدیدتر می‌نویسد؛ این فرمت به‌جای متن موقعیتی در براکت، برای هر تنظیم یک فیلد نام‌گذاری‌شده دارد و مسیری است که توزیع‌ها به سمت آن حرکت می‌کنند. پیش از حذف فایل .list، با استفاده از ls -l /etc/apt/keyrings/ تأیید کنید که مسیر Signed-By در داخل فایل .sources به یک کلید موجود اشاره دارد. فایل قدیمی را از /etc/apt/sources.list.d/ خارج کنید و آن را داخل همان دایرکتوری تغییر نام ندهید، زیرا باقی ماندن فایلی با پسوند .bak باعث می‌شود apt در هر بار اجرا، یک اعلان مبنی بر نادیده گرفتن فایل چاپ کند.

چگونه می‌توانم یک مخزن apt را بدون حذف کردن، غیرفعال کنم؟

در یک فایل deb822 با پسوند .sources، عبارت Enabled: no را به stanza مربوطه اضافه کنید. در یک فایل تک‌خطی .list، یک # در ابتدای خط قرار دهید. در هر دو حالت، پس از آن sudo apt update را اجرا کنید تا بلوک Err: مربوط به آن مخزن ناپدید شود. این کار زمانی مناسب است که یک مخزن شخص ثالث هنوز بسته‌ای برای نسخه Ubuntu شما ندارد و خطای 404 آن باعث می‌شود apt update با کد خروجی غیر صفر متوقف شود.

آیا فرمت تک‌خطی sources.list در حال حذف شدن است؟

این فرمت منسوخ شده است، اما حذف نشده است. apt همچنان فایل‌های .list را می‌خواند و تا مدت‌ها این کار را ادامه خواهد داد، بنابراین هیچ‌چیز در سرور شما فردا از کار نخواهد افتاد. ابزارهای جدید از فرمت deb822 استفاده می‌کنند: Ubuntu 24.04 و نسخه‌های جدیدتر، مخازن توزیع را در /etc/apt/sources.list.d/ubuntu.sources نگه می‌دارند و add-apt-repository فایل‌های .sources را می‌نویسد. در apt 3.0 و نسخه‌های جدیدتر، sudo apt modernize-sources فایل‌هایی که همچنان دارید را تبدیل می‌کند.