Ubuntu में /boot partition को कैसे साफ करें

जब /boot में पुराने kernels भर जाते हैं तो apt काम करना क्यों बंद कर देता है

Ubuntu पर, हर kernel update /boot में फाइलों का एक नया सेट लिखता है और पिछली फाइलों को वहीं रहने देता है। इस कारण एक छोटी /boot partition भर जाती है और apt किसी भी install को पूरा नहीं कर पाता है। इसे ठीक करने के दो चरण हैं। सबसे पहले यह पता लगाएँ कि सिस्टम पर कौन से packages kernels हैं और आप कौन सा kernel इस्तेमाल कर रहे हैं, फिर बाकी को apt autoremove --purge के साथ हटा दें।

क्रम महत्वपूर्ण है। जो kernel अभी चल रहा है, उसे बिल्कुल न हटाएँ। हो सकता है कि सिस्टम पहले से ही ऐसी स्थिति में हो जहाँ apt बिल्कुल भी न चल पा रहा हो। इसलिए पहले समस्या की जाँच करें।

विफलता वास्तव में कैसी दिखती है

एक kernel version /boot में दो बड़ी फाइलें install करता है: compressed kernel (vmlinuz-<version>) और initramfs (initial RAM filesystem, initrd.img-<version>, वह छोटा archive जिसे kernel वास्तविक root को mount करने से पहले unpack करता है)। initramfs का निर्माण install के समय आपकी machine पर ही होता है, इसीलिए install के लिए केवल download bandwidth ही नहीं, बल्कि खाली disk space की भी आवश्यकता होती है। जगह न बचने पर, यह build प्रक्रिया विफल हो जाती है और package को भी साथ ले डूबती है।

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 इसे फिर से configure करने का प्रयास करता है, उसी तरह विफल होता है, और E: Sub-process /usr/bin/dpkg returned an error code (1) के साथ समाप्त होता है। disk space के अलावा यह हिस्सा महत्वपूर्ण है: unattended-upgrades अपने timer पर चलता है, उसी error का सामना करता है, और रुक जाता है। सर्वर स्वस्थ दिखता है और चुपचाप security patches लागू करना बंद कर देता है। इसका मतलब यह भी है कि आप जो भी अन्य unrelated install करने का प्रयास करेंगे, वह भी उसी line के साथ विफल हो जाएगा और दोष उस चीज़ पर मढ़ा जाएगा जिसे आप उस समय जोड़ रहे थे, इसीलिए Ubuntu पर विफल होने वाला Tailscale install को पहले एक apt error के रूप में पढ़ना सार्थक है। यदि आप यहाँ तक पहुँचने से पहले ही apt update विफल हो जाता है, तो यह एक अलग समस्या है, जो अक्सर deb822 sources migration के बाद duplicate entry के कारण होती है।

जाँचें कि क्या /boot एक अलग partition है

कुछ भी delete करने से पहले, यह पता लगाएँ कि आप वास्तव में कितनी जगह खाली कर रहे हैं।

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

पहली command केवल तभी एक line print करती है यदि /boot अपना स्वयं का mount point हो। दूसरी command हमेशा print करती है और उस filesystem का नाम बताती है जो वास्तव में /boot को धारण करता है। यदि वे / के समान filesystem का नाम बताती हैं, तो /boot केवल root filesystem पर एक directory है और यह अपने आप full नहीं हो सकती: आपका root filesystem full है, और पुराने kernels इसके कई कारणों में से एक हैं। उस स्थिति में sudo apt clean, जो /var/cache/apt/archives के अंतर्गत download की गई .deb files को खाली करता है, आपको जगह दिलाता है। एक वास्तविक /boot partition वाली machine पर, 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 को print करती है। उस string को कहीं copy कर लें। यह वह एकमात्र version है जिसे आपको नहीं हटाना चाहिए।

