Ubuntu मध्ये जुने kernels काढून /boot मोकळे करा

जुने kernels मुळे /boot भरल्यावर apt काम करणे का थांबवते

Ubuntu वर प्रत्येक kernel update /boot मध्ये फाइल्सचा एक नवीन संच लिहितो आणि मागील फाइल्स तिथेच ठेवतो. त्यामुळे लहान /boot partition भरतो आणि apt install पूर्ण करू शकत नाही. दुरुस्ती दोन टप्प्यांत करावी लागते. या मशीनवर कोणती packages kernels आहेत आणि सध्या कोणता kernel boot झाला आहे ते ठरवा. त्यानंतर apt autoremove --purge वापरून उरलेले kernels काढा.

क्रम महत्त्वाचा आहे. सध्या चालू असलेला kernel काढू नये. तसेच मशीनची स्थिती अशी असू शकते की apt अजिबात चालू शकत नाही. प्रथम निदान करा.

प्रत्यक्षात अपयश कसे दिसते

कर्नलची एखादी आवृत्ती /boot मध्ये दोन मोठ्या फाइल्स स्थापित करते: संकुचित कर्नल (vmlinuz-<version>) आणि initramfs (initial RAM filesystem, initrd.img-<version>; वास्तविक root mount करण्यापूर्वी कर्नल ज्या छोट्या archive ला unpack करतो). Install वेळी initramfs तुमच्या मशीनवर तयार केला जातो. त्यामुळे install साठी केवळ download bandwidth नव्हे, तर मोकळी जागाही आवश्यक असते. जागा शिल्लक नसल्यास build अपयशी ठरतो आणि त्यासोबत package installation देखील अपयशी ठरते.

update-initramfs: Generating /boot/initrd.img-6.8.0-64-generic
gzip: stdout: No space left on device
E: mkinitramfs failure gzip 1
update-initramfs: failed for /boot/initrd.img-6.8.0-64-generic with 1.
dpkg: error processing package linux-image-6.8.0-64-generic (--configure):
 installed linux-image-6.8.0-64-generic package post-installation script subprocess returned error exit status 1

Version string तुमच्या सिस्टमप्रमाणे असेल. Compressor चे नाव /etc/initramfs-tools/initramfs.conf मधील COMPRESS= वरून येते. त्यामुळे अलीकडील image मध्ये zstd, तर जुन्या image मध्ये gzip असे नाव असू शकते. या समस्येची ओळख करणाऱ्या दोन ओळी म्हणजे No space left on device आणि तिच्या खालील dpkg: error processing package ओळ.

यानंतर package half-configured स्थितीत राहतो. प्रत्येक पुढील apt run त्याला पुन्हा configure करण्याचा प्रयत्न करतो, त्याच प्रकारे अपयशी ठरतो आणि E: Sub-process /usr/bin/dpkg returned an error code (1) ने समाप्त होतो. Disk space च्या पलीकडे महत्त्वाचा मुद्दा हा आहे: unattended-upgrades आपल्या timer नुसार चालतो, तोच error आढळतो आणि थांबतो. Server व्यवस्थित दिसत राहतो, पण security patches लागू करणे शांतपणे थांबते. तसेच तुम्ही केलेला कोणताही unrelated install त्याच ओळीमुळे अपयशी ठरू शकतो आणि त्या वेळी तुम्ही जोडत असलेल्या package वर दोष जातो. म्हणूनच Ubuntu वर अपयशी ठरणारे Tailscale install प्रथम apt error म्हणून वाचणे उपयुक्त ठरते. तुम्ही इथपर्यंत पोहोचण्यापूर्वी apt update अपयशी ठरत असेल, तर ती स्वतंत्र समस्या आहे. ती बहुतेकदा deb822 sources migration नंतरची duplicate entry असते.

/boot स्वतंत्र partition आहे का ते तपासा

काहीही हटवण्यापूर्वी, प्रत्यक्षात किती जागा मोकळी होणार आहे ते शोधा.

findmnt /boot
findmnt -T /boot
df -h /boot /

