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

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

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

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

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

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

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 अर्धवट 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 वर आहे त्याचे नाव देते. जर दोन्ही commands / प्रमाणेच filesystem दाखवत असतील, तर /boot ही root filesystem वरील फक्त एक directory आहे आणि ती स्वतंत्रपणे भरू शकत नाही. याचा अर्थ root filesystem भरले आहे आणि जुने kernels हे त्यामागील अनेक कारणांपैकी एक आहे. अशा वेळी sudo apt clean वापरल्यास /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 च्या size शी करा. initrd यांपैकी मोठी file आहे. पुढील kernel update साठी जवळपास त्याच size ची आणखी एक जोडी ठेवण्यासाठी जागा आवश्यक आहे. त्यामुळे Avail सध्याच्या initrd पेक्षा लहान असल्यास, पुढील update आधीच fail होणार आहे.

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

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

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

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

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

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

पहिले क्षेत्र dpkg चा state code दाखवते. ii म्हणजे पॅकेज installed आणि configured आहे. iF म्हणजे पॅकेज installed आहे, पण half-configured आहे. वरील अयशस्वी upgrade नंतर हीच स्थिती उरते. rc म्हणजे पॅकेज removed आहे, पण त्याची configuration डिस्कवर आहे. यामुळे /boot मध्ये जागा वापरली जात नाही आणि ते purge करणे सुरक्षित आहे.

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

या families चे विभाजन पुढीलप्रमाणे आहे. linux-image-* मध्ये /boot मधील compressed kernel असतो. 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/

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

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

apt autoremove ज्या kernel ला संरक्षित मानते तो 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 पुन्हा लिहिते. त्यामुळे ती file manually edit करून उपयोग होत नाही: पुढील kernel install तुमचे बदल overwrite करतो. ज्या releases मध्ये ही file नसते, त्या ठिकाणी apt हेच संरक्षण internally लागू करते. दोन्ही परिस्थितींमध्ये apt-config dump आपल्या box वर लागू असलेले rules दाखवते. आपल्या release साठी तेच output योग्य उत्तर आहे.

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

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

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

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

sudo apt autoremove --purge
df -h /boot

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

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

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

पहिल्या output मधील प्रत्येक version दुसऱ्या output मध्ये दिसली पाहिजे. अस्तित्वात नसलेल्या file कडे निर्देश करणारी menu entry असल्यास, कार्यरत 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 वापरून तो पुन्हा apt कडे सोपवा:

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 मध्ये काढावे लागते. छापलेली ही यादी तुमची वास्तविक सुरक्षा पडताळणी आहे. तुम्हाला काढायच्या version सोबत एखादे meta package देखील काढले जात आहे का, हे याच ठिकाणी समजते. यादीत काही अनपेक्षित असल्यास n ला उत्तर द्या. त्यानंतर आता आवश्यक राहिलेले module आणि header packages काढण्यासाठी sudo apt autoremove --purge चालवा.

तुम्ही चालू kernel कधीही का काढू नये

मेमरीमध्ये आधीच लोड असलेला kernel त्याच्या फाइल्स हटवल्यानंतरही चालू राहतो. त्यामुळे सुरुवातीला काहीही बिघडल्याचे दिसत नाही. मात्र kernel ने अद्याप लोड न केलेल्या गोष्टी बिघडतात. linux-modules-$(uname -r) purge केल्यावर /lib/modules/$(uname -r)/ हटते. त्यामुळे पुढील 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 पुरवत राहते, पण ती आधीच boot न होण्याच्या स्थितीत असते. प्रत्येक वेळी removal list मधील नोंदी uname -r शी तपासा.

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

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

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

प्रत्येक command मागे एक कारण आहे. rm हा जाणीवपूर्वक केलेला exception आहे. त्यामुळे file अस्तित्वात नसतानाही dpkg ला ती अस्तित्वात असल्याचे वाटते. आता initramfs साठी जागा उपलब्ध झाल्यामुळे apt --fix-broken install अयशस्वी झालेली configuration पूर्ण करते. त्यानंतर autoremove --purge तुम्ही delete केलेली file ज्या package ची होती ते package इतर जुन्या versions सह काढून टाकते. त्यामुळे dpkg पुन्हा disk वरील प्रत्यक्ष स्थितीशी सुसंगत होते. update-grub प्रत्यक्षात अस्तित्वात असलेल्या files वरून 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 नावाची संख्या लागू करते. नवीन kernel install केल्यामुळे ही मर्यादा ओलांडली जाणार असल्यास, ते सर्वात जुना kernel आपोआप काढून टाकते. सध्या लागू असलेली value grep installonly_limit /etc/dnf/dnf.conf आणि man 5 dnf.conf वापरून पाहा. आधीपासून साचलेले kernels sudo dnf remove --oldinstallonly वापरून काढा. तेथेही सध्या चालू असलेला kernel सुरक्षित ठेवला जातो. दोन्ही package managers मधील व्यापक तुलनेसाठी dnf आणि apt command equivalents पहा.

पुन्हा असे होऊ नये यासाठी

तुम्ही लक्षात ठेवण्यावर अवलंबून असलेली cleanup प्रक्रिया शेवटी चुकणारच. त्यामुळे ती kernels install करणाऱ्या configuration मध्येच ठेवा. /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";

शेवटी दुसरी copy जोडण्याऐवजी त्या uncomment करा. apt configuration मध्ये एखाद्या key ची शेवटची assignment लागू होते. त्यामुळे duplicate असल्यास file मधील मूल्ये परस्परविरोधी होतात आणि प्रत्यक्षात कोणते मूल्य लागू आहे हे स्पष्ट राहत नाही. 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, मशीनवर patches प्रलंबित असल्याचे कोणाच्या लक्षात येण्यापूर्वीच log मध्ये दिसतो. त्या configuration चा उर्वरित भाग Ubuntu वरील automatic security updates मध्ये दिला आहे.

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

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

Avail ही संख्या त्या file पेक्षा पुरेशी मोठी नसेल, तर पुढील kernel वर वर वर्णन केल्याप्रमाणेच failure येईल. त्यामुळे upgrade चालू असताना नव्हे, तर आत्ताच ते दुरुस्त करा. इतर VPS वरील disk health checks सोबत ही तपासणी करण्यासाठी एक मिनिट देणे उपयुक्त आहे. Release upgrade च्या अगोदर ही बाब विशेष महत्त्वाची असते. कारण Ubuntu 24.04 ला 26.04 वर हलवताना प्रक्रियेच्या सुरुवातीलाच fresh kernel install केला जातो आणि do-release-upgrade मध्ये पुरेशी space नसल्यास /boot पुढे सुरू ठेवण्यास नकार देतो. तुमच्या LTS server ला अजून तो upgrade उपलब्ध झाला नसेल, तर ते fault मुळे नव्हे तर timing मुळे आहे. Ubuntu, 26.04.1 point release ships होईपर्यंत LTS ते LTS upgrades थांबवते. त्यामुळे आधी /boot व्यवस्थित करण्यासाठी तुम्हाला निश्चित वेळ मिळतो.

FAQ

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

कारण boot होण्यात अपयशी ठरलेला kernel उपलब्ध पर्यायांशिवाय सोडू शकतो. मागील version ठेवल्यामुळे खराब update नंतर provider rescue console वापरण्याऐवजी GRUB menu मधून प्रणाली पुन्हा सुरू करता येते. 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 अजूनही भरलेले आहे. आता काय करावे?

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

/boot मधील files manually हटवू शकतो का?

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