दूसरी file केवल तब मौजूद होती है जब किसी package ने reboot के लिए कहा हो। इसमें मौजूद linux-image लाइन का अर्थ है कि disk पर एक नया kernel installed है जो अभी उपयोग में नहीं है, क्योंकि उसे install करने के बाद machine reboot नहीं हुई है। यदि संभव हो तो सफाई करने से पहले reboot करें। apt चल रहे kernel और सबसे नए kernel को सुरक्षित रखता है, इसलिए यदि आप पुराने kernel पर चल रहे हैं और सफाई करते हैं, तो यह आपकी आवश्यकता से एक अधिक version को सुरक्षित रखेगा।

Kernel packages की सूची बनाएँ और उनकी स्थिति पढ़ें

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

पहला field dpkg का state code है। ii का अर्थ है कि package install और configure हो चुका है। iF का अर्थ है कि package install तो है लेकिन आधा-अधूरा configure हुआ है, जो कि ऊपर बताए गए failed upgrade का परिणाम है। rc का अर्थ है कि package हटा दिया गया है लेकिन उसकी configuration अभी भी disk पर मौजूद है, जो /boot में कोई जगह नहीं घेरती और इसे सुरक्षित रूप से purge किया जा सकता है।

दूसरा field आपको बताता है कि यह किस प्रकार का package है। एक नाम जिसमें version शामिल हो, जैसे linux-image-6.8.0-64-generic, एक विशिष्ट kernel है। बिना version वाला नाम, जैसे linux-image-generic, linux-headers-generic या linux-generic, एक meta package है। इसमें कोई kernel नहीं होता। इसका मुख्य कार्य सबसे नए versioned kernel पर निर्भर रहना है ताकि apt upgrade नए kernels को pull कर सके। Meta package को हटाने से मशीन को kernel updates मिलना बंद हो जाते हैं, और बाद में आपको कोई चेतावनी भी नहीं मिलती।

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/

ये दोनों सूचियाँ एक-दूसरे के साथ और dpkg --list output के साथ मेल खानी चाहिए। /lib/modules में मौजूद कोई directory जिसका कोई matching installed package नहीं है, वह किसी के द्वारा मैन्युअल रूप से files हटाने का परिणाम है।

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 जनरेट होता है, उस file को हर बार kernel package install होने पर /etc/kernel/postinst.d/apt-auto-removal द्वारा फिर से लिखा जाता है, इसलिए उसे हाथ से edit करने का कोई फायदा नहीं है: अगला kernel install आपके बदलाव को overwrite कर देगा। जिन releases में यह file मौजूद नहीं होती, apt आंतरिक रूप से वही सुरक्षा लागू करता है। किसी भी स्थिति में, apt-config dump आपके सिस्टम पर लागू नियमों को दिखाता है, और वह output ही आपके release के लिए सही उत्तर है।

वह सफाई जिसे चलाना सुरक्षित है

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

--dry-run डिस्क पर कुछ भी नहीं बदलता है और ठीक वही प्रिंट करता है जिसे वास्तविक रन हटा देगा। सूची को पढ़ें। दो चीजें आपको रुकने पर मजबूर कर देनी चाहिए। हटाने की सूची में linux-generic या linux-image-generic जैसा कोई मेटा पैकेज होने का मतलब है कि किसी चीज ने इसे स्वचालित रूप से चिह्नित किया है, और इसे हटाने का मतलब है कि आपके कर्नेल अपडेट बंद हो जाएंगे। हटाने की सूची में uname -r से आने वाली स्ट्रिंग का मतलब है कि चल रहा कर्नेल सुरक्षित नहीं है, जो कि नहीं होना चाहिए और आगे बढ़ने से पहले इसकी जांच की जानी चाहिए।

यदि सूची सही दिखती है, तो इसे वास्तविक रूप से चलाएं।

sudo apt autoremove --purge
df -h /boot

--purge आधा हिस्सा पैकेज के साथ-साथ बचे हुए कॉन्फ़िगरेशन को भी हटा देता है। यह थोड़ी अतिरिक्त जगह खाली करता है, और यह dpkg --list को संचित rc लाइनों से मुक्त रखता है, जिससे अगला ऑडिट पढ़ने योग्य हो जाता है।

