Ubuntu VPS वर पुढील boot साठी kernel कसा pin करावा

तुमचे VPS पुढील वेळी कोणता kernel boot करेल हे काय ठरवते

तुमचे VPS पुढील वेळी कोणता kernel boot करेल हे एका generated file मुळे ठरते: /boot/grub/grub.cfg. ही file तुम्ही कधीही थेट edit करू नका. तिच्या input files मध्ये बदल करा आणि ती पुन्हा generate करा. Ubuntu cloud image मध्ये यापैकी एक input image vendor कडून येतो. त्यामुळे menu selection लागू न होण्याची शक्यता असते. म्हणूनच rented server वर GRUB_DEFAULT=1 नंतर update-grub चालवूनही काही बदल होत नाहीत, तर laptop install वर हेच दोन steps कार्य करतात.

हे काम पुढील क्रमाने करा. kernel निवडण्याचा अधिकार तुमच्याकडे आहे का ते निश्चित करा. Vendor ने जोडलेल्या files सहित प्रत्येक input file वाचा. Generated output वाचा आणि त्यात प्रत्यक्ष किती entries आहेत ते मोजा. त्यानंतरच pinning method निवडा. ज्या machine ला तुम्ही फक्त SSH द्वारे access करता, त्यावर ही प्रक्रिया चुकीची केल्यास rescue console ची आवश्यकता पडू शकते. त्यामुळे या page च्या शेवटी दिलेले safest answers वापरणे योग्य ठरते; अनेकदा तेच योग्य पर्याय असतात.

तुम्ही pin करू शकत असलेला kernel तुमचाच आहे का ते प्रथम तपासा

uname -r
systemd-detect-virt
ls -1 /boot/vmlinuz-*

systemd-detect-virt चे output kvm, qemu किंवा xen दाखवत असल्यास, तुम्ही स्वतःचा kernel चालवत आहात आणि खालील सर्व माहिती लागू होते. lxc किंवा openvz चे output दाखवत असल्यास, तुमचा server host चा kernel share करतो. त्यामुळे तुमचा bootloader नसतो आणि pin करण्यासाठी काहीही नसते. अशा वेळी uname -r अशी version दाखवते जी /boot/vmlinuz-* मध्ये अजिबात दिसत नाही. याचे कारण चालू kernel host चा असतो आणि तुमच्या disk वरील कोणत्याही setting ने तो बदलता येत नाही.

ls -1 /boot/vmlinuz-* ही तुम्ही निवडू शकत असलेल्या kernels ची प्रत्यक्ष यादी आहे. त्यात एकच ओळ असल्यास, मागील kernel आधीच delete केलेला आहे. कोणतीही bootloader setting तो पुन्हा आणू शकत नाही. हे सहसा autoremove दरम्यान घडते. तुम्हाला महत्त्वाच्या box वर Ubuntu वरील जुने kernels साफ करण्यापूर्वी हे समजून घेणे उपयुक्त ठरेल.

तुम्ही संपादित करत असलेली फाइल GRUB वाचत नाही

/etc/default/grub मध्ये साध्या shell variable assignments असतात. ती input फाइल आहे. /boot/grub/grub.cfg ही output फाइल आहे आणि तिची सुरुवात # DO NOT EDIT THIS FILE तसेच कारणाने होते. तुम्ही output मध्ये लिहिलेली कोणतीही गोष्ट पुढच्या वेळी kernel package install किंवा remove केल्यावर नष्ट होते, कारण ते package scripts ही फाइल पुन्हा तयार करतात.

cat /usr/sbin/update-grub

update-grub हा wrapper आहे. तो grub-mkconfig -o /boot/grub/grub.cfg चालवतो. grub-mkconfig -o /boot/grub/grub.cfg variables वाचतो, /etc/grub.d/ मधील प्रत्येक script चालवतो आणि त्याचा result लिहितो. दोन commands, एकच दिशा: inputs आत जातात आणि grub.cfg बाहेर येते.

तुमची सेटिंग कोणती गोष्ट अधिलिखित करते: /etc/default/grub.d

grep -rn '^[^#]' /etc/default/grub /etc/default/grub.d/

