Duplicate apt sources error को कैसे ठीक करें

Duplicate apt sources error का क्या अर्थ है

Duplicate apt sources का अर्थ है कि एक ही repository को दो अलग-अलग फाइलों में घोषित किया गया है, और APT (advanced package tool) को दोनों प्रतियां मिल गई हैं। Ubuntu 24.04 और उसके बाद के संस्करणों पर, यह लगभग हमेशा इसलिए होता है क्योंकि किसी थर्ड-पार्टी इंस्टॉलेशन स्क्रिप्ट ने एक पुरानी एक-लाइन वाली .list फाइल लिखी है, जबकि उसी repository के लिए एक deb822 .sources फाइल पहले से ही डिस्क पर मौजूद थी। कुछ भी corrupt नहीं है और कोई भी पैकेज खतरे में नहीं है। दो घोषणाओं में से एक को हटा दें और संदेश गायब हो जाएगा।

यह वह लाइन है जिसे लोग सर्च बॉक्स में पेस्ट करते हैं:

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 यह जानने के लिए डाउनलोड करता है कि कोई repository कौन से पैकेज प्रदान करती है, और stable/binary-amd64/Packages उस घटक (stable) और आर्किटेक्चर (amd64) का नाम बताता है जिसे वह इंडेक्स कवर करता है। इसलिए apt आपको बता रहा है कि stable घटक के लिए amd64 इंडेक्स docker.list में लाइन 1 पर कॉन्फ़िगर किया गया है, और फिर से docker.sources में लाइन 1 पर।

apt 3.0 और उसके बाद के संस्करणों पर, जिसका अर्थ है Ubuntu 25.04 और उसके बाद, और Debian 13, वही संदेश W: के बजाय Warning: से शुरू होता है। प्रीफिक्स के बाद का टेक्स्ट समान है।

वह चेतावनी एक हल्का मामला है। apt दोनों घोषणाओं को मर्ज कर देता है और अपडेट अभी भी चलता है, क्योंकि दोनों एक ही की (key) के साथ एक ही आर्काइव का वर्णन करते हैं। कठिन मामला सब कुछ रोक देता है:

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 यहाँ मना कर देता है क्योंकि दो घोषणाएं एक ही आर्काइव के लिए अलग-अलग साइनिंग की (signing keys) का नाम बताती हैं। यह दो समान घोषणाओं को मर्ज कर देगा, लेकिन यह दो Signed-By मानों के बीच चयन नहीं करेगा, क्योंकि गलत को चुनने का मतलब है कि पैकेज हस्ताक्षरों की जांच ऐसी की (key) के खिलाफ करना जिसके साथ आर्काइव मालिक ने कभी साइन नहीं किया था। इसलिए apt कोई भी सोर्स नहीं पढ़ता है। apt update और apt install दोनों ही उन दो लाइनों के साथ विफल हो जाते हैं जब तक कि आप फाइलों को मैन्युअल रूप से संपादित नहीं करते।

डुप्लिकेट वहां कैसे पहुंचता है

ये दोनों फॉर्मेट अलग-अलग एक्सटेंशन वाली फाइलों में मौजूद होते हैं, इसलिए डिस्क पर ऐसा कुछ नहीं है जो दोनों को एक साथ रहने से रोके। apt को इस ओवरलैप का पता तब चलता है जब वह हर सोर्स फाइल को उन इंडेक्स टारगेट्स की सूची में विस्तारित करता है जिन्हें वह फेच (fetch) करने की योजना बनाता है। उस क्षण तक docker.list और docker.sources दो असंबंधित फाइलें होती हैं।

चार सामान्य घटनाएं इस जोड़ी को उत्पन्न करती हैं:

• एक वेंडर इंस्टॉल स्क्रिप्ट, या किसी पुराने पोस्ट से कॉपी की गई कमांड, /etc/apt/sources.list.d/vendor.list को एक tee लाइन के साथ लिखती है।
• वेंडर का अपना पैकेज बाद में /etc/apt/sources.list.d/vendor.sources को शिप (ship) करता है और उसे आपके लिए इंस्टॉल कर देता है।
• Ubuntu 24.04 और उसके बाद के वर्ज़न पर add-apt-repository, deb822 .sources फाइलें लिखता है, इसलिए एक PPA (personal package archive) जिसे आपने कभी हाथ से .list के रूप में जोड़ा था, वह .sources के रूप में वापस आ जाता है।
• एक रिलीज अपग्रेड ने डिस्ट्रीब्यूशन के अपने सोर्सेज को deb822 में फिर से लिखा और आपकी हाथ से लिखी गई .list फाइल को उनके बगल में बिना छुए छोड़ दिया।

प्रत्येक पाथ अपने आप में तर्कसंगत है। डुप्लिकेट तब बनता है जब इनमें से दो घटनाएं एक ही बॉक्स पर होती हैं, जो अक्सर महीनों के अंतराल पर होती हैं।

दो प्रारूप, साथ-साथ

पुराना प्रारूप प्रति रिपॉजिटरी एक लाइन का है, और इसका प्रत्येक भाग स्थिति-आधारित (positional) है।

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

क्रम निश्चित है: प्रकार (binary packages के लिए deb, source packages के लिए deb-src), फिर square brackets में विकल्प, फिर आर्काइव का URI (uniform resource identifier), फिर suite, और अंत में एक या अधिक components। चूंकि अर्थ स्थिति से निर्धारित होता है, इसलिए गलत जगह पर एक space होने से apt द्वारा पढ़ा जाने वाला अर्थ बदल जाता है।

deb822 इन्हीं बातों को named fields के एक stanza के रूप में प्रस्तुत करता है। इसका नाम RFC 822 से आया है, जो कि mail header की वह शैली है जिसे Debian पहले से ही package control files के लिए उपयोग करता है।

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

वही रिपॉजिटरी, वही key, कुछ भी नया नहीं जोड़ा गया। मैपिंग सीधी है: deb बदलकर Types हो जाता है, आर्काइव का पता URIs बन जाता है, suite Suites बन जाता है, components Components बन जाते हैं, और प्रत्येक bracket विकल्प अपना एक अलग field बन जाता है, इसलिए signed-by= बदलकर Signed-By: हो जाता है और arch= बदलकर Architectures: हो जाता है।

प्रत्येक field का नाम plural है क्योंकि हर field space से अलग की गई सूची (list) स्वीकार करता है। एक stanza में Suites: noble noble-updates noble-backports तीन अलग-अलग deb लाइनों की जगह ले लेता है। एक खाली लाइन stanza को समाप्त करती है, इसलिए एक ही .sources फाइल में कई रिपॉजिटरी हो सकती हैं। deb822 उन सेटिंग्स को भी संभालता है जिन्हें एक लाइन वाला प्रारूप ठीक से नहीं कर पाता: रिपॉजिटरी को बंद करने के लिए Enabled: no, Trusted, Check-Valid-Until, और एक inline key जिसे सीधे Signed-By में पेस्ट किया जा सकता है, जिसमें प्रत्येक लाइन एक space से indented होती है और खाली लाइनों को एक dot के रूप में लिखा जाता है।

प्रत्येक फ़ाइल कहाँ स्थित है

• /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/: जहाँ आपके द्वारा जोड़ी गई कुंजियाँ (keys) रहती हैं। /usr/share/keyrings/ में वे कुंजियाँ होती हैं जो किसी पैकेज के साथ आती हैं।

apt केवल उन फ़ाइलों को पढ़ता है जो .list या .sources पर समाप्त होती हैं, और फ़ाइल नाम में अक्षर, अंक, अंडरस्कोर, हाइफ़न और पीरियड हो सकते हैं। किसी अन्य एक्सटेंशन वाली फ़ाइल को एक सूचना के साथ छोड़ दिया जाता है, जो नीचे दिए गए सुधार के लिए महत्वपूर्ण है।

डुप्लिकेट जोड़े का पता लगाएँ

Directory listing से शुरुआत करें:

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