पहिली command फक्त /boot हा स्वतंत्र mount point असेल तरच एक ओळ दाखवते. दुसरी command नेहमी output दाखवते आणि /boot प्रत्यक्षात ज्या filesystem वर आहे त्याचे नाव देते. त्या दोन्हींचे नाव / प्रमाणेच filesystem दाखवत असेल, तर /boot ही root filesystem वरील केवळ directory आहे आणि ती स्वतंत्रपणे भरू शकत नाही. तुमची root filesystem भरली आहे आणि जुने kernels हे त्यामागील अनेक कारणांपैकी एक आहे. अशा वेळी sudo apt clean वापरल्यास जागा मोकळी होते. ही command /var/cache/apt/archives अंतर्गत डाउनलोड केलेल्या .deb files हटवते. प्रत्यक्ष /boot partition असलेल्या मशीनवर apt clean तिथे कोणतीही जागा मोकळी करत नाही, कारण cache वेगळ्या filesystem वर असतो.

आता तुम्ही ज्या संख्येच्या आधारावर काम करणार आहात ती मिळवा.

df -h /boot
ls -lh /boot/vmlinuz-$(uname -r) /boot/initrd.img-$(uname -r)

Avail column ची तुलना त्या दोन files च्या आकाराशी करा. initrd यांपैकी मोठी file आहे. पुढील kernel update साठी साधारण त्याच आकाराच्या आणखी एका जोडीसाठी जागा लागेल. त्यामुळे Avail सध्याच्या initrd पेक्षा लहान असेल, तर पुढील update आधीच अपयशी ठरणार आहे.

तुम्ही चालवत असलेले kernel शोधा

uname -r
cat /var/run/reboot-required.pkgs

uname -r सध्या memory मध्ये लोड असलेल्या kernel ची release string दाखवते. ती string कुठेतरी कॉपी करून ठेवा. हीच ती version आहे जिच्यात तुम्ही कोणताही बदल करू नये.

दुसरी file फक्त एखाद्या package ने reboot मागितल्यावरच अस्तित्वात असते. त्या file मधील linux-image line म्हणजे disk वर नवीन kernel install केलेले आहे, पण तो वापरात नाही, कारण तो install झाल्यापासून machine reboot केलेली नाही. शक्य असल्यास cleanup करण्यापूर्वी reboot करा. apt चालू kernel आणि सर्वात नवीन kernel सुरक्षित ठेवते. त्यामुळे जुना kernel चालू असताना cleanup केल्यास आवश्यकतेपेक्षा आणखी एक version pinned राहते.

कर्नल पॅकेजची यादी करा आणि त्यांची स्थिती वाचा

dpkg --list | grep -E 'linux-(image|modules|headers|tools)' | awk '{print $1, $2}'

पहिले फील्ड म्हणजे dpkg चा स्थिती कोड. ii म्हणजे पॅकेज install आणि configure केलेले आहे. iF म्हणजे पॅकेज install झालेले आहे, पण अर्धवट configure झालेले आहे. वरील अयशस्वी upgrade नंतर नेमकी हीच स्थिती उरते. rc म्हणजे पॅकेज remove केलेले आहे, पण त्याची configuration डिस्कवर अजूनही आहे. ते /boot मध्ये कोणतीही जागा व्यापत नाही आणि purge करणे सुरक्षित आहे.

दुसरे फील्ड पॅकेजचा प्रकार सांगते. linux-image-6.8.0-64-generic सारख्या नावात version असल्यास ते एक विशिष्ट कर्नल असते. linux-image-generic, linux-headers-generic किंवा linux-generic सारख्या नावात version नसल्यास ते meta package असते. त्यात कर्नल नसतो. त्याचे एकमेव काम नवीनतम version असलेल्या कर्नलवर dependency ठेवणे हे आहे, त्यामुळे apt upgrade नवीन कर्नल install करते. Meta package काढल्यावर मशीनला कर्नल updates मिळणे थांबते. त्यानंतर याबाबत कोणतीही सूचना मिळत नाही.

