On Tue, Mar 23, 2021 at 10:37 AM Gidi Gal <gidi.gal.linux@gmail.com> wrote:

> 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. Please
> let me know what additional input can help to analyze this issue.
>
>
dpkg -i and make install are two very different beasts. See this answer it
will help you to understand why you are seeing the files in boot.
https://askubuntu.com/questions/1118896/software-installation-with-dpkg-i-vs-with-make-how-do-they-differ

The safest way would be to identify which kernel you want to remove first.
Change into /boot then use rm to delete the files one by one.
Then run sudo update-grub2 and reboot. And your good to go.



> 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.
>
>
Have a look at the make install and make clean sections in the Makefile.
Again nothing to stop you from having a 'delete' or 'remove' target eh ? :-)



> 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
>>
>