رفع خطای تکراری بودن منابع در apt و deb822

خطای تکراری بودن منابع apt به چه معناست

تکراری بودن منابع apt به این معناست که یک مخزن (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 دو فایل کاملاً بی‌ارتباط هستند.

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

• اسکریپت نصب یک فروشنده، یا دستوری که از یک پست قدیمی کپی شده است، فایل /etc/apt/sources.list.d/vendor.list را با یک خط tee ایجاد می‌کند.
• بستهٔ نرم‌افزاری خودِ فروشنده در مراحل بعدی، فایل /etc/apt/sources.list.d/vendor.sources را منتشر کرده و آن را برای شما نصب می‌کند.
• ابزار add-apt-repository در Ubuntu 24.04 و نسخه‌های جدیدتر، فایل‌های deb822 با پسوند .sources می‌نویسد؛ بنابراین یک PPA (آرشیو بسته شخصی) که زمانی به‌صورت دستی با فرمت .list اضافه کرده بودید، اکنون به‌شکل .sources بازمی‌گردد.
• ارتقای نسخه توزیع، فایل‌های منبع خودِ سیستم‌عامل را به فرمت 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 و مجموعه 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 هیچ محتوایی برای آن نسخه (suite) منتشر نکرده است، بنابراین مسیر در سرور وجود ندارد و درخواست با خطای 404 مواجه می‌شود. سایر مخازن شما همچنان به‌روزرسانی می‌شوند و بسته‌هایی که از قبل دارید دست‌نخورده باقی می‌مانند. با این حال، اجرای دستور با کد خروجی غیرصفر پایان می‌یابد؛ بنابراین هر اسکریپتی که وضعیت خروجی apt update را بررسی کند، از این پس هر بار گزارش خطا می‌دهد. به همین دلیل است که پاک‌سازی یک منبع ازکارافتاده در سیستمی که ارتقاهای امنیتی خودکار روی آن تنظیم شده، ضروری است: هشدارهای روزانهٔ کاذب باعث می‌شوند خطاهای واقعی نادیده گرفته شوند. اسکریپت‌های نصب فروشندگان اغلب با هر دو نسخهٔ این مشکل مواجه می‌شوند؛ به همین دلیل است که اکثر خطاهای نصب Tailscale در Ubuntu ناشی از نبود keyring که اسکریپت باید می‌نوشت، یا نام رمز (codename) نسخه‌ای است که در آرشیو وجود ندارد.

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

برای یک فایل با فرمت 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 می‌گوید یک هدف (target) چندین بار پیکربندی شده است؟

زیرا دو فایل در مسیر /etc/apt/sources.list.d/ یک مخزن (repository)، توزیع (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 را به بخش مربوطه اضافه کنید. در یک فایل یک‌خطی .list، یک علامت # در ابتدای خط قرار دهید. در هر دو حالت، پس از آن sudo apt update را اجرا کنید تا بلوک Err: مربوط به آن مخزن ناپدید شود. این کار زمانی مناسب است که یک مخزن شخص ثالث هنوز بسته‌ای برای نسخه Ubuntu شما ارائه نکرده و خطای 404 آن باعث می‌شود apt update با کد خروجی غیر صفر متوقف شود.

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

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