ही कुटुंबे पुढीलप्रमाणे विभागली जातात. linux-image-* मध्ये /boot मधील compressed कर्नल असतो. linux-modules-* आणि linux-modules-extra-* मध्ये /lib/modules अंतर्गत drivers असतात. linux-headers-* मध्ये /usr/src अंतर्गत build headers असतात. त्यामुळे headers purge केल्याने root filesystem मधील जागा मोकळी होते, /boot मधील नाही. तुमची समस्या /boot partition भरल्याची असल्यास, तुम्ही image packages शोधले पाहिजेत.

ls -1 /boot/vmlinuz-*
ls -1 /lib/modules/

या दोन्ही याद्या एकमेकांशी आणि dpkg --list च्या output शी जुळल्या पाहिजेत. /lib/modules मधील एखाद्या directory साठी matching installed package नसेल, तर ती एखाद्याने files manually delete केल्यामुळे उरलेली आहे.

apt कोणते kernels ठेवायचे हे कसे ठरवते

apt autoremove ज्या kernel ला संरक्षित मानते तो काढणार नाही. या संरक्षित संचात सध्या चालू असलेला kernel देखील समाविष्ट असतो. Ubuntu releases मध्ये retention policy बदललेली आहे. त्यामुळे कुठेही लिहिलेल्या संख्येवर विश्वास ठेवण्याऐवजी ती तुमच्या स्वतःच्या मशीनवर तपासा.

apt-config dump | grep -i -e neverautoremove -e versionedkernel
ls -l /etc/apt/apt.conf.d/01autoremove /etc/apt/apt.conf.d/01autoremove-kernels

APT::NeverAutoRemove ही package name patterns ची यादी आहे, ज्यांना apt autoremove स्पर्श करण्यास नकार देते. APT::VersionedKernelPackages ही name prefixes ची यादी आहे, ज्यांना apt सुरुवातीपासून versioned kernel packages मानते. ज्या releases मध्ये /etc/apt/apt.conf.d/01autoremove-kernels तयार केली जाते, त्या releases मध्ये प्रत्येक kernel package install केल्यानंतर /etc/kernel/postinst.d/apt-auto-removal ती file पुन्हा लिहिते. त्यामुळे ती स्वतः संपादित करून उपयोग होत नाही: पुढील kernel install तुमचा बदल overwrite करतो. ज्या releases मध्ये ही file उपलब्ध नसते, तिथे apt हीच protection अंतर्गत लागू करते. कोणत्याही परिस्थितीत, तुमच्या मशीनवर लागू असलेले rules apt-config dump दाखवते. तुमच्या release साठी तेच अचूक उत्तर आहे.

सुरक्षितपणे चालवता येणारी साफसफाई

sudo apt update
sudo apt autoremove --purge --dry-run

--dry-run डिस्कवरील काहीही बदलत नाही आणि प्रत्यक्ष run मध्ये काय काढले जाईल ते अचूकपणे दाखवते. यादी वाचा. दोन गोष्टी दिसल्यास थांबा. linux-generic किंवा linux-image-generic सारखे meta package removal list मध्ये असल्यास, एखाद्या प्रक्रियेने त्याला automatic म्हणून चिन्हांकित केले आहे. ते काढल्यास kernel updates बंद होतील. uname -r मधील string removal list मध्ये असल्यास, सध्या चालू असलेला kernel protected नाही. असे होऊ नये. पुढे जाण्यापूर्वी याची चौकशी करा.

यादी योग्य दिसत असल्यास ती प्रत्यक्षात चालवा.

sudo apt autoremove --purge
df -h /boot

--purge भाग package सोबत उरलेली configuration देखील हटवतो. यामुळे फारच थोडी अतिरिक्त जागा मोकळी होते. तसेच dpkg --list मध्ये rc lines साचत नाहीत आणि पुढील audit वाचणे सोपे होते.

त्यानंतर boot menu पुन्हा तयार झाले आहे याची खात्री करा. Kernel package काढल्यावर update-grub तुमच्यासाठी चालवले जाते. त्यामुळे menu मध्ये अजून अस्तित्वात असलेल्या files चेच संदर्भ असले पाहिजेत.

sudo grep -o 'vmlinuz-[^ ]*' /boot/grub/grub.cfg | sort -u
ls -1 /boot/vmlinuz-*