दुसरा path अनेकदा दुर्लक्षित राहतो. grub-mkconfig प्रथम /etc/default/grub ला source करते. त्यानंतर /etc/default/grub.d/ मधील प्रत्येक *.cfg file glob क्रमाने source केली जाते. हे करणारा code वाचा:

grep -n 'default/grub' /usr/sbin/grub-mkconfig

Sourcing ही साधी shell प्रक्रिया आहे. त्यामुळे शेवटची assignment लागू राहते. Ubuntu cloud images या directory मध्ये files देतात. तुमची file वाचल्यानंतर त्या timeout आणि kernel command line सारख्या settings सेट करतात. /etc/default/grub मधील तुमची GRUB_TIMEOUT=10 काही क्षणांनी vendor file मुळे अधिलिखित होते; ती file तिची किंमत 0 सेट करते. वरील grep तुमच्या image मधील अचूक assignments दाखवते. त्यामुळे या वाक्यावर विश्वास ठेवण्याऐवजी त्या assignments तपासा.

यातून व्यावहारिक नियम असा मिळतो: /etc/default/grub संपादित करण्याऐवजी तुमच्या settings शेवटी क्रमबद्ध होणाऱ्या file मध्ये ठेवा, उदाहरणार्थ /etc/default/grub.d/99-local.cfg. त्यामुळे image मधून आलेली कोणतीही file तुमच्या settings नंतर लागू होऊ शकत नाही.

GRUB_FORCE_PARTUUID मुळे मेनूची निवड का अप्रासंगिक ठरते

grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/
grep -n GRUB_FORCE_PARTUUID /etc/grub.d/10_linux
sudo grep -n 'root=PARTUUID' /boot/grub/grub.cfg

GRUB_FORCE_PARTUUID जनरेटरला root filesystem partition UUID द्वारे शोधण्यास सांगते. हे थेट kernel command line वर root=PARTUUID=... म्हणून लिहिले जाते. त्यामुळे boot वेळी filesystem UUID शोधण्याची गरज राहत नाही. image vendor ही setting वापरतो, कारण त्यामुळे एखाद्या विशिष्ट hardware वर तयार न केलेली disk image देखील वेगवेगळ्या hardware वर विश्वसनीयपणे boot होते. दुसऱ्या grep मधून /etc/grub.d/10_linux मधील या variable वर प्रक्रिया करणारा code दिसतो. ही script तुमच्या स्वतःच्या disk वर आहे. तुमची image नेमके काय करते याबाबत तीच अंतिम प्रमाण मानली जाते.

येथे महत्त्वाचा परिणाम असा आहे: या मार्गावर generator installed kernels ची संपूर्ण यादी न बनवता थेट boot entry लिहितो. शेवटी किती entries तयार झाल्या ते मोजा.

sudo grep -cE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg
sudo grep -nE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg

जर count 1 असेल, तर निवडण्यासाठी दुसरी entry नसते. त्यामुळे GRUB_DEFAULT=1 अशा entry चे नाव देते जी अस्तित्वातच नाही. GRUB ती resolve करू शकत नाही. म्हणून ते पहिली entry boot करते. हीच तुम्ही टाळू इच्छित असलेली नवीन kernel असते. grub-set-default देखील मदत करत नाही, कारण समस्या default मध्ये नाही. तुम्ही ज्या मेनूमधून निवड करण्याचा प्रयत्न करत आहात तो मेनू तयारच झाला नव्हता.

संपूर्ण मेनू पुन्हा मिळवण्यासाठी vendor file बाजूला हलवा आणि बदल लागू करण्यापूर्वी त्याचा परिणाम preview करा. grub-mkconfig सोबत -o न दिल्यास output standard output वर लिहिले जाते आणि disk वरील कोणतीही गोष्ट बदलली जात नाही.

sudo grub-mkconfig 2>/dev/null | grep -cE '^\s*(menuentry|submenu) '
sudo mkdir -p /root/grub-backup
sudo mv /etc/default/grub.d/<the file your grep named> /root/grub-backup/
sudo grub-mkconfig 2>/dev/null | grep -cE '^\s*(menuentry|submenu) '

