Ubuntu LTS की Interim Release: सर्व्हरसाठी काय निवडावे?

Ubuntu LTS आणि interim releases मधील फरक: थोडक्यात उत्तर

सर्व्हरसाठी Ubuntu LTS आणि interim release यांपैकी कशाची निवड करायची, हे एकाच गोष्टीवर अवलंबून असते: त्या रिलीजला किती काळ सुरक्षा अपडेट्स मिळतील. LTS ला पाच वर्षांची मानक सुरक्षा देखभाल मिळते. interim release ला नऊ महिने मिळतात आणि त्यानंतर अपडेट्स बंद होतात, त्यामुळे तुम्हाला अपग्रेड करावे लागते किंवा सर्व्हर पुन्हा तयार करावा लागतो. ज्या सेवांवर इतर लोक अवलंबून आहेत, तिथे नेहमी LTS वापरा. interim release फक्त अशा ठिकाणी वापरा जिथे सर्व्हर पुन्हा तयार करणे कोणाचीही परवानगी न घेता शक्य असेल.

LTS म्हणजे long term support. Canonical दर दोन वर्षांनी, सम वर्षांच्या एप्रिल महिन्यात एक LTS रिलीज करते आणि त्या दरम्यान दर सहा महिन्यांनी एक interim release प्रसिद्ध करते. 26.04 LTS हे 23 एप्रिल 2026 रोजी रिलीज झाले आणि त्याची मानक सुरक्षा देखभाल 2031 पर्यंत सुरू राहील. 26.10 हे 15 ऑक्टोबर 2026 रोजी अपेक्षित आहे आणि ते एक interim release असल्याने, त्याची मुदत जुलै 2027 मध्ये संपेल.

प्रत्येक Ubuntu रिलीजला किती कालावधीसाठी सपोर्ट मिळतो

