From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: ** X-Spam-Status: No, score=2.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EC36C433C1 for ; Tue, 23 Mar 2021 15:25:52 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1A85161983 for ; Tue, 23 Mar 2021 15:25:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1A85161983 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies-bounces+kernelnewbies=archiver.kernel.org@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94) (envelope-from ) id 1lOiul-0006Sn-8o for kernelnewbies@archiver.kernel.org; Tue, 23 Mar 2021 11:25:51 -0400 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1lOist-00051T-PG for kernelnewbies@kernelnewbies.org; Tue, 23 Mar 2021 11:23:55 -0400 Received: by mail-ed1-x529.google.com with SMTP id l18so15723400edc.9 for ; Tue, 23 Mar 2021 08:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4k4HgmH1n0e4wsoQI1J3gF6dBfxIue8R51jXVsZRWSg=; b=i25kNQcS23VGUoXHm6sELB7Ob7eDROmvsdzBepj4cYVWX7Ep5TV9eKN0w413RxXxiv uMF06ofGu9L5xp261LIJZrvT77NrRzwJKi642VYlqrCpm+5StIJFrWVLDezjjIZ1xgWo pOa+LxWVgZdbg3v65lx834yYj1UaEPKDH/T8g1nPq9ZjQP2sXJcMadJncbtDBI0/lw8Q 8Q3kAJeKjWo0sJsrDL+yHrUEA9XtXEyU2R6PhoP9ec+ClYuaY5B6L6Tx7i6/MPPydz2Q 0cTLaUSs5CE/CkzShmPYnpt0hK9KjL2a5hkn4qak/weIO0qYCsDsADNwzxxok+p58edj 8BQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4k4HgmH1n0e4wsoQI1J3gF6dBfxIue8R51jXVsZRWSg=; b=nibk8asEjG35pY2tgPNM+WT95in7ll+R/WF0NBOYa6PtD19X50ZqXBxCpoicHiALWt yOe/cDnYckwNzU4uX7f0m4Sjyno5M58RoYfSyw5MXARGyDj6GcQB+B9h9dVsuyMrrDwZ RHL36qHs8flVqqygqylS7ogUJYXBDJXdrLs3ZwwvxYJg8nQEUZrRg9cWXhFD1bld9ulb J+exzVModm3uB1iGBULpCE6raJrbTJY2h0SHD2pQ0eWCDbI6wDI3/sBf8J4FvWTskWKs GI//4CgV5bOup15FqEUMfUeMOZ3fj19RvyZzo8Fdjuo7rMEFIopjU/KxH8OfsQS/sP1j uVuA== X-Gm-Message-State: AOAM5337KQRYj1RITZn5dPLH3nYrx+5Nh35geoV51HBYqaq4TaqiQwNq trT8aVimglW7u6jFrV1cXS2lXxLME0HJI/fs/Z8= X-Google-Smtp-Source: ABdhPJzCGTCa3B+tysCT0RetpsqEcuwCcd3pYGMRl2A1n78MGRU1ARb0rgYbFpJmwuDOo1bzjn2QV6fmumMfpai01tY= X-Received: by 2002:a05:6402:4314:: with SMTP id m20mr4987116edc.5.1616513034074; Tue, 23 Mar 2021 08:23:54 -0700 (PDT) MIME-Version: 1.0 References: <87zgyvtkd8.fsf@miraculix.mork.no> <323555.1616462233@turing-police> In-Reply-To: From: Aruna Hewapathirane Date: Tue, 23 Mar 2021 11:23:43 -0400 Message-ID: Subject: Re: How to switch between installed kernel and developed kernel To: Gidi Gal Cc: Valdis Kletnieks , kernelnewbies X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9141219367122630908==" Errors-To: kernelnewbies-bounces+kernelnewbies=archiver.kernel.org@kernelnewbies.org --===============9141219367122630908== Content-Type: multipart/alternative; boundary="0000000000002bc04105be35c598" --0000000000002bc04105be35c598 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 23, 2021 at 10:37 AM Gidi Gal wrote: > Thanks Aruna and Valdis for your replies. > > Use : linux-check-removal >> > > 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 attac= h > 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-v= s-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 tha= t >> ? 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=C4=93tnieks >> 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 >> >> Once you are comfortable with compiling + linking/building +running a >> custom kernel >> what is preventing you from writing 'your own command' to do exactly tha= t >> ? 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 o= r >>> 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 shoul= d >>> 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 lik= e >> 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 durin= g >>> 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 i= t >>> won't boot and be blaming the older version until we figured out what w= as >>> happening. :) >>> >>> But seriously - if you have a good backup of the system, and an bootabl= e >>> 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 yo= u >>> run :) >>> >> >> Hope this helps - Aruna >> > --0000000000002bc04105be35c598 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Mar 23, 2021 at 10:37 AM Gidi= Gal <gidi.gal.linux@gmail.c= om> 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-im= age" I don't=C2=A0see my kerne= l in the list. When I reboot I still get an "invalid signature" e= rror. 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 iss= ue.