count 1 वरून अनेक entries पर्यंत वाढत असेल, तर forcing काढल्यानंतर entries दिसू लागल्या आहेत. अद्याप काहीही लिहिले गेलेले नाही. दुसरा count योग्य दिसत नसेल, तर file पुन्हा पूर्ववत ठेवा. कारण forced PARTUUID मुळे तुमच्या provider ची image तिचे root filesystem शोधते. ते काढल्यास मशीन search path वर जाते. प्रत्यक्षात update-grub चालवण्यापूर्वी snapshot घ्या.

तुमचा एकमेव उद्देश एखाद्या खराब kernel नंतर system चालू ठेवणे असेल, तर येथेच थांबा आणि पुढे दिलेले अधिक सुरक्षित पर्याय वापरा. एका upgrade मधून बाहेर पडण्यासाठी remote server वरील boot menu पुन्हा तयार करणे, या समस्येच्या तुलनेत अनावश्यक जोखीम निर्माण करते.

प्रवेश क्रमांक पिन करण्यासाठी चुकीचे पर्याय का आहेत

GRUB_DEFAULT क्रमांक, शीर्षक किंवा identifier स्वीकारते. क्रमांक 0 पासून top-level entries मोजतात. नेस्टेड entry साठी > separator म्हणून वापरले जाते. त्यामुळे GRUB_DEFAULT="1>2" म्हणजे index 1 वरील submenu मधील index 2 वरील entry.

Indices बदलतात. 10_linux kernels नवीनतम क्रमाने दाखवते. त्यामुळे kernel install केल्यावर प्रत्येक जुनी entry एक क्रमांक खाली जाते आणि kernel काढल्यावर त्या पुन्हा एक क्रमांक वर येतात. तुमचे काळजीपूर्वक तयार केलेले 1>2 त्यानंतरही resolve होते. मात्र आता ते वेगळ्या kernel चे नाव दर्शवते. कोणतीही error येत नाही आणि कोणतीही warning दिसत नाही. याची जाणीव reboot केल्यानंतर होते.

Identifiers बदलत नाहीत, कारण प्रत्येक identifier मध्ये kernel version असते. तुमचे identifier पाहण्यासाठी:

sudo awk -F"'" '/menuentry_id_option/ {print $2, "==>", $4}' /boot/grub/grub.cfg

Output मधील सुरुवातीच्या काही lines कडे दुर्लक्ष करा. त्या header मध्ये define केलेले variable असतात. त्यानंतर डावीकडील भाग हा reader ला दिसणारा title असतो आणि उजवीकडील भाग हा tools कडे pass करायचा identifier असतो. Submenu मधील entry साठी submenu identifier आणि entry identifier > ने, याच क्रमाने, जोडावे. Numeric form प्रमाणेच हा क्रम ठेवावा.

grub-reboot वापरून मागील kernel एकदा सुरू करा

Remote server वर एकदाच केलेली निवड योग्य ठरते, कारण तिचा परिणाम आपोआप पूर्ववत होतो. grub-reboot हे /boot/grub/grubenv मध्ये next_entry लिहिते. GRUB हे variable वाचते, ते साफ करते आणि कोणतीही गोष्ट boot करण्यापूर्वी साफ केलेली value जतन करते. त्यामुळे panic झालेला kernel पुढील boot वेळी पुन्हा वापरला जात नाही. तुम्हाला एक प्रयत्न मिळतो आणि त्यानंतर मशीन स्वतःहून नेहमीच्या default वर परतते.

सर्वप्रथम तुमच्या generated config मध्ये हे variable वाचले जाते का ते तपासा:

sudo grep -n -B2 -A5 'next_entry' /boot/grub/grub.cfg

तुम्हाला load_env अशी line आणि next_entry मधून default सेट करणारा block दिसायला हवा. grep ने काहीही दाखवले नाही, तर boot वेळी तुमची image grubenv वाचत नाही. त्यामुळे grub-reboot हे shell मध्ये स्वीकारले जाईल, पण bootloader त्याकडे दुर्लक्ष करेल. मागील section मधील forced direct boot path दुसऱ्या ठिकाणी दिसण्याचे हेच उदाहरण आहे.

sudo grub-reboot '<the identifier you copied>'
sudo grub-editenv list

आता grub-editenv list ने तुम्ही दिलेली value जशीच्या तशी असलेली next_entry= line दाखवायला हवी. तुमच्या provider चे console browser tab मध्ये उघडा. त्यानंतर reboot करून परिणाम तपासा.

