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 real root mount करने से पहले unpack करता है)। Initramfs का निर्माण install के समय आपकी machine पर ही होता है, इसीलिए install के लिए केवल download bandwidth ही नहीं, बल्कि खाली disk space की भी आवश्यकता होती है। यदि जगह कम पड़ जाए, तो 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 आपकी machine के अनुसार होगी। Compressor का नाम /etc/initramfs-tools/initramfs.conf में मौजूद COMPRESS= से आता है, इसलिए हाल की image में zstd नाम हो सकता है, जबकि पुरानी image में gzip हो सकता है। इस समस्या की पहचान करने वाली दो पंक्तियाँ No space left on device और उसके नीचे मौजूद dpkg: error processing package पंक्ति हैं।

इसके बाद, package आधा-अधूरा configured रह जाता है। बाद में चलने वाला हर apt command इसे फिर से configure करने का प्रयास करता है, उसी तरह विफल हो जाता है, और E: Sub-process /usr/bin/dpkg returned an error code (1) के साथ समाप्त होता है। disk space के अलावा यह हिस्सा महत्वपूर्ण है: unattended-upgrades अपने timer पर चलता है, उसी error का सामना करता है, और रुक जाता है। सर्वर देखने में तो ठीक लगता है, लेकिन चुपचाप security patches लागू करना बंद कर देता है। इसका मतलब यह भी है कि आप जो भी unrelated install करने का प्रयास करेंगे, वह उसी line के साथ विफल हो जाएगा और दोष उस चीज़ पर मढ़ा जाएगा जिसे आप उस समय add कर रहे थे, इसीलिए 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 को hold करता है। यदि वे / के समान ही 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 की एक और pair के लिए जगह की आवश्यकता होती है, इसलिए यदि 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 line का अर्थ है कि 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 का अर्थ है कि पैकेज install और configure हो चुका है। iF का अर्थ है कि पैकेज install तो है लेकिन आधा-अधूरा configure हुआ है, जो कि ऊपर बताए गए failed upgrade का परिणाम है। rc का अर्थ है कि पैकेज हटा दिया गया है लेकिन उसकी configuration अभी भी disk पर मौजूद है, जो /boot में कोई जगह नहीं घेरती और इसे सुरक्षित रूप से purge किया जा सकता है।

दूसरा field बताता है कि पैकेज किस प्रकार का है। एक नाम जिसमें version शामिल हो, जैसे linux-image-6.8.0-64-generic, एक विशिष्ट kernel है। बिना version वाला नाम, जैसे linux-image-generic, linux-headers-generic या linux-generic, एक meta package है। इसमें कोई kernel नहीं होता। इसका एकमात्र कार्य नवीनतम version वाले kernel पर निर्भर रहना है ताकि apt upgrade नए kernels को install कर सके। 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 नहीं है, वह किसी के द्वारा मैन्युअल रूप से फाइलें हटाने का अवशेष है।

apt यह कैसे तय करता है कि किन kernels को रखना है

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

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

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

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

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

sudo apt autoremove --purge
df -h /boot

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

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

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

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

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

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

manual के रूप में चिह्नित meta packages को वैसा ही रहने दें। उन्हें 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 उत्तर दें। इसके बाद उन module और header packages को हटाने के लिए sudo apt autoremove --purge का उपयोग करें जिनका अस्तित्व अब समाप्त हो चुका है।

आप 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 कहीं और ले जाता है। मशीन traffic serve करना जारी रखती है और पहले से ही unbootable हो चुकी होती है। हर बार removal list के साथ uname -r को check करें।

जब /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 के किसी rebuild पर चलता है, तो इसकी कार्यप्रणाली उल्टी है। Debian और Ubuntu कर्नेल को apt autoremove नियमों के साथ सुरक्षित रखते हैं और सफाई का काम आप पर या unattended-upgrades पर छोड़ देते हैं, जबकि dnf में installonly_limit नामक एक संख्या निर्धारित होती है। जैसे ही कोई नया इंस्टॉलेशन इस सीमा को पार करता है, यह सबसे पुराने कर्नेल को स्वचालित रूप से हटा देता है। grep installonly_limit /etc/dnf/dnf.conf और man 5 dnf.conf के साथ वर्तमान में लागू मान को पढ़ें, और sudo dnf remove --oldinstallonly का उपयोग करके मौजूदा बैकलॉग को साफ करें। यहाँ भी चल रहा कर्नेल सुरक्षित रहता है। दोनों पैकेज मैनेजरों के बीच व्यापक मैपिंग के लिए, dnf और apt कमांड के समकक्ष देखें।

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

सफाई का काम जो आपकी याददाश्त पर निर्भर है, वह अंततः विफल हो जाएगा, इसलिए इसे उस प्रक्रिया में शामिल करें जो kernel 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 करें, न कि अंत में दूसरी copy जोड़ें। 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 install करता है और do-release-upgrade आगे बढ़ने से मना कर देगा जब /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 मेनू में ऐसी एंट्रीज़ रह जाएंगी जो गायब फाइलों की ओर इशारा करती हैं। इससे मशीन आपके द्वारा गलती करने के तुरंत बाद के बजाय अगले रीबूट पर विफल हो जाएगी।