<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 22, 2021 at 9:17 PM Valdis Klētnieks <<a href="mailto:valdis.kletnieks@vt.edu">valdis.kletnieks@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 23 Mar 2021 00:01:22 +0200, Gidi Gal said:<br>
<br>
> Many thanks for your reply, Aruna. Is there a way to remove the installed<br>
> '5.12.0-rc3-GIDI_DEV+' kernel ? </blockquote><div><br></div><div>Yes there are 'many' ways to remove a kernel :-)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A reverse command for the 'sudo make<br>
> modules_install install' command ? I found this link which explains how to<br>
> do it manually (<br>
> <a href="https://www.cyberciti.biz/faq/debian-redhat-linux-delete-kernel-command/" rel="noreferrer" target="_blank">https://www.cyberciti.biz/faq/debian-redhat-linux-delete-kernel-command/</a>),<br>
> I wonder if there is a safer way.<br></blockquote><div><br></div><div>Type linux into your shell then press the 'tab' key twice.. you will see a list of commands.<br></div><div><br></div><div>Use : linux-check-removal <uname-r of your kernel to remove><br></div><div></div><div><br></div><div>Once you are comfortable with compiling + linking/building +running a custom kernel</div><div>what is preventing you from writing 'your own command' to do exactly that ? Say a bash</div><div>script ? Or Python program ?  <br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I can't speak for Debian, but I've used both the RedHat rpm method and just<br>
using the 'rm' command for self-bullt kernels since the 2.5.47 kernel or so<br>
(Egads, that was November 2002).  As long as you follow the directions, you<br>
should be OK.  'rm' can get dangerous if you get over-exuberant with using '*'<br>
characters, but you already knew that, right? :)<br></blockquote><div><br></div><div>If you have to use rm always use it with the -i flag. Always prompt before removal.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
And if you followed my recommendation and back up /boot, you'll be all<br>
set to restore whatever you mess up.  </blockquote><div><br></div><div>Listen to Valdis in this case and follow orders religioulsy. Back up not just /boot but anything <br>and everything that is important for you. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The running kernel will work just fine<br>
as long as you don't reboot. And unless you did 'rm /boot/*', you should have<br>
at least one usable kernel left...<br>
<br>
Seriously - if you're not comfortable with that level of sysadmin procedures,<br>
maybe you shouldn't be a kernel hacker... </blockquote><div><br></div><div>Do not listen to Valdis in this case as we were all newbies at one time like Dan Carpenter told me</div><div>which I will remember to my dying day. Do not let anyone tell you what you can or cannot do when it</div><div>come's to the kernel because believe me like me you will find out over time the kernel is a living thing that</div><div>has very subtle ways of informing you when you did something and it is not happy :-) <br><br>So compile away to your hearts content and go ahead and break things like I did that is actually a very good way to learn. <br></div><div>And listen to more experienced folk like Valdis who probably knows more about all the subsystems than anyone. But if anyone tells you <br></div><div>you should not be a kernel hacker then prove them wrong ? Actually that is Valdis's way of motivating you.</div><div><br></div><div>So good luck and we are here if you have questions :-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">there is always the possibility of<br>
something you didn't know about trashing your system.  See 5.12.0-rc1-dontuse<br>
for a nasty bug with file-backed swap that would stomp all over a section of your<br>
filesystem, and there was an ext[34] (can't remember anymore) bug during 2.5<br>
that would trash the filesystem when you *unmounted* it.  So you could boot the<br>
new kernel for testing, shutdown and boot the older version, and find it<br>
won't boot and be blaming the older version until we figured out what was<br>
happening. :)<br>
<br>
But seriously - if you have a good backup of the system, and an bootable<br>
external image that you can use for rescue, there's not much a kernel screw-up<br>
can do to permanently lose date.<br></blockquote><div><br></div><div>Agreed 110%. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Of course, WIndows Update is at that same level of reliability, so "knowing how<br>
to recover a trashed system" is an important skill no matter what OS you run :) <br></blockquote><div><br></div><div> Hope this helps - Aruna<br></div></div></div>