sudo reboot

uname -r

uname -r ने जुनी version दाखवली, तर pin यशस्वी झाला आहे. नवीन version दाखवली, तर identifier resolve झाला नाही किंवा grubenv वाचले जात नाही. कोणत्याही परिस्थितीत मशीन सुरू आहे. One shot form वापरण्याचा हाच उद्देश आहे.

GRUB_DEFAULT=saved सह निवड कायम ठेवा

GRUB_DEFAULT=saved मुळे default मूल्य grubenv मधील saved_entry कडून घेतले जाते आणि हे मूल्य grub-set-default वापरून सेट करता येते. Kernel install केल्यानंतरही हे कायम राहते, कारण update-grub, grub.cfg पुन्हा लिहिताना grubenv ला कधीही बदलत नाही.

echo 'GRUB_DEFAULT=saved' | sudo tee /etc/default/grub.d/99-local.cfg
sudo update-grub
sudo grub-set-default '<the identifier you copied>'
sudo grub-editenv list
sudo grep -n 'set default' /boot/grub/grub.cfg

शेवटच्या command ने set default="${saved_entry}" print केले पाहिजे. जर set default="0" print झाले, तर तुमच्या file नंतर source झालेल्या कोणत्यातरी file ने GRUB_DEFAULT पुन्हा literal value वर सेट केले आहे. त्यामुळे /etc/default/grub.d/ पुन्हा list करा आणि 99-local.cfg खरोखर शेवटी sort होत आहे का ते तपासा.

GRUB_SAVEDEFAULT=true ही वेगळी setting आहे आणि तिचा या setting सोबत सहज गोंधळ होतो. तुम्ही नुकतेच boot केलेली entry नवीन default म्हणून ती जतन करते. त्यामुळे default शेवटच्या यशस्वी boot नुसार बदलतो. Server वर याचा अर्थ unattended reboot मुळे तुमचा pin शांतपणे बदलू शकतो. तुम्हाला हेच अपेक्षित असेल तरच ते सुरू ठेवा.

Identifier वापरून केलेला pin एका बाबतीत तरी अपयशी ठरतो. त्यात नमूद केलेला kernel काढून टाकल्यास तो identifier resolve होत नाही आणि default पुन्हा पहिल्या entry वर येतो. त्यामुळे package देखील hold करा किंवा तो kernel autoremove मधून वगळा.

प्रदाता कन्सोलवर मेन्यू दाखवणे

परस्परसंवादी निवडीसाठी मेन्यू स्क्रीनवर दिसणे आवश्यक असते, परंतु cloud images ते लपवतात. या ओळी शेवटी क्रमाने येणाऱ्या फाइलमध्ये ठेवा आणि त्यानंतर sudo update-grub चालवा.

GRUB_TIMEOUT=10
GRUB_TIMEOUT_STYLE=menu
GRUB_RECORDFAIL_TIMEOUT=10

GRUB_TIMEOUT_STYLE=hidden आणि GRUB_TIMEOUT=0 एकत्र वापरल्यावर काहीही दिसत नाही. त्यामुळे कन्सोल पाहणाऱ्या व्यक्तीला kernel messages लगेच सुरू झाल्याचे दिसते आणि bootloader वगळला गेला असा निष्कर्ष निघतो. GRUB_RECORDFAIL_TIMEOUT हा boot पूर्ण न झाल्यानंतर वापरला जाणारा स्वतंत्र timeout आहे. cloud images तोही 0 वर ठेवतात. त्यामुळे नुकताच boot होण्यात अयशस्वी झालेला server तुमच्यासाठी थांबून प्रतीक्षा करत नाही.

तुमचा provider graphical console ऐवजी serial console देत असेल आणि तरीही काहीही दिसत नसेल, तर GRUB तुम्हाला दिसत नसलेल्या terminal वर लिहित आहे. दोन्ही ओळी एकत्र जोडा. पहिली ओळ outputs निवडते आणि दुसरी port configure करते:

GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"

आतापासून प्रत्येक boot साठी दहा सेकंदांचा अवधी जोडला जाईल. काम पूर्ण झाल्यावर timeout पुन्हा 0 वर सेट करा.

बूटलोडर संपादित करण्यापेक्षा सुरक्षित पर्याय