एक ही stem और अलग extensions वाली दो फाइलें सामान्य जोड़ा होती हैं, लेकिन नामों पर भरोसा न करें। सामग्री पढ़ें, क्योंकि एक डुप्लिकेट किसी भी नाम की फाइल में छिपा हो सकता है:

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

यह जोड़ा वे दो entries हैं जिनमें एक ही host और एक ही suite है। दोनों https://download.docker.com/linux/ubuntu और suite noble की ओर संकेत करती हैं, इसलिए वे एक ही repository हैं जिसे दो बार लिखा गया है। उनके Signed-By paths भी अलग हैं, जो पहले दिखाए गए Conflicting values error का कारण बनते हैं।

इस चरण के लिए apt command के बजाय grep का उपयोग करें। जब apt पहले से ही conflict के कारण रुक रहा हो, तो वह आपकी sources की सूची भी नहीं दिखा सकता, इसलिए apt-cache policy आपके द्वारा चाहा गया उत्तर देने के बजाय वही error print करता है।

समस्या ठीक करें: deb822 फ़ाइल रखें, पुरानी फ़ाइल हटाएँ

.sources फ़ाइल को रखें। यह वह प्रारूप है जिसमें apt टूलिंग अब लिखती है, और यही वह दिशा है जिसमें Debian और Ubuntu दोनों आगे बढ़ रहे हैं। कुछ भी हटाने से पहले, जाँचें कि डिस्क पर इन दो key paths में से कौन सा मौजूद है:

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 फ़ाइल एक ऐसी key की ओर इशारा करती है जिसे हटा दिया गया है। यदि आपको पता चलता है कि जिस फ़ाइल को आप रखना चाहते हैं, उसमें गायब key का नाम है, तो पहले उसमें सही वर्किंग पाथ कॉपी करें, फिर दूसरी फ़ाइल हटा दें।

पुरानी फ़ाइल को सीधे हटाने के बजाय उसे डायरेक्टरी से बाहर ले जाएँ:

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 फ़ाइल को हटा सकते हैं। एक नियम इसे किसी भी तरह से तय करता है: किसी दिए गए आर्काइव और सूट को केवल एक ही फ़ाइल घोषित कर सकती है।

एक खराब third-party source के कारण apt update क्यों रुक जाता है

पड़ोसी विफलता अलग दिखती है लेकिन इसका मूल कारण वही है, एक ऐसा third-party source जिसे apt उपयोग नहीं कर सकता। पहला संस्करण एक missing key है:

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 फ़ील्ड गायब है, या यह ऐसी फ़ाइल की ओर इशारा करता है जो उपयोग करने योग्य key नहीं है, इसलिए apt आर्काइव की InRelease फ़ाइल पर हस्ताक्षर (signature) को सत्यापित नहीं कर सकता। इसके बाद यह पूरे रिपॉजिटरी को हटा देता है बजाय इसके कि उन पैकेज सूचियों पर भरोसा करे जिन्हें वह जांच नहीं सकता। स्वयं key फ़ाइल को देखें:

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

एक कार्यशील key एक pub लाइन को key id के साथ और एक uid लाइन को वेंडर के नाम के साथ प्रिंट करती है। gpg: no valid OpenPGP data found. का अर्थ है कि फ़ाइल बिल्कुल भी key नहीं है, जिसका आमतौर पर मतलब है कि डाउनलोड ने एक त्रुटि पृष्ठ (error page) सहेजा है क्योंकि key URL बदल गया है। key को फिर से प्राप्त करें, फ़ाइल की जाँच करें, और फिर 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 के लिए कुछ भी प्रकाशित नहीं किया है, इसलिए सर्वर पर वह path मौजूद नहीं है और अनुरोध 404 लौटाता है। आपके अन्य रिपॉजिटरी अभी भी अपडेट होते हैं, और आपके पास पहले से मौजूद पैकेज अप्रभावित रहते हैं। हालाँकि, रन non-zero पर समाप्त होता है, इसलिए कोई भी स्क्रिप्ट जो apt update की exit status की जाँच करती है, अब हर बार चलने पर विफलता की रिपोर्ट करती है। यही कारण है कि unattended security upgrades कॉन्फ़िगर किए गए बॉक्स पर एक मृत स्रोत को हटाना उचित है: दैनिक शोर (noise) में ही वास्तविक विफलता छिपी होती है। वेंडर इंस्टॉल स्क्रिप्ट इन दोनों संस्करणों का सामना करती हैं, यही कारण है कि अधिकांश Tailscale install errors on Ubuntu एक ऐसे keyring के रूप में सामने आते हैं जिसे स्क्रिप्ट ने कभी नहीं लिखा या एक ऐसा release codename जिसे आर्काइव में नहीं रखा गया है।

