Thanks Aruna and Valdis for your replies.

Use : linux-check-removal <uname-r of your kernel to remove>
>

I tried to use it on my kernel. It did not seem to work - I still see the
files in /boot. I assume it is because my kernel is not signed properly.
When I launch "dpkg --list | grep linux-image" I don't see my kernel in the
list. When I reboot I still get an "invalid signature" error. I attach the
build log, install log and .config file and x509.genkey file in this link
<https://drive.google.com/drive/folders/1mVUzrF_5MM4H1x0bLacprvkrXaKtFm6V?usp=sharing>
in Google Drive (I tried attaching the files to the mail and got a message
saying there's an issue with their size). Please let me know what
additional input can help to analyze this issue.

Seriously - if you're not comfortable with that level of sysadmin
> procedures,
> maybe you shouldn't be a kernel hacker...
>

Once you are comfortable with compiling + linking/building +running a
> custom kernel
> what is preventing you from writing 'your own command' to do exactly that
> ? Say a bash
> script ? Or Python program ?
>

I gave up for now and prepared bash script for removing the files, based on
the information in
https://www.cyberciti.biz/faq/debian-redhat-linux-delete-kernel-command/
(see "A note about custom compiled Linux kernel" section). In my opinion,
if Makefile supports install, it should support uninstall as well. Please
let me know whether it sounds like a worthy enhancement or a wrong
expectation.

Aruna, thank you for your kind words. I promise not to be discouraged.
Continuing with my quest to become a kernel developer :-)

Thanks,
Gidi

On Tue, Mar 23, 2021 at 6:29 AM Aruna Hewapathirane <
aruna.hewapathirane@gmail.com> wrote:

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