पहिल्या output मधील प्रत्येक version दुसऱ्या output मध्ये दिसला पाहिजे. अस्तित्वात नसलेल्या file कडे निर्देश करणारी menu entry असल्यास working server GRUB prompt वर थांबू शकतो. हा kernel update नंतर boot न होणारा VPS होण्याचा एक मार्ग आहे. हे आधीच टाळण्यापेक्षा rescue console मधून दुरुस्त करणे खूप कठीण असते.

apt autoremove कधीकधी काहीही का काढत नाही

apt autoremove फक्त automatic म्हणून चिन्हांकित केलेली पॅकेजेस काढते. म्हणजेच, इतर एखाद्या पॅकेजची dependency म्हणून install केलेली पॅकेजेस. तुम्ही apt install linux-image-6.8.0-40-generic वापरून स्वतः install केलेला kernel manual म्हणून चिन्हांकित केला जातो. तो कितीही जुना झाला तरी autoremove त्याला कधीही काढणार नाही.

apt-mark showmanual | grep -E '^linux-'

त्या output मधील version असलेला कोणताही kernel autoremove ला दिसत नाही. तुमच्या स्वतःच्या listing मधील version strings वापरून तो पुन्हा automatic म्हणून चिन्हांकित करा:

sudo apt-mark auto linux-image-6.8.0-40-generic linux-modules-6.8.0-40-generic
sudo apt autoremove --purge --dry-run

meta packages manual म्हणूनच चिन्हांकित ठेवा. ती manual असणे अपेक्षित आहे, कारण त्यांची मागणी तुम्हीच केली आहे.

विशिष्ट kernel जाणूनबुजून काढून टाका

कधीकधी policy परवानगी देईपर्यंत प्रतीक्षा करण्याऐवजी एखादी विशिष्ट version लगेच काढायची असते. image package चे नाव द्या आणि apt ला उर्वरित प्रक्रिया ठरवू द्या.

sudo apt purge linux-image-6.8.0-40-generic

apt कोणतीही कृती करण्यापूर्वी काढल्या जाणाऱ्या packages ची यादी दाखवते, कारण linux-modules-extra-* image package वर अवलंबून आहे आणि त्याला त्याच transaction मध्ये काढावे लागते. ही दाखवलेली यादी तुमची वास्तविक safety check आहे. याच ठिकाणी तुम्हाला काढायच्या version सोबत एखादा meta package देखील काढला जात आहे का ते समजते. यादीत अनपेक्षित काही असल्यास n द्या. त्यानंतर आता आवश्यक न राहिलेले module आणि header packages काढण्यासाठी sudo apt autoremove --purge चालवा.

चालू kernel कधीही का काढू नये

मेमरीमध्ये आधीच लोड असलेला kernel त्याच्या फाइल्स delete केल्यानंतरही चालू राहतो. त्यामुळे सुरुवातीला काहीही बिघडल्याचे दिसत नाही. मात्र kernel ने अद्याप load न केलेल्या सर्व गोष्टी बिघडतात. linux-modules-$(uname -r) purge केल्यावर /lib/modules/$(uname -r)/ delete होते. त्यामुळे पुढील module load अयशस्वी होते:

modprobe: FATAL: Module nf_tables not found in directory /lib/modules/6.8.0-64-generic

त्या क्षणापासून firewall reload अयशस्वी होते. तसेच boot पासून या kernel ने न हाताळलेला filesystem type mount करणेही अयशस्वी होते. दरम्यान, /boot/vmlinuz-$(uname -r) नाहीसे होते. त्यामुळे boot menu मध्ये तुम्ही चालवत असलेला kernel उपलब्ध राहत नाही. पुढील reboot नंतर मशीन वेगळ्या kernel वर सुरू होते. मशीन network traffic serve करत राहते, पण ती आधीच boot न होण्याच्या स्थितीत असते. प्रत्येक वेळी removal list विरुद्ध uname -r तपासा.

जेव्हा /boot इतके भरते की apt अजिबात चालत नाही