फक्त SSH द्वारे प्रवेश करता येणाऱ्या मशीनवर bootloader input बदलणे हा या पृष्ठावरील सर्वाधिक जोखमीचा पर्याय आहे. यापेक्षा सोपे पर्याय उपलब्ध आहेत आणि ते सहसा मूळ समस्या सोडवतात.

Kernel packages hold करा. उद्देश "नवीन kernel देऊ नका" असा असेल, तर ही सूचना bootloader ऐवजी package manager ला द्या.

apt list --installed 2>/dev/null | grep -E '^linux-(image|headers|generic|virtual|kvm|aws|azure|gcp|oracle)'
sudo apt-mark hold linux-image-virtual linux-headers-virtual
apt-mark showhold

पहिल्या command ने दाखवलेली नावेच वापरा, कारण cloud images मध्ये अनेकदा generic flavour ऐवजी virtual किंवा kvm flavour install केलेले असते. Held package apt upgrade द्वारे वगळले जाते आणि ते The following packages have been kept back: द्वारे जाहीर केले जाते. Ubuntu मधील unattended upgrades मधूनही ते वगळले जाते. याची वास्तविक किंमत आहे: held kernel ला security fixes मिळत नाहीत. त्यामुळे ही तारीख निश्चित केलेली तात्पुरती स्थगिती समजा आणि sudo apt-mark unhold द्वारे hold काढा. Reboot मुळे downtime होत असल्याने kernel updates टाळत असाल, एखादा kernel खराब असल्यामुळे नव्हे, तर त्यासाठी VPS वर live kernel patching हा पर्याय वापरा.

Upgrade करण्यापूर्वी snapshot घ्या. Snapshot काही मिनिटांत restore करता येतो. त्यासाठी console वर typing करण्याची गरज नसते आणि bootloader बदल अर्धवट लागू होण्याचा धोका नसतो. Snapshot घ्या, upgrade करा, reboot करा आणि पडताळणी करा. नवीन kernel मध्ये समस्या आल्यास rollback करा. Boot path अगदी पूर्वीसारखाच राहतो.

जे box आधीच बंद आहे त्यासाठी console किंवा rescue image वापरा. Server boot होत नसताना bootloader config मध्ये बदल करून समस्या सोडवता येत नाही. Recovery path ही स्वतंत्र प्रक्रिया आहे: kernel update नंतर VPS boot होत नसल्यास काय करावे.

काय बिघडते आणि तुम्हाला कोणता संदेश दिसेल

/boot/grub/grub.cfg मधील तुमचे संपादन नाहीसे झाले. Kernel package install किंवा remove झाले, त्याची maintainer script update-grub चालली आणि input पासून file पुन्हा तयार झाली. # DO NOT EDIT THIS FILE header मध्ये त्या दोन input locations ची नावे दिलेली असतात. त्याच ठिकाणी संपादन करा.

grub-editenv: error: environment block too small. /boot/grub/grubenv हरवले आहे किंवा अपूर्ण आहे. sudo grub-editenv /boot/grub/grubenv create वापरून ते पुन्हा तयार करा. त्यानंतर तुमचे value पुन्हा set करा आणि sudo grub-editenv list वापरून त्याची खात्री करा.

Pinned kernel VFS: Unable to mount root fs on unknown-block(0,0) सह panic होतो. तुम्ही pin केलेली entry आता disk वर नसलेल्या kernel किंवा initrd कडे निर्देश करते. Identifier grubenv मध्ये राहिले असताना package remove झाल्यामुळे हे सहसा घडते. कार्यरत entry वर console boot करा आणि त्यानंतर stale value साफ करा.

तुम्ही बदल अपेक्षित केलेल्या reboot नंतर uname -r बदललेले नाही. पुढील तीन गोष्टी क्रमाने तपासा: grub-editenv list मध्ये अजून तुमचे value दिसत आहे का, की ते वापरले गेले; तुम्ही set केलेला identifier सध्याच्या grub.cfg मध्ये दिसतो का; grub.cfg मध्ये तुम्ही set केलेले variable वाचणारी set default line आहे का. या तीनपैकी एक कारण प्रत्येक वेळी स्पष्ट करते.

