VPS पुढच्या वेळी कोणता kernel बूट करेल ते pin करा

तुमचा VPS कोणता kernel बूट करेल हे कशावर ठरते

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

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

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

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

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

तुम्ही निवडू शकणाऱ्या kernels ची वास्तविक यादी ls -1 /boot/vmlinuz-* मध्ये असते. त्यात एकच line असल्यास मागील 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 चालवतो आणि परिणाम लिहितो. दोन commands, एकच दिशा: input आत जातो आणि 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 आधीच read झाल्यानंतर त्या files मध्ये timeout आणि kernel command line यांसारख्या settings सेट केल्या जातात. /etc/default/grub मधील तुमची GRUB_TIMEOUT=10 काही क्षणांनी vendor file मुळे overwrite होते. ती file हे मूल्य 0 वर सेट करते. वरील grep तुमच्या image मधील अचूक assignments दाखवतो. त्यामुळे या वाक्यावर अवलंबून न राहता त्या assignments तपासा.

यातून व्यवहार्य नियम असा आहे: तुमच्या स्वतःच्या settings शेवटी sort होणाऱ्या file मध्ये ठेवा, उदाहरणार्थ /etc/default/grub.d/99-local.cfg. /etc/default/grub संपादित करू नका. त्यानंतर 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 शोधण्याची गरज राहत नाही. ज्या hardware वर image तयार केलेली नाही, तिथेही एकच disk image विश्वसनीयपणे boot व्हावी म्हणून image vendor हे सेट करतो. दुसऱ्या 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 ती शोधू शकत नाही. म्हणून तो पहिली 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 वरून अनेकांपर्यंत वाढला, तर forcing काढल्यानंतर entries दिसत आहेत. अद्याप काहीही लिहिले गेलेले नाही. दुसरा count योग्य दिसत नसेल, तर file पुन्हा मूळ ठिकाणी ठेवा. तुमच्या provider ची image root filesystem शोधण्यासाठी forced PARTUUID वापरते. तो काढल्यास मशीन search path वापरू लागते. update-grub प्रत्यक्षात चालवण्यापूर्वी snapshot घ्या.

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

प्रवेश क्रमांक pin करणे चुकीचे का आहे

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

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

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

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 ओळ आणि 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= ओळ दाखवली पाहिजे. तुमच्या 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 मूल्य saved_entry मधून घेतले जाते. हे मूल्य तुम्ही grub-set-default वापरून grubenv मध्ये सेट करता. 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 झालेल्या एखाद्या घटकाने 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 झाल्यास तुमची निश्चित केलेली निवड शांतपणे बदलू शकते. हेच अपेक्षित असल्यासच ते सुरू ठेवा.

Identifier वापरून केलेली pinning एका परिस्थितीत तरी अपयशी ठरते. त्या identifier ने निर्दिष्ट केलेला 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 ऐवजी virtual किंवा kvm flavour सहसा install केले जाते. नवीन kernel image refresh च्या आसपास दिसला आणि release स्वतःच बदलला असावा असा संशय असल्यास, तसे झालेले नसते. कारण point release म्हणजे आधीपासून उपलब्ध updates नवीन install media मध्ये समाविष्ट केलेली आवृत्ती असते आणि आधीच patched असलेल्या server ला काही आठवड्यांपूर्वी उपलब्ध नसलेली कोणतीही गोष्ट मिळत नाही. Held package apt upgrade वगळते आणि ते The following packages have been kept back: द्वारे जाहीर करते. Ubuntu वरील unattended upgrades देखील ते package वगळतात. याची वास्तविक किंमत आहे: held kernel ला security fixes मिळत नाहीत. त्यामुळे त्याला ठरावीक तारखेपर्यंतची तात्पुरती स्थगिती समजा आणि sudo apt-mark unhold द्वारे hold काढा. एका kernel मध्ये समस्या आहे म्हणून नव्हे, तर reboot मुळे downtime येतो म्हणून kernel updates टाळत असाल, तर त्याऐवजी VPS वरील live kernel patching वापरा.

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

आधीच बंद असलेल्या मशीनसाठी console किंवा rescue image वापरा. Server boot होत नसेल, तर bootloader config ही समस्या सोडवण्याची योग्य जागा नाही. त्या recovery path साठी स्वतंत्र procedure आहे: 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 ची नावे आहेत. त्या locations मधील files संपादित करा.

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) सह kernel panic येतो. तुम्ही pin केलेली entry आता disk वर नसलेल्या kernel किंवा initrd कडे निर्देश करते. Identifier grubenv मध्ये तसाच राहिला असताना package remove झाल्यामुळे हे सहसा घडते. Recovery साठी console वरून कार्यरत entry ने boot करा. त्यानंतर stale value clear करा.

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

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

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

FAQ

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

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 वापरून याची खात्री करा. 1 ही count म्हणजे उत्तर आहे. याचे कारण GRUB_FORCE_PARTUUID आहे. Image vendor हा पर्याय /etc/default/grub.d/ अंतर्गत असलेल्या file मध्ये सेट करतो. त्यामुळे generator स्थापित kernels ची संपूर्ण यादी तयार करण्याऐवजी direct boot path वापरतो. grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/ वापरून ती file शोधा.

मागील kernel फक्त एकदाच कसा सुरू करायचा?

तुमच्या स्वतःच्या grub.cfg मधून identifier कॉपी करून sudo grub-reboot '<identifier>' चालवा. त्यानंतर provider console आधीच उघडी ठेवून reboot करा. GRUB boot करण्यापूर्वी 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 नुसार. 10_linux यादी नवीनतम kernel प्रथम अशा क्रमाने पुन्हा तयार करतो. त्यामुळे कोणताही kernel install किंवा remove केल्यावर entry numbers बदलतात. जुना 1>2 मात्र कोणतीही सूचना न देता वास्तविक पण चुकीच्या entry कडे resolve होऊ शकतो. Identifier मध्ये kernel version असते. त्यामुळे ते अपेक्षित kernel शी जुळते किंवा resolve होत नाही. sudo grep -n menuentry_id_option /boot/grub/grub.cfg वापरून identifiers ची यादी करा आणि प्रत्येक entry line नंतर असलेली quoted string कॉपी करा.

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

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