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