हीच ती स्थिती आहे ज्यामुळे लोक हे पृष्ठ शोधतात. apt autoremove ला अर्धवट configure झालेल्या kernel package चे configuration आधी पूर्ण करण्यासाठी dpkg आवश्यक असते. त्या प्रक्रियेत initramfs पुन्हा तयार केला जातो. त्यासाठी अशा /boot मध्ये जागा आवश्यक असते, ज्यात जागाच उरलेली नसते. ही चक्राकार समस्या हाताने एकदाच सोडवा.

uname -r
ls -1 /boot/initrd.img-*

ज्याची version uname -r ने दिलेल्या string सारखी नाही, असा एक initrd निवडा आणि ती एकच file delete करा.

sudo rm /boot/initrd.img-6.8.0-40-generic
sudo apt --fix-broken install
sudo apt autoremove --purge
sudo update-grub

प्रत्येक ओळीमागे एक कारण आहे. rm हा जाणीवपूर्वक केलेला अपवाद आहे. त्यामुळे file अस्तित्वात नसतानाही dpkg ला ती अस्तित्वात असल्याचे वाटते. आता initramfs साठी जागा उपलब्ध झाल्यामुळे apt --fix-broken install अयशस्वी झालेले configuration पूर्ण करते. त्यानंतर autoremove --purge तुम्ही delete केलेली file असलेले package इतर जुन्या versions सोबत काढून टाकते. त्यामुळे dpkg पुन्हा disk वरील प्रत्यक्ष स्थितीशी जुळते. प्रत्यक्षात अस्तित्वात असलेल्या files वरून update-grub menu पुन्हा तयार करते. rm आणि update-grub यांच्या दरम्यान reboot करू नका. त्या वेळेत menu अजूनही तुम्ही delete केलेल्या file कडे निर्देश करू शकतो. dpkg interrupted असल्याची तक्रार करत असल्यास, sudo dpkg --configure -a हे apt --fix-broken install प्रमाणेच repair करते.

dnf प्रणालींवर तेच काम

तुमचा VPS Fedora किंवा Rocky Linux सारख्या RHEL पुनर्बांधणींपैकी एखादे वितरण चालवत असल्यास, यंत्रणा उलट असते. Debian आणि Ubuntu apt autoremove नियमांद्वारे kernel चे संरक्षण करतात आणि cleanup तुमच्यावर किंवा तो सुरू करण्यासाठी unattended-upgrades वर सोपवतात. याउलट, dnf installonly_limit नावाची संख्या लागू करते आणि नवीन install मुळे ही मर्यादा ओलांडली जाणार असल्यास सर्वात जुना kernel आपोआप काढून टाकते. सध्या लागू असलेली value grep installonly_limit /etc/dnf/dnf.conf आणि man 5 dnf.conf वापरून वाचा. आधीपासून साचलेला backlog sudo dnf remove --oldinstallonly वापरून साफ करा. तेथेही सध्या चालू असलेल्या kernel चे संरक्षण केले जाते. या दोन package managers मधील विस्तृत तुलनेसाठी dnf आणि apt command equivalents पहा.

पुन्हा असे होऊ देऊ नका

तुमच्या लक्षात राहण्यावर अवलंबून असलेली साफसफाई अखेरीस अपयशी ठरेल. त्यामुळे ती kernels install करणाऱ्या घटकातच कॉन्फिगर करा. /etc/apt/apt.conf.d/50unattended-upgrades उघडा आणि या keys शोधा. shipped file मध्ये त्या commented lines म्हणून आधीच आहेत:

Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

त्यांच्या पुढे दुसरी प्रत जोडण्याऐवजी त्या uncomment करा. apt configuration मध्ये एखाद्या key ची शेवटची assignment लागू होते. त्यामुळे duplicate असल्यास file मधील values परस्परविरोधी होतात आणि खरी value कोणती हे अस्पष्ट होते. Parser ने शेवटी कोणती configuration स्वीकारली ते तपासा आणि काहीही बदल न करणारी run monitor करा:

apt-config dump | grep -i 'Unattended-Upgrade::Remove'
sudo unattended-upgrade --dry-run --debug
sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log

Log हा याचा पुरावा आहे. तो प्रत्येक run नोंदवतो. त्यामुळे space कमी असल्याने अयशस्वी झालेला upgrade, machine वर patches मागे पडल्याचे कोणाच्या लक्षात येण्यापूर्वीच log मध्ये दिसतो. या configuration चा उर्वरित भाग Ubuntu वरील automatic security updates मध्ये दिला आहे.