फिर पुष्टि करें कि बूट मेनू को फिर से बनाया गया था। कर्नेल पैकेज को हटाने से आपके लिए update-grub चलता है, इसलिए मेनू को केवल उन फ़ाइलों का संदर्भ देना चाहिए जो अभी भी मौजूद हैं।

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

पहले आउटपुट का प्रत्येक संस्करण दूसरे में दिखाई देना चाहिए। एक ऐसी फ़ाइल की ओर इशारा करने वाली मेनू प्रविष्टि जो गायब हो गई है, वह तरीका है जिससे एक काम करने वाला सर्वर GRUB प्रॉम्प्ट पर रुकने वाला सर्वर बन जाता है। यह एक VPS जो कर्नेल अपडेट के बाद बूट नहीं होगा तक पहुँचने का एक रास्ता है, और इसे यहाँ बचने की तुलना में रेस्क्यू कंसोल से ठीक करना कहीं अधिक कठिन है।

apt autoremove कभी-कभी कुछ भी क्यों नहीं हटाता है

apt autoremove केवल उन packages को हटाता है जिन्हें automatic के रूप में चिह्नित किया गया है, जिसका अर्थ है कि वे packages जो किसी अन्य चीज़ की dependency के रूप में install किए गए थे। आपके द्वारा स्वयं install किया गया kernel, apt install linux-image-6.8.0-40-generic के साथ, manual के रूप में चिह्नित होता है, और autoremove उसे कभी नहीं हटाएगा, चाहे वह कितना भी पुराना क्यों न हो जाए।

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

उस output में कोई भी versioned kernel autoremove के लिए अदृश्य होता है। अपनी listing से version strings का उपयोग करके, उसे वापस manual चिह्नित करें:

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 ही होना चाहिए, क्योंकि वे वही हैं जिन्हें आपने install करने के लिए कहा था।

किसी विशिष्ट kernel को जानबूझकर हटाना

कभी-कभी आप चाहते हैं कि कोई विशिष्ट version तुरंत हट जाए, न कि तब जब policy इसकी अनुमति दे। image package का नाम दें और बाकी काम apt को करने दें।

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

apt कोई भी कार्रवाई करने से पहले हटाने वाली सूची (removal list) प्रिंट करता है, क्योंकि linux-modules-extra-* उस image package पर निर्भर है और उसे भी उसी transaction में हटाना होगा। वह प्रिंट की गई सूची आपकी वास्तविक सुरक्षा जाँच है, और यहीं आप देख सकते हैं कि क्या उस version के साथ कोई meta package भी हट रहा है जिसे आप हटाना नहीं चाहते थे। यदि सूची में कुछ भी अप्रत्याशित हो, तो n उत्तर दें। इसके बाद sudo apt autoremove --purge का उपयोग करके उन module और header packages को हटाएँ जिनका अस्तित्व अब समाप्त हो चुका है।

आप running kernel को कभी क्यों नहीं हटाते

जो kernel पहले से memory में है, वह files 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 विफल हो जाता है, और इसी तरह उस filesystem type को mount करना भी विफल हो जाता है जिसे इस kernel ने boot के बाद से touch नहीं किया है। इस बीच /boot/vmlinuz-$(uname -r) जा चुका होता है, इसलिए boot menu अब वह kernel offer नहीं करता जिसे आप चला रहे हैं, और अगला reboot कहीं और ले जाता है। machine traffic serve करना जारी रखती है और पहले से ही unbootable होती है। हर बार removal list के साथ uname -r की जाँच करें।

जब /boot इतना भर जाए कि apt बिल्कुल न चल सके

यह वह स्थिति है जिसके कारण लोग इस पेज को ढूँढते हैं। apt autoremove को आधे-अधूरे कॉन्फ़िगर किए गए kernel पैकेज को पूरा करने के लिए dpkg की आवश्यकता होती है, और वह चरण एक initramfs को फिर से बनाता है, जिसके लिए ऐसे /boot में जगह चाहिए जिसमें कोई जगह नहीं बची है। इस लूप को एक बार मैन्युअल रूप से तोड़ें।

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