dpkg -i = and make install are two very different beasts. See this answer it will hel= p 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 w= ant 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 g= o.

=C2=A0
Seriously - if you're not comfortable with t= hat level of sysadmin procedures,
maybe you shouldn't be a kernel hacker...

Once you ar= e comfortable with compiling + linking/building +running a custom kernel
what is preventing you from writing 'your own command' to d= o exactly that ? Say a bash
script ? Or Python program ?=C2=A0

I gave up for now and prepared b= ash script for removing the files, based on the information in https://www.cyberciti.biz/faq/debian-redhat-linux-delete-ke= rnel-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 enhan= cement or a wrong expectation.

=
Have a look at the make install and make clean sections in t= he Makefile. Again nothing to stop you from having a 'delete' or &#= 39;remove' target eh ? :-)

=C2=A0
=
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=C4=93tnieks <= ;valdis.kletni= eks@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 instal= led
> '5.12.0-rc3-GIDI_DEV+' kernel ?

Yes there are 'many' ways to remove a kernel :-)

=
A reverse command f= or the 'sudo make
> modules_install install' command ? I found this link which explain= s how to
> do it manually (
> https://www.cyberciti.b= iz/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 wil= l see a list of commands.

Use : linux-check-re= moval <uname-r of your kernel to remove>
Once you are comfortable with compiling + linking/building +run= ning a custom kernel
what is preventing you from writing 'you= r own command' to do exactly that ? Say a bash
script ? Or Py= thon program ?=C2=A0
=C2=A0
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 kern= el or so
(Egads, that was November 2002).=C2=A0 As long as you follow the directions= , you
should be OK.=C2=A0 'rm' can get dangerous if you get over-exuberan= t with using '*'
characters, but you already knew that, right? :)

<= /div>
If you have to use rm always use it with the -i flag. Always prom= pt before removal.
=C2=A0
And if you followed my recommendation and back up /boot, you'll be all<= br> set to restore whatever you mess up.=C2=A0

Listen to Valdis in this case and follow orders religioulsy. Back up not j= ust /boot but anything
and everything that is important for you.
=C2=A0
The = running kernel will work just fine
as long as you don't reboot. And unless you did 'rm /boot/*', y= ou should have
at least one usable kernel left...

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

<= div>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
co= me's to the kernel because believe me like me you will find out over ti= me the kernel is a living thing that
has very subtle ways of info= rming 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 exp= erienced folk like Valdis who probably knows more about all the subsystems = than anyone. But if anyone tells you
you should not be a ker= nel hacker then prove them wrong ? Actually that is Valdis's way of mot= ivating you.

So good luck and we are here if you h= ave questions :-)

there is always the possibility of
something you didn't know about trashing your system.=C2=A0 See 5.12.0-= rc1-dontuse
for a nasty bug with file-backed swap that would stomp all over a section o= f your
filesystem, and there was an ext[34] (can't remember anymore) bug durin= g 2.5
that would trash the filesystem when you *unmounted* it.=C2=A0 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 w= as
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 s= crew-up
can do to permanently lose date.

Agreed= 110%.

Of course, WIndows Update is at that same level of reliability, so "kn= owing how
to recover a trashed system" is an important skill no matter what OS y= ou run :)

=C2=A0Hope this helps - Arun= a
--0000000000002bc04105be35c598-- --===============9141219367122630908== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============9141219367122630908==--