Crash नंतर menu आपोआप दिसले. GRUB grubenv मध्ये failed boot ची नोंद recordfail=1 म्हणून करतो. त्यामुळे पुढील boot वेळी menu दाखवले जाते, जेणेकरून मानव हस्तक्षेप करू शकेल. Machine व्यवस्थित झाल्यावर sudo grub-editenv /boot/grub/grubenv unset recordfail वापरून ते साफ करा.

लक्षात ठेवण्यासारखे एक वाक्य: तुम्ही edit करता ती file GRUB वाचत असलेल्या file पेक्षा वेगळी आहे. Cloud image मध्ये या दोन्हीमधील अंतरच गोंधळाचे मुख्य कारण असते. सर्वप्रथम generated config वाचा. या पृष्ठावरील प्रत्येक निर्णय त्यात प्रत्यक्ष काय लिहिले आहे यावर आधारित आहे.

FAQ

GRUB_DEFAULT=1 बदलल्यावर माझ्या VPS वर कोणते kernel boot होते ते का बदलत नाही?

Ubuntu cloud image मध्ये निर्माण झालेल्या /boot/grub/grub.cfg मध्ये अनेकदा एकच boot entry असते. त्यामुळे index 1 कोणत्याही entry ला दर्शवत नाही आणि GRUB पहिल्या entry वर fallback करतो. sudo grep -cE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg ने याची पुष्टी करा. Count 1 हे याचे उत्तर आहे. याचे कारण म्हणजे GRUB_FORCE_PARTUUID. Image vendor हे /etc/default/grub.d/ अंतर्गत असलेल्या file मध्ये सेट करतो. त्यामुळे generator installed kernels ची पूर्ण list तयार करण्याऐवजी direct boot path वापरतो. grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/ ने ती file शोधा.

मागील kernel फक्त एकदा कसे boot करावे?

तुमच्या स्वतःच्या grub.cfg मधून identifier घेऊन sudo grub-reboot '<identifier>' चालवा. त्यानंतर provider console आधीच उघडी ठेवून reboot करा. Boot करण्यापूर्वी GRUB next_entry साफ करतो. त्यामुळे ही निवड नेमक्या एका प्रयत्नासाठी लागू होते आणि panic झालेला kernel पुन्हा प्रयत्न केला जात नाही. sudo grub-editenv list ने value लागू झाली आहे का ते तपासा. यावर अवलंबून राहण्यापूर्वी sudo grep -n next_entry /boot/grub/grub.cfg चालवा. कारण configuration मध्ये grubenv load होत नसेल, तर command कोणतीही error न दाखवता दुर्लक्षित केली जाईल.

Entry number वापरून pin करावे की identifier वापरून?

Identifier वापरा. Entry numbers ही 10_linux नवीन entries प्रथम ठेवून पुन्हा तयार करत असलेल्या list मधील positions असतात. त्यामुळे कोणताही kernel install किंवा remove केल्यावर त्या बदलतात. जुना 1>2 तरीही अस्तित्वात असलेल्या पण चुकीच्या entry कडे resolve होऊ शकतो आणि याबद्दल कोणतीही warning दिली जात नाही. Identifiers मध्ये kernel version असते. त्यामुळे ते तुम्हाला अपेक्षित असलेल्या kernel शी जुळतात किंवा resolve होत नाहीत. sudo grep -n menuentry_id_option /boot/grub/grub.cfg ने त्यांची list दाखवा आणि प्रत्येक entry line नंतर असलेली quoted string copy करा.

Bootloader बदलण्यापेक्षा kernel package hold करून ठेवणे अधिक सुरक्षित आहे का?

सामान्य उद्दिष्टासाठी, होय. sudo apt-mark hold linux-image-virtual linux-headers-virtual नवीन kernel येऊच देत नाही. त्यामुळे boot path बदलत नाही आणि कदाचित उपलब्ध नसलेल्या console मधून चूक होण्याची शक्यता राहत नाही. तुमच्या स्वतःच्या box वर install असलेली flavour names प्रथम apt list --installed ने तपासा आणि hold लागू आहे का ते apt-mark showhold ने पडताळा. याचा तोटा असा की held kernel ला security fixes मिळत नाहीत. त्यामुळे hold करण्यापूर्वी sudo apt-mark unhold कधी चालवायचे ते ठरवा.