एक ऐसा initrd चुनें जिसका वर्शन वह स्ट्रिंग न हो जो आपको uname -r ने दी थी, और उस एक फ़ाइल को हटा दें।

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

प्रत्येक पंक्ति का एक कारण है। rm एक जानबूझकर किया गया अपवाद है जो dpkg को यह विश्वास दिलाता है कि एक फ़ाइल मौजूद है जबकि वह नहीं है। apt --fix-broken install उस कॉन्फ़िगरेशन को पूरा करता है जो विफल हो गया था, क्योंकि अब initramfs के लिए जगह उपलब्ध है। इसके बाद autoremove --purge उस पैकेज को हटा देता है जिसकी फ़ाइल आपने हटाई थी, साथ ही अन्य पुराने वर्शन भी हटा देता है, जिससे dpkg डिस्क के साथ फिर से तालमेल में आ जाता है। update-grub उन फ़ाइलों से मेनू को फिर से बनाता है जो वास्तव में मौजूद हैं। rm और update-grub के बीच रीबूट न करें, क्योंकि उस अंतराल में मेनू अभी भी उस फ़ाइल की ओर इशारा कर सकता है जिसे आपने अभी हटाया है। यदि dpkg शिकायत करता है कि वह बाधित हो गया है, तो sudo dpkg --configure -a वही मरम्मत करता है जो apt --fix-broken install करता है।

dnf सिस्टम पर वही कार्य

यदि आपका VPS Fedora या Rocky Linux जैसे RHEL-आधारित सिस्टम पर चलता है, तो इसकी कार्यप्रणाली उल्टी है। Debian और Ubuntu में kernels को apt autoremove नियमों द्वारा सुरक्षित रखा जाता है और cleanup का कार्य आप पर या unattended-upgrades पर छोड़ दिया जाता है। इसके विपरीत, dnf में installonly_limit नामक एक count लागू होता है, जो नए kernel के install होते ही पुराने kernels की संख्या सीमा पार होने पर उन्हें स्वचालित रूप से हटा देता है। वर्तमान में लागू मान को grep installonly_limit /etc/dnf/dnf.conf और man 5 dnf.conf के साथ देखें, और मौजूदा backlog को साफ करने के लिए sudo dnf remove --oldinstallonly का उपयोग करें। यहाँ भी चल रहे (running) kernel को सुरक्षित रखा जाता है। दोनों package managers के बीच व्यापक तुलना के लिए, dnf और apt कमांड के समकक्ष देखें।

इसे दोबारा होने से रोकें

सफाई का काम जो आपकी याददाश्त पर निर्भर है, वह अंततः विफल हो जाएगा, इसलिए इसे उस प्रक्रिया में शामिल करें जो kernel इंस्टॉल करती है। /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 ने अंततः क्या परिणाम दिया है, और एक ऐसे run को देखें जो कुछ भी नहीं बदलता है:

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 को record करता है, इसलिए जगह की कमी के कारण विफल हुआ upgrade किसी के यह नोटिस करने से बहुत पहले ही वहाँ दिखाई दे जाता है कि मशीन patches में पीछे है। उस configuration का शेष भाग Ubuntu पर automatic security updates में कवर किया गया है।

अगले kernel के आने से पहले एक संख्या की जाँच करनी है, और यह इस guide की शुरुआत में दिए गए commands का वही जोड़ा है:

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

यदि Avail उस file से पर्याप्त रूप से बड़ा नहीं है, तो अगला kernel ठीक वैसे ही विफल हो जाएगा जैसा ऊपर बताया गया है, इसलिए upgrade के दौरान के बजाय इसे अभी ठीक करें। यह जाँच आपके अन्य VPS पर disk health checks के साथ एक मिनट का समय देने योग्य है। release upgrade से ठीक पहले यह सबसे अधिक मायने रखता है, क्योंकि Ubuntu 24.04 को 26.04 पर ले जाना प्रक्रिया की शुरुआत में ही एक नया kernel इंस्टॉल करता है और जब /boot में जगह कम होती है तो do-release-upgrade आगे बढ़ने से मना कर देता है। यदि आपके LTS server को अभी तक वह upgrade offer नहीं किया गया है, तो इसका कारण कोई खराबी नहीं बल्कि समय है, क्योंकि Ubuntu LTS से LTS upgrades को 26.04.1 point release के आने तक रोक कर रखता है, जो आपको /boot को व्यवस्थित करने के लिए एक निश्चित समय सीमा देता है।

FAQ

Ubuntu पुराने kernels को डिलीट करने के बजाय क्यों रखता है?

क्योंकि यदि कोई kernel बूट होने में विफल रहता है, तो आपके पास चुनने के लिए कुछ नहीं बचेगा। पिछले वर्ज़न को रखने का अर्थ है कि एक खराब अपडेट के बाद आप GRUB मेनू से सिस्टम को रिकवर कर सकते हैं, न कि किसी प्रोवाइडर कंसोल के माध्यम से। apt इसलिए kernel पैकेजों के एक सेट को स्वचालित रूप से हटाने से बचाता है, जिसमें हमेशा वह वर्ज़न शामिल होता है जिसे आप वर्तमान में चला रहे हैं। यह देखने के लिए कि आपका रिलीज़ किन पैटर्न्स को सुरक्षित रखता है, apt-config dump | grep -i neverautoremove चलाएं, क्योंकि अलग-अलग रिलीज़ के बीच यह पॉलिसी बदलती रहती है।

क्या प्रोडक्शन सर्वर पर apt autoremove --purge चलाना सुरक्षित है?

हाँ, बशर्ते आप पहले ड्राई रन (dry run) को ध्यान से पढ़ें। sudo apt autoremove --purge --dry-run चलाएं, जो कुछ भी डिलीट नहीं करता है, और प्रिंट की गई सूची की जाँच करें। यदि इसमें linux-generic या linux-image-generic जैसा कोई मेटा पैकेज शामिल है, तो रुक जाएं, क्योंकि इनमें से किसी एक को हटाने से भविष्य के kernel अपडेट बंद हो जाएंगे। यदि इसमें वह वर्ज़न स्ट्रिंग शामिल है जिसे uname -r प्रिंट करता है, तो भी रुक जाएं। यदि इनमें से कुछ भी नहीं दिखता है, तो हटाए जाने वाले पैकेज केवल पुराने kernels और अनाथ (orphaned) डिपेंडेंसीज़ हैं।

apt autoremove ने कुछ भी नहीं हटाया और /boot अभी भी फुल है। अब क्या करें?

पुराने kernels संभवतः 'manual' के रूप में चिह्नित हैं, और autoremove केवल उन्हीं पैकेजों को हटाता है जो 'automatic' के रूप में चिह्नित होते हैं। apt-mark showmanual | grep -E '^linux-' चलाएं। वहां सूचीबद्ध कोई भी वर्ज़न वाला kernel किसी समय मैन्युअल रूप से इंस्टॉल किया गया था। इसे sudo apt-mark auto linux-image-<version> के साथ 'automatic' के रूप में चिह्नित करें और फिर से ड्राई रन चलाएं, या उस एक वर्ज़न को सीधे sudo apt purge linux-image-<version> के साथ हटा दें।

क्या मैं /boot से फाइलें मैन्युअल रूप से डिलीट कर सकता हूँ?

केवल एक बार के विशेष उपाय के रूप में, जब /boot इतना फुल हो कि apt टूटे हुए kernel पैकेज को कॉन्फ़िगर न कर सके। एक ऐसी सिंगल initrd.img-<version> फाइल डिलीट करें जिसका वर्ज़न uname -r का आउटपुट नहीं है, फिर तुरंत sudo apt --fix-broken install, sudo apt autoremove --purge और sudo update-grub चलाएं। इन फॉलो-अप स्टेप्स के बिना फाइलें डिलीट करने से dpkg उन पैकेजों को रिकॉर्ड करता रहेगा जिनकी फाइलें गायब हो चुकी हैं और GRUB मेनू एंट्रीज़ ऐसी फाइलों की ओर इशारा करेंगी जो मौजूद नहीं हैं, जिससे मशीन अगली बार बूट होने पर विफल हो जाएगी।