[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

हे आकडे ऑगस्ट 2026 पर्यंत Canonical ने जाहीर केलेली अधिकृत धोरणे आहेत, कोणत्याही टेस्ट बॉक्सवरून घेतलेली मोजमापे नाहीत. एका LTS ला 60 महिने स्टँडर्ड सुरक्षा मेंटेनन्स मिळतो, ज्याचा अर्थ पाच वर्षांत 1 नियोजित रिलीज अपग्रेड्स असा होतो. एका इंटरिम (interim) रिलीजला 9 महिने सपोर्ट मिळतो. त्याच पाच वर्षांच्या कालावधीत इंटरिम ट्रॅकवर राहिल्यास 10 रिलीज अपग्रेड्स करावे लागतात, कारण तुम्ही एखादे रिलीज वगळू शकत नाही आणि पाच वर्षांच्या कालावधीत दहा रिलीज येतात.

Ubuntu Pro सबस्क्रिप्शनमुळे LTS चा कालावधी वाढून 120 महिने, म्हणजेच दहा वर्षे होतो आणि कव्हरेज केवळ main घटकापुरते मर्यादित न राहता संपूर्ण आर्काइव्हसाठी उपलब्ध होते. ऑगस्ट 2026 पर्यंत, वैयक्तिक वापरासाठी पाच मशीनपर्यंत Pro मोफत आहे, जे बहुतेक लहान VPS फ्लीट्ससाठी पुरेसे आहे. इंटरिम रिलीजसाठी अशी कोणतीही सुविधा उपलब्ध नाही. नऊ महिने हाच संपूर्ण कालावधी आहे आणि कोणतेही सबस्क्रिप्शन तो वाढवू शकत नाही.

एका रिअल सर्व्हरवर नऊ महिन्यांच्या देखभालीचा खर्च

26.10 हे उदाहरण म्हणून घेऊ. हे 15 ऑक्टोबर 2026 रोजी रिलीज होते आणि याची सुरक्षा देखभाल जुलै 2027 मध्ये संपते. हाच नऊ महिन्यांचा पॅटर्न 25.10 साठी जुलै 2026 मध्ये संपला होता. कॅलेंडरनुसार पाहिले तर, हे दर तीन तिमाहीत एकदा देखभाल विंडो असल्यासारखे वाटते. परंतु, कॅलेंडरचे हे वाचन चुकीचे आहे आणि ते महागड्या दिशेने चुकीचे आहे.

रिलीज अपग्रेड ऑपरेटिंग सिस्टमला आहे तसे बदलून टाकते. do-release-upgrade हे apt सोर्सेस पुन्हा लिहिते, थर्ड-पार्टी रिपॉझिटरीज डिसेबल करते, जवळजवळ सर्व इन्स्टॉल केलेल्या पॅकेजेसची आवृत्ती बदलते, तुम्ही एडिट केलेल्या कॉन्फिगरेशन फाइल्सबद्दल विचारण्यासाठी थांबते आणि शेवटी रीबूट करते. म्हणूनच ही एक नियोजित विंडो असते, बॅकग्राउंड जॉब नाही.

हे ssh वर चालवताना, टूल तुम्हाला तुमचे कनेक्शन तुटण्यापासून वाचवते. ते स्वतःचे screen सेशन सुरू करते आणि दुसरे sshd उघडते, ज्याची माहिती ते तुम्हाला आधीच देते:

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.

त्याला तसे करू द्या. जर तुमच्या फायरवॉलने किंवा तुमच्या प्रोव्हायडरच्या स्वतंत्र नेटवर्क फायरवॉलने 1022 पोर्ट ब्लॉक केले असेल, तर तो फॉलबॅक अस्तित्वात नसतो. अशा वेळी कनेक्शन तुटल्यास पॅकेज सेट अर्धवट अपग्रेड झालेला राहतो. tmux किंवा screen मध्ये स्वतः काम केल्यास तुम्हाला कोणत्याही बॉक्सवर हेच संरक्षण मिळते.

कॉन्फिगरेशन फाइलचे प्रॉम्प्ट्स पंधरा मिनिटांचे अपग्रेड एका तासाचे बनवतात:

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

तुमची फाइल ठेवल्यास, नवीन डिफॉल्टमध्ये काय बदलले आहे ते तुम्हाला समजत नाही. मेंटेनर्सची फाइल स्वीकारल्यास, तुम्ही केलेले हार्डनिंग पुन्हा करेपर्यंत निघून जाते. त्या रिलीजमध्ये नक्की काय बदलले आहे हे माहीत असल्याशिवाय दोन्ही उत्तरे सुरक्षित नाहीत. म्हणूनच रिलीज नोट्स वाचणे हा या विंडोचा भाग आहे, ऐच्छिक गृहपाठ नाही.

आता हे सर्व्हरच्या संख्येनुसार गुणा. इंटरिम ट्रॅकवर असलेला एक VPS पाच वर्षांत दहा अपग्रेड विंडोज घेतो. पाच VPS बॉक्स असतील तर ही संख्या पन्नास होते, जोपर्यंत प्रत्येक बॉक्स डिस्पोजेबल नसेल आणि इमेजवरून पुन्हा तयार केला जात नसेल. LTS ट्रॅकवर असलेले पाच बॉक्स त्याच कालावधीत पाच अपग्रेड घेतात आणि प्रत्येक अपग्रेड कोणत्या महिन्यात करायचा हे तुम्ही ठरवू शकता.

तुम्ही Ubuntu चे एखादे रिलीज का वगळू शकत नाही

अपग्रेडचे मार्ग निश्चित असतात. एक इंटरिम रिलीज त्याच्या पुढील रिलीजवरच अपग्रेड होते, मग ते कोणतेही असो. एक LTS थेट पुढील LTS वर किंवा तुमच्या सूचनेनुसार पुढील इंटरिम रिलीजवर अपग्रेड होऊ शकते. कोणतीही गोष्ट एकाच वेळी दोन टप्पे ओलांडून अपग्रेड होत नाही. 26.10 वरून 28.04 LTS वर जाण्यासाठी तुम्हाला 27.04 आणि 27.10 मधून जावे लागेल, किंवा मशीन पुन्हा इन्स्टॉल करावे लागेल.

ही यंत्रणा समजून घेणे महत्त्वाचे आहे, कारण ती स्पष्ट करते की नियम बदलता येत नाहीत. do-release-upgrade हे changelogs.ubuntu.com वरून एक meta-release फाईल मिळवते आणि त्यानंतर एका विशिष्ट संक्रमणासाठी (transition) तयार केलेले अपग्रेड टूल डाउनलोड करते. Canonical एका वेळी एकच संक्रमण तयार करते आणि त्याची चाचणी घेते, त्यामुळे एखादे रिलीज वगळून थेट पुढे जाण्यासाठी कोणतेही टूल किंवा चाचणी उपलब्ध नसते. अपग्रेडर सावधगिरी म्हणून नकार देत नाही, तर त्याच्याकडे ऑफर करण्यासाठी काहीही नसते.

तुम्हाला कोणते रिलीज ऑफर केले जाईल, हे कॉन्फिगरेशनच्या एका ओळीवरून ठरते:

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts फक्त पुढील LTS ऑफर करते. Prompt=normal पुढील रिलीज ऑफर करते, मग ते LTS असो वा नसो. Prompt=never काहीही ऑफर करत नाही; तुमच्या नियोजनाशिवाय एखाद्या सहकाऱ्याने अपग्रेड सुरू करू नये म्हणून हे उपयुक्त ठरते. LTS नसलेल्या रिलीजवर, lts हे अगदी normal प्रमाणेच काम करते, कारण 26.10 नंतरचे पुढील रिलीज 27.04 हे दोन्ही सेटिंग्जमध्ये सारखेच असते. तपासणी दरम्यान Checking for a new Ubuntu release प्रिंट होते आणि त्यानंतर एकतर New release ... available. किंवा No new release found. ही ओळ दिसते.

नियोजनाचा आणखी एक नियम वापरकर्त्यांना गोंधळात टाकतो. नवीन LTS रिलीज झाल्याच्या दिवशीच LTS ते LTS अपग्रेड ऑफर केले जात नाही. हे पहिल्या पॉइंट रिलीजसह सुरू होते आणि 26.04.1 हे 27 ऑगस्ट 2026 साठी नियोजित आहे. पॉइंट रिलीज म्हणजे Ubuntu ची नवीन आवृत्ती नसते, तर चार महिन्यांच्या सुधारणांसह एकत्रित केलेले तेच रिलीज असते जे नवीन इन्स्टॉल मीडियामध्ये समाविष्ट केले जाते. हा प्रतीक्षा कालावधी यासाठी असतो की अपग्रेड मार्गाला कोणालाही ऑफर करण्यापूर्वी चार महिन्यांची चाचणी मिळावी. 2026 च्या उन्हाळ्यात Prompt=lts असलेले 24.04 चे मशीन जर No new release found. असे उत्तर देत असेल, तर ते खराब झालेले नसते. ते धोरणाचे पालन करत असते. जेव्हा मार्ग खुला होतो, तेव्हा 24.04 ते 26.04 LTS अपग्रेड हे नियोजित आणि सराव करण्यासाठी योग्य असते.

इंटरिम रिलीज कधी योग्य निवड असते

अशी चार प्रकरणे जिथे हे खरोखर फायदेशीर ठरते:

• तुम्हाला अशा कर्नल किंवा userspace आवृत्तीची गरज आहे जी LTS आर्काइव्हमध्ये उपलब्ध नाही आणि ती तुम्हाला या सर्व्हरवर त्वरित हवी आहे.
• जर ती मशीन build host, CI runner किंवा test box असेल, ज्याला तुम्ही इमेजवरून पुन्हा तयार करता, तर अपग्रेड म्हणजे मेंटेनन्स विंडोऐवजी एक नवीन इन्स्टन्स तयार करणे असते.
• हार्डवेअर किंवा हायपरवायझरचे एखादे फिचर LTS फ्रीझ झाल्यानंतर आले असेल आणि त्यासाठी कोणतेही backport उपलब्ध नसेल.
• तुम्ही पुढील LTS मध्ये काय असेल हे तपासत असाल. 28.04 हे 26.10, 27.04 आणि 27.10 पासून बनवले जाते. महत्त्वाच्या सर्व्हरवर समस्या शोधण्यापेक्षा एका अतिरिक्त VPS वर 'breaking change' शोधणे स्वस्त पडते.

जे लोक इंटरिम रिलीजकडे वळतात, त्यातील बहुतेकांना केवळ एक नवीन पॅकेज हवे असते, संपूर्ण डिस्ट्रिब्युशन नको असते. यासाठी दोन स्वस्त पर्याय उपलब्ध आहेत. हार्डवेअर इनेबलमेंट स्टॅक (HSE) नंतरच्या रिलीजमधील कर्नल LTS मध्ये आणतो: 24.04 वर हे sudo apt install linux-generic-hwe-24.04 आहे आणि ते प्रत्येक पॉइंट रिलीजच्या वेळी पुढे सरकते, ज्याची सुरुवात दुसऱ्या पॉइंट रिलीजपासून होते. केवळ एका ॲप्लिकेशनसाठी, कंटेनर इमेज किंवा व्हेंडरची स्वतःची रिपॉझिटरी वापरणे हे संपूर्ण ऑपरेटिंग सिस्टम बदलण्यापेक्षा अधिक सोयीचे असते.

जेव्हा interim release निवडणे चुकीचे असते

• ज्या प्रणालीवर पैसे देणारे वापरकर्ते आहेत किंवा on-call rotation आहे. तुम्ही वर्षातून दोनदा अनिवार्य अपग्रेड स्वीकारत असता, अशा पॅकेज व्हर्जन्सच्या बदल्यात ज्यांची तुम्हाला कदाचित कधीच गरज पडणार नाही.
• अशी कोणतीही सिस्टिम जिथे unattended-upgrades तुमच्यासाठी सुरक्षा पॅचिंग करत आहे. ती ऑटोमेशन केवळ त्या सुरक्षा रिपॉझिटरीवर अवलंबून असते ज्यातून ते पॅचेस खेचले जातात.
• अशी सर्व्हर्सची फ्लीट जी तुम्ही हाताने अपग्रेड करता, कारण याचा खरा खर्च एका मेंटेनन्स विंडोचा वेळ आणि सर्व्हर्सची संख्या यांचा गुणाकार असतो.
• अशी कोणतीही गोष्ट जी तुम्ही एकदा इन्स्टॉल करता आणि वर्षभर पुन्हा पाहत नाही. तुम्ही विसरलेले interim release नऊ महिन्यांनंतर एक विना-पॅच केलेले, इंटरनेटला उघडे असलेले सर्व्हर बनते.

हा शेवटचा प्रकारचा बिघाड शांत असतो, जो त्याला धोकादायक बनवतो. जेव्हा एखादे रिलीज end of life ला पोहोचते, तेव्हा त्याची पॅकेजेस old-releases.ubuntu.com वर हलवली जातात, त्यामुळे sudo apt update हे archive.ubuntu.com विरुद्ध 404 एरर्स दाखवून अपयशी ठरू लागते. डिस्कवरील पॅकेज लिस्ट जुन्या होतात. unattended-upgrades त्याच्या टायमरवर चालू राहते आणि /var/log/unattended-upgrades/unattended-upgrades.log मध्ये अशा ओळी लिहित राहते:

No packages found that can be upgraded unattended and no pending auto-removals

ही ओळ पूर्णपणे पॅच केलेल्या सर्व्हरवर आणि ज्या रिलीजची मुदत चार महिन्यांपूर्वी संपली आहे अशा सर्व्हरवर सारखीच दिसते. जोपर्यंत कोणी apt एरर्स वाचत नाही किंवा end of life ची तारीख ट्रॅक करत नाही, तोपर्यंत मशीनवर अशी कोणतीही गोष्ट नसते जी तुम्हाला सांगेल की तुम्ही नक्की कशाकडे पाहत आहात.

ज्या प्रकारचे बदल सर्वप्रथम अंतरिम (interim) ट्रॅकवर येतात

मार्च 2026 मध्ये, एका Canonical इंजिनिअरने Ubuntu discourse वर 26.10 मध्ये secure boot साठी वापरल्या जाणाऱ्या signed GRUB बूटलोडरला मर्यादित करण्याचा प्रस्ताव मांडला. या प्रस्तावामुळे btrfs, hfsplus, xfs आणि zfs साठीचे फाइलसिस्टम ड्रायव्हर्स, JPEG आणि PNG इमेज पार्सर्स, Apple पार्टिशन टेबल्स, LVM वरील /boot, RAID 1 व्यतिरिक्त इतर सॉफ्टवेअर RAID आणि LUKS एनक्रिप्टेड /boot काढून टाकले जातील. याचे कारण असे दिले आहे की, बूटलोडरमधील पार्सर्स हे सुरक्षेतील त्रुटींचे वारंवार कारण ठरतात आणि स्टोरेज व एनक्रिप्शन लॉजिक हे initramfs मध्ये असावे, जे कर्नल मुख्य रूट फाइलसिस्टम माउंट करण्यापूर्वी लोड करते. ऑगस्ट 2026 पर्यंत हा केवळ चर्चेतील प्रस्ताव आहे, अंमलात आलेला बदल नाही.

बहुतेक VPS इन्स्टन्सेससाठी यामुळे काहीही बदलणार नाही, कारण ते secure boot शिवाय GPT पार्टिशन टेबलवरील साध्या ext4 /boot वरून बूट होतात. गृहीत धरण्याऐवजी स्वतःच्या सर्व्हरची स्थिती तपासा. जर तुमची रूट फाइलसिस्टम ZFS असेल, किंवा /boot हे btrfs वर किंवा LUKS च्या आत असेल, तर हे अशा प्रकारचे बदल आहेत जे तुम्हाला सर्वप्रथम अंतरिम ट्रॅकवर आढळतील. प्रभावित वापरकर्त्यांसाठी त्या थ्रेडमधील सल्ला हाच आहे की त्यांनी LTS वर राहावे. हा सल्ला एका वाक्यात संपूर्ण युक्तिवाद स्पष्ट करतो. अंतरिम रिलीज हे बदल आजमावण्यासाठी असतात. LTS रिलीज हे असे ठिकाण आहे जिथे दोन वर्षांच्या अंतरिम रिलीजमध्ये काय बिघडते हे समजल्यानंतरच बदल स्वीकारले जातात.

हाच पॅटर्न प्रत्येक अंतरिम रिलीजमध्ये लहान स्वरूपात दिसून येतो. डेटाबेस, लँग्वेज रनटाइम आणि init कॉन्फिगरेशनच्या डीफॉल्ट आवृत्त्या पुढे सरकतात, त्यामुळे पूर्वी काम करणाऱ्या कॉन्फिगरेशन फाइल्स काम करणे बंद करू शकतात. डीफॉल्ट सेटिंग्ज अद्ययावत करणे हेच अंतरिम रिलीजचे काम आहे, ज्याचा अर्थ असा की त्या दहा अपग्रेड्सपैकी प्रत्येक अपग्रेड करण्यापूर्वी रिलीज नोट्स वाचणे ही तुम्ही मान्य केलेल्या अटींपैकी एक अट आहे.

सर्व्हर तयार करताना ट्रॅक निवडणे

इन्स्टॉलेशनच्या वेळीच ट्रॅक निवडा, कारण नंतर तो बदलण्यासाठी पुन्हा इन्स्टॉल करावे लागते किंवा अपग्रेडची मोठी साखळी पार करावी लागते. नवीन सर्व्हरवर, खालील चार कमांड्स तुम्हाला तुमची स्थिती सांगतात:

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a ने तुम्ही इन्स्टॉल करू इच्छित असलेल्या रिलीजचे नाव दर्शवले पाहिजे आणि LTS वर डिस्क्रिप्शन ओळीचा शेवट LTS ने होतो. Prompt ओळ तुम्ही निवडलेल्या ट्रॅकशी जुळली पाहिजे, प्रोव्हायडरच्या इमेजमध्ये जे काही आले असेल त्याशी नाही. चालू LTS वर do-release-upgrade -c ने No new release found. असे उत्तर दिले पाहिजे. जर ते त्याऐवजी तुम्हाला इंटरिम रिलीज सुचवत असेल, तर Prompt हे normal वर सेट केलेले आहे आणि हा निर्णय जाणीवपूर्वक घेतला आहे का, हे कोणीतरी ठरवले पाहिजे. pro security-status किती इन्स्टॉल केलेले पॅकेजेस कोणत्या अपडेट स्ट्रीमद्वारे कव्हर केले जातात हे रिपोर्ट करते आणि मशीन सबस्क्रिप्शनला जोडलेले नसेल तर ते स्पष्टपणे सांगते.

त्यानंतर, सर्व्हरच्या इतर बिल्ड नोट्ससोबत जिथे तुम्हाला पुन्हा दिसेल, तिथे 'एंड ऑफ लाईफ' (EOL) तारीख लिहून ठेवा. हे काम नवीन VPS वरील पहिली दहा मिनिटे यामधील इतर कामांसोबतच केले पाहिजे, कारण केवळ कोणाच्या तरी स्मरणात असलेली सपोर्ट तारीख नकळत कालबाह्य होते. जर तुम्हाला सहा महिन्यांच्या बदलांच्या चक्रातून पूर्णपणे बाहेर पडायचे असेल, तर तुम्ही एखाद्या फ्लीटसाठी निर्णय घेण्यापूर्वी FreeBSD रिलीज मॉडेल आणि Linux ची तुलना हा लेख वाचण्यासाठी एक तास देणे फायदेशीर ठरेल.

FAQ

मी प्रोडक्शन सर्व्हरवर Ubuntu interim release वापरावे का?

बहुतेक प्रकरणांमध्ये, नाही. एखादे interim release रिलीज झाल्यापासून नऊ महिन्यांनी त्याचे सुरक्षा अपडेट्स मिळणे बंद होते. त्यामुळे प्रोडक्शन सर्व्हरवर हे वापरणे म्हणजे वर्षातून दोनदा अनिवार्य अपग्रेड करणे होय. ज्या मशीन तुम्ही इमेजवरून पुन्हा तयार करता, जसे की CI runners आणि build hosts, तिथे अपग्रेड म्हणजे नवीन इन्स्टन्स तयार करणे असते, त्यामुळे तिथे हे वापरणे योग्य ठरू शकते. जर प्रत्यक्ष वापरकर्ते त्या सर्व्हरवर अवलंबून असतील, तर LTS आवृत्तीच वापरा आणि अपग्रेडसाठी लागणारा वेळ इतर कामांसाठी खर्च करा.

Ubuntu interim release ला किती कालावधीसाठी सपोर्ट मिळतो?

नऊ महिने. 26.10 हे 15 ऑक्टोबर 2026 रोजी रिलीज होते आणि त्याचे सुरक्षा मेंटेनन्स जुलै 2027 मध्ये संपते, अगदी तसेच जसे 25.10 चे जुलै 2026 मध्ये संपले होते. प्रत्येक interim release याच नियमाचे पालन करते: एप्रिल किंवा ऑक्टोबरमध्ये रिलीज आणि नऊ महिन्यांनंतर सपोर्ट समाप्त. LTS आवृत्तीला पाच वर्षांचे मानक सुरक्षा मेंटेनन्स मिळते, जे Ubuntu Pro सह दहा वर्षांपर्यंत वाढवता येते. ऑगस्ट 2026 पर्यंत, वैयक्तिक वापरासाठी पाच मशीनपर्यंत Ubuntu Pro मोफत उपलब्ध आहे.

अपग्रेड करताना मी Ubuntu च्या मधल्या आवृत्त्या वगळू शकतो का?

नाही. do-release-upgrade एका वेळी एकच पाऊल पुढे जाते: interim release त्याच्या पुढच्या रिलीजवर जाते आणि LTS थेट पुढच्या LTS वर जाऊ शकते. 26.10 वरून 28.04 LTS वर जाण्यासाठी तुम्हाला आधी 27.04 आणि 27.10 मधून अपग्रेड करावे लागेल, किंवा मशीन पुन्हा इन्स्टॉल करावे लागेल. Canonical एका वेळी एकाच ट्रांझिशनची चाचणी करते आणि अपग्रेडर फक्त त्या विशिष्ट जंपसाठी टूल डाउनलोड करतो. त्यामुळे दोन टप्प्यांची जंप करण्यासाठी कोणतेही टूल उपलब्ध नसते आणि ती ऑफर केली जात नाही.

माझ्या Ubuntu रिलीजचा सपोर्ट संपल्यावर काय होते?

त्याचे पॅकेजेस old-releases.ubuntu.com वर हलवले जातात. त्यामुळे sudo apt update हे archive.ubuntu.com वर 404 एरर दाखवू लागते आणि त्या रिलीजसाठी कोणतेही नवीन सुरक्षा अपडेट्स प्रकाशित होत नाहीत. मशीनवर याची कोणतीही सूचना मिळत नाही. सर्व्हर चालू राहतो आणि ट्रॅफिक सर्व्ह करत राहतो, परंतु त्यातील सर्व नवीन असुरक्षितता (vulnerabilities) उघड्या राहतात. अशा वेळी घाईघाईत रिलीज अपग्रेड करणे किंवा मशीन पुन्हा तयार करणे हेच पर्याय उरतात, त्यामुळे लक्षणांची वाट पाहण्यापेक्षा तारखेवर लक्ष ठेवा.

नवीन हार्डवेअरसाठी LTS कर्नल खूप जुने असते का?

सहसा नाही, कारण LTS पाच वर्षे त्याचे मूळ कर्नल वापरत नाही. Hardware enablement stack (HWE) द्वारे, नंतरच्या रिलीजमधील कर्नल LTS मध्ये पॉइंट रिलीजच्या स्वरूपात आणले जातात. सर्व्हर इन्स्टॉल करताना तुम्ही linux-generic-hwe-24.04 सारख्या पॅकेजद्वारे हे निवडू शकता. कर्नलमुळे अडथळा येत आहे असे गृहीत धरण्यापूर्वी uname -r वापरून तुम्ही कोणती आवृत्ती वापरत आहात ते तपासा. जर अडचण कर्नलची नसून userspace आवृत्तीची असेल, तर संपूर्ण मशीन interim track वर नेण्यापेक्षा कंटेनर किंवा व्हेंडर रिपॉझिटरी वापरणे हा अधिक सोपा बदल आहे.