बाकी को प्रभावित किए बिना एक source को disable करना

deb822 फ़ाइल के लिए, stanza में एक फ़ील्ड जोड़ें और उसे save करें:

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 manual stanza की प्रत्येक लाइन को comment करने के बजाय इस तरीके की अनुशंसा करता है, और इसे undo करना भी आसान है। एक लाइन वाली फ़ाइल के लिए, लाइन की शुरुआत में # लगाएँ। दोनों प्रारूपों के लिए, फ़ाइल को /etc/apt/sources.list.d/ से बाहर ले जाना भी काम करता है, और जब repository हमेशा के लिए हटानी हो तो यही विकल्प चुनें।

sudo apt update को फिर से चलाएँ। उस repository के लिए Err: ब्लॉक गायब हो जाता है, और exit status 0 पर वापस आ जाता है, जिसे आप अगली लाइन पर echo $? के साथ जाँच सकते हैं।

कभी भी किसी टूटे हुए source को sudo rm /etc/apt/sources.list.d/* से ठीक न करें। Ubuntu 24.04 और उसके बाद के वर्ज़न पर यह ubuntu.sources को हटा देता है, जिसमें distribution की अपनी repositories होती हैं, इसलिए apt के पास कोई package list नहीं बचती और वह उन software के लिए 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 के रूप में save करें, जिसमें noble की जगह lsb_release -cs से अपने release का नाम लिखें, और फिर sudo apt update चलाएँ।

Legacy .list फाइलों को deb822 में बदलें

अगस्त 2026 से, apt 3.0 और उसके बाद के वर्ज़न में इसके लिए एक कनवर्टर उपलब्ध है। 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 फाइलें होती हैं, उसमें इस प्रकार की डुप्लीकेट फाइलें नहीं बढ़ सकतीं।

सर्वर पर third-party sources को व्यवस्थित रखें

Third-party repositories सर्वर का वह हिस्सा हैं जो सबसे जल्दी पुराने पड़ते हैं। प्रत्येक repository किसी और का यह वादा है कि वे आपके Ubuntu release के लिए software publish करते रहेंगे, और एक release upgrade उसी दोपहर उन सभी वादों की परीक्षा ले लेता है।

• Third-party repository तभी जोड़ें जब distribution package से काम न चल रहा हो। एक साधारण LAMP stack on Ubuntu 24.04 को किसी अतिरिक्त repository की आवश्यकता नहीं होती: Ubuntu archive में वे सभी packages मौजूद होते हैं, जिन्हें release के पूरे जीवनकाल के लिए security updates मिलते हैं।
• Keys को /etc/apt/keyrings/ में रखें, प्रति vendor एक file, mode 644 के साथ। Unprivileged _apt user ही downloading करता है और उसे key पढ़नी होती है, इसलिए केवल root द्वारा पढ़ी जा सकने वाली key file हर बार repository से fetch करते समय permission error देगी।
• हर stanza में Signed-By को उसी विशिष्ट file पर point करें। /etc/apt/trusted.gpg या /etc/apt/trusted.gpg.d/ में रखी गई key को सर्वर की हर repository के लिए trusted माना जाता है, जिसका अर्थ है कि वर्षों पहले जोड़ी गई कोई vendor key कहीं से भी आए packages को validate कर सकती है।
• Release upgrade से पहले, अपनी sources को पढ़ें और जाँचें कि क्या प्रत्येक vendor उस suite के लिए packages publish कर रहा है जिस पर आप move कर रहे हैं।

पुरानी global keyring में मौजूद एक key हर update पर खुद को सूचित करती है:

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.

उस एक key को उसकी अपनी file में export करें, फिर stanza को उस पर point करें:

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

Repository के stanza में Signed-By: /etc/apt/keyrings/docker.gpg जोड़ें और sudo apt update चलाएँ। जब कोई भी repository पुरानी keyring पर निर्भर नहीं रहेगी, तो चेतावनी बंद हो जाएगी, और तब आप sudo gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --delete-key 7EA0A9C3F273FCD8 के साथ उस entry को हटा सकते हैं।

एक और आदत सबसे अधिक परेशानी से बचाती है। do-release-upgrade upgrade के लिए third-party sources को disable कर देता है और बाद में उन्हें बंद ही रहने देता है, और उन्हें एक-एक करके हाथ से वापस चालू करना ही वह जगह है जहाँ duplicate declarations बन जाते हैं। शुरू करने से पहले the Ubuntu 24.04 to 26.04 upgrade guide पढ़ें, और लिख लें कि आपको किन repositories की अभी भी आवश्यकता है। जिस machine को आपने अभी-अभी तैयार किया है, उस पर sources को सही करने का सबसे सस्ता समय the first ten minutes on a new VPS के दौरान होता है, जब box पर केवल वही entries होती हैं जो Ubuntu के साथ आई थीं।

FAQ

apt यह क्यों कहता है कि कोई target कई बार कॉन्फ़िगर किया गया है?

ऐसा इसलिए होता है क्योंकि /etc/apt/sources.list.d/ के अंतर्गत दो फाइलें एक ही रिपॉजिटरी, सुइट और कंपोनेंट को घोषित करती हैं। यह संदेश दोनों फाइलों के नाम और लाइन नंबर बताता है, जैसे कि docker.list:1 और docker.sources:1। apt इन्हें मर्ज कर देता है और अपना काम जारी रखता है, इसलिए अपडेट की प्रक्रिया काम करती रहती है। फिर भी, इस डुप्लीकेट को हटा देना बेहतर है: जैसे ही ये दो फाइलें अलग-अलग साइनिंग की (signing keys) का नाम लेंगी, apt E: Conflicting values set for option Signed-By के साथ रुक जाएगा और किसी भी सोर्स को पढ़ने से मना कर देगा, जिससे apt install भी ब्लॉक हो जाएगा।

क्या मुझे .list फाइल रखनी चाहिए या .sources फाइल?

.sources फाइल को रखें। deb822 वह फॉर्मेट है जिसे Ubuntu 24.04 और उसके बाद के वर्ज़न पर add-apt-repository लिखता है। इसमें स्क्वायर ब्रैकेट में पोजीशनल टेक्स्ट के बजाय प्रत्येक सेटिंग के लिए एक नामित फील्ड (named field) होता है, और यही भविष्य की दिशा है। .list फाइल को डिलीट करने से पहले, यह पुष्टि कर लें कि .sources फाइल के अंदर का Signed-By पाथ एक ऐसी की (key) की ओर इशारा करता है जो मौजूद है, इसके लिए ls -l /etc/apt/keyrings/ का उपयोग करें। पुरानी फाइल को डायरेक्टरी के अंदर रीनेम करने के बजाय उसे /etc/apt/sources.list.d/ से बाहर ले जाएं, क्योंकि वहां बची हुई कोई भी .bak फाइल apt को हर रन पर एक 'ignored-file' नोटिस प्रिंट करने के लिए मजबूर करती है।

मैं किसी apt रिपॉजिटरी को हटाए बिना उसे बंद कैसे करूँ?

deb822 .sources फाइल में, स्टैन्ज़ा (stanza) में 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 उन फाइलों को कन्वर्ट कर देता है जो आपके पास अभी भी हैं।