पुढील kernel येण्यापूर्वी एक संख्या तपासा. हीच guide च्या सुरुवातीला वापरलेली commands ची जोडी आहे:

df -h /boot
ls -lh /boot/initrd.img-$(uname -r)

Avail ही file size पेक्षा पुरेशी जास्त नसेल, तर पुढील kernel वर वर्णन केल्याप्रमाणेच fail होईल. त्यामुळे upgrade च्या वेळी नव्हे, तर आत्ताच ते दुरुस्त करा. तुमच्या इतर VPS वरील disk health checks सोबत ही तपासणी करण्यासाठी एक मिनिट पुरेसा आहे. Release upgrade च्या अगोदर ही तपासणी विशेष महत्त्वाची आहे. कारण Ubuntu 24.04 ला 26.04 वर नेल्यावर प्रक्रियेच्या सुरुवातीलाच fresh kernel install होतो आणि do-release-upgrade कडे पुरेशी space नसल्यास तो पुढे सुरू ठेवण्यास नकार देतो. /boot

FAQ

Ubuntu जुने kernels हटवण्याऐवजी ते का ठेवते?

Boot होण्यात अपयशी ठरलेला kernel असल्यास निवडण्यासाठी दुसरा पर्याय उरत नाही. मागील version ठेवलेली असल्यास खराब update नंतर provider rescue console ऐवजी GRUB menu मधून recovery करता येते. apt म्हणून kernel packages च्या एका संचाला automatic removal पासून सुरक्षित ठेवते. यात तुम्ही सध्या चालवत असलेला kernel नेहमी समाविष्ट असतो. तुमचे release नेमके कोणते patterns सुरक्षित ठेवते हे पाहण्यासाठी apt-config dump | grep -i neverautoremove चालवा, कारण releases नुसार policy बदलली आहे.

Production server वर apt autoremove --purge चालवणे सुरक्षित आहे का?

होय, dry run आधी वाचल्यास ते सुरक्षित आहे. काहीही लिहित नसलेले sudo apt autoremove --purge --dry-run चालवा आणि छापलेली list तपासा. त्यात linux-generic किंवा linux-image-generic सारखे meta package असल्यास थांबा, कारण यापैकी एखादे काढल्यास पुढील kernel updates बंद होतात. त्यात uname -r ने दाखवलेला version string असल्यासही थांबा. यापैकी एकही आढळले नाही, तर काढली जाणारी packages जुने kernels आणि orphaned dependencies आहेत.

apt autoremove ने काहीही काढले नाही आणि /boot अजूनही full आहे. आता काय करावे?

जुने kernels बहुधा manual म्हणून marked आहेत आणि autoremove फक्त automatic म्हणून marked असलेल्या packages वर कार्य करते. apt-mark showmanual | grep -E '^linux-' चालवा. तेथे सूचीबद्ध असलेला कोणताही versioned kernel पूर्वी कधीतरी हाताने install केलेला आहे. sudo apt-mark auto linux-image-<version> वापरून त्याला automatic म्हणून mark करा आणि dry run पुन्हा चालवा. किंवा sudo apt purge linux-image-<version> वापरून ती एक version थेट purge करा.

मी /boot मधील files हाताने delete करू शकतो का?

फक्त जाणीवपूर्वक केलेल्या एकदाचच्या उपाय म्हणून, जेव्हा /boot इतका full असतो की apt broken kernel package configure करू शकत नाही. uname -r च्या output मध्ये नसलेली version असलेली एकच initrd.img-<version> file delete करा. त्यानंतर लगेच sudo apt --fix-broken install, sudo apt autoremove --purge आणि sudo update-grub चालवा. या पुढील steps शिवाय files delete केल्यास dpkg files नसलेल्या packages ची नोंद ठेवते आणि GRUB menu entries missing files कडे निर्देश करत राहतात. त्यामुळे चूक केल्याच्या क्षणी नव्हे, तर पुढील reboot वेळी machine fail होते.