How to switch between installed kernel and developed kernel

How to switch between installed kernel and developed kernel

[Gidi Gal]

[-- Attachment #1.1: Type: text/plain, Size: 565 bytes --]

Hello,

I am new to kernel development, currently working on
https://kernelnewbies.org/FirstKernelPatch. I reached the step "Install
your changes" in "Modifying a driver on native Linux". I would like to
separate my developed kernel and my installed kernel and to switch between
the two in order to test my changes. I am not sure that my tutorial
explains how to do that. If you have a link that proposes a workflow for
this request (or if my tutorial does explain this workflow and I'm missing
the exact paragraph that does that) please let me know.

Thanks,
Gidi

[-- Attachment #1.2: Type: text/html, Size: 756 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to switch between installed kernel and developed kernel

[Bernd Petrovitsch]

Hi,

On 22/03/2021 13:11, Gidi Gal wrote:
[...]
> <https://kernelnewbies.org/FirstKernelPatch>. I reached the step
> "Install your changes" in "Modifying a driver on native Linux". I would
> like to separate my developed kernel and my installed kernel and to
> switch between the two in order to test my changes. I am not sure that
[...]

I don't know that tutorial but - TTBOMK - folks use UserModeLinux, qemu
or a virtual machine like VirtualBox to test a self-patched kernel.

It obviously depends on the changed parts/drivers and/or architecture of
the kernel if that makes sense ...

MfG,
	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
     There is NO CLOUD, just other people's computers. - FSFE
                     LUGA : http://www.luga.at

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to switch between installed kernel and developed kernel

[Valdis Klētnieks]

[-- Attachment #1.1: Type: text/plain, Size: 2502 bytes --]

On Mon, 22 Mar 2021 14:11:58 +0200, Gidi Gal said:

> I am new to kernel development, currently working on
> https://kernelnewbies.org/FirstKernelPatch. I reached the step "Install
> your changes" in "Modifying a driver on native Linux". I would like to
> separate my developed kernel and my installed kernel and to switch between
> the two in order to test my changes. I am not sure that my tutorial
> explains how to do that.

Well... the first rule of thumb is to make sure that your kernel release name
will be different one way or another.  CONFIG_LOCALVERSION is a good way to
ensure it, while linux-next kernels and git-bisect kernels have their own way
of naming themselves.  It's also what shows up in uname -r.

What I have in /boot at the moment:

[/boot] ls vmlinuz-*
vmlinuz-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64  vmlinuz-5.10.0-rc4-next-20201117-dirty  vmlinuz-5.11.0-rc3-next-20210114-dirty
vmlinuz-5.10.0-next-20201215				     vmlinuz-5.10.0-rc6-next-20201203	     vmlinuz-5.12.0-rc1-next-20210302-dirty
vmlinuz-5.10.0-next-20201223-dirty			     vmlinuz-5.10.0-rc6-next-20201207	     vmlinuz-5.12.0-rc2-next-20210309-dirty
vmlinuz-5.10.0-rc1-00257-gcf9446cc8e6d-dirty		     vmlinuz-5.10.0-rc7-next-20201208	     vmlinuz-5.8.0-next-20200807
vmlinuz-5.10.0-rc1-next-20201030			     vmlinuz-5.11.0-rc2-next-20210105-dirty  vmlinuz-5.8.0-rc1-next-20200616

Each has a matching config-, System.map-, and initramfs- file in /boot, a grub2
config entry in /boot/loader/entries/, and the loadable modules in
subdirectories under /lib/modules/`uname -r`.  So if you back up /boot
and /lib/modules, you should be able to recover from any issues.  Note
that on many systems, /boot is ext4, but there's a /boot/efi that's vfat that
kernel installs shouldn't be touching, but you want a copy in case an update
of grub goes astray...

This is probably a good time to back up your *entire* system, because lots
of Bad Things can happen even when you're not testing a new kernel.

If you want to double-check what your just-built kernel is called, you can use
'make kernelrelease' to tell you.  As long as that's different from any
installed kernel, you shouldn't have any issues with files getting overlaid.

'make install' will look for a script 'installkernel' that does some of the
heavy lifting, like building an initramfs, adding grub entries, and the like.
That usually lives in /sbin/installkernel, but if you create your own and have
it before /sbin in $PATH, it will get used.


[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to switch between installed kernel and developed kernel

[Bjørn Mork]

Gidi Gal <gidi.gal.linux@gmail.com> writes:

> I am new to kernel development, currently working on
> https://kernelnewbies.org/FirstKernelPatch. I reached the step "Install
> your changes" in "Modifying a driver on native Linux". I would like to
> separate my developed kernel and my installed kernel and to switch between
> the two in order to test my changes. I am not sure that my tutorial
> explains how to do that. If you have a link that proposes a workflow for
> this request (or if my tutorial does explain this workflow and I'm missing
> the exact paragraph that does that) please let me know.

The answer depends on your choice of bootloader, distro etc.

But one way to do this is to build a native kernel package for your
distro and simply install that like any other package. So instead of

 make -j2; sudo make modules_install install

you'll do somethong like (or maybe give a more explicit version than '*')

 make -j2 bindeb-pkg; sudo dpkg -i ../linux-image-*.deb

or similare with "binrpm-pkg" for the RPM based distros.

With this you'll end up with your testing kernel as an additional choice
in the bootloader menu, keeping all your previously installed kernels as
alternatives.

Note that this way of testing is quite slow since you'll rebuild
everythng and reboot a bare metal machine.  There are easier ways to
test many kernel changes, like rebuilding only one module and load it in
your running kernel. And there is of course always a very real risk of
crashing, and possibly thrashing too...  So if you can, you might want
to run test your kernels on a virtual machine, or some other test
machine, instead of your development machine.


Bjørn

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to switch between installed kernel and developed kernel

[Gidi Gal]

[-- Attachment #1.1: Type: text/plain, Size: 5493 bytes --]

I am grateful for your replies, Brend, Valdis and Bjørn.

I did some backups, decided for now to try and run my kernel on my native
Linux, until I prepare a VM for testing.
I tried to install my kernel. The output showed some errors (I copied the
install log at the bottom of this email). I think these errors led to an
"invalid signature" error later on when I rebooted my machine.
I would be grateful if you could take a look and comment about possible
solutions. Regarding my CONFIG_LOCALVERSION, it is set as follows:
CONFIG_LOCALVERSION="-GIDI_DEV"

Here is the installation output (if there's a different preferable way to
attach such info, please let me know) :
gidi@gidi-Precision-3510:~/git/kernels/staging$ sudo make modules_install
install
[sudo] password for gidi:
  INSTALL arch/x86/crypto/aesni-intel.ko
...
  INSTALL sound/soundcore.ko
  DEPMOD  5.12.0-rc3-GIDI_DEV+
sh ./arch/x86/boot/install.sh 5.12.0-rc3-GIDI_DEV+ arch/x86/boot/bzImage \
System.map "/boot"
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal
5.12.0-rc3-GIDI_DEV+ /boot/vmlinuz-5.12.0-rc3-GIDI_DEV+
run-parts: executing /etc/kernel/postinst.d/dkms 5.12.0-rc3-GIDI_DEV+
/boot/vmlinuz-5.12.0-rc3-GIDI_DEV+
 * dkms: running auto installation service for kernel 5.12.0-rc3-GIDI_DEV+

      [ OK ]
run-parts: executing /etc/kernel/postinst.d/initramfs-tools
5.12.0-rc3-GIDI_DEV+ /boot/vmlinuz-5.12.0-rc3-GIDI_DEV+
update-initramfs: Generating /boot/initrd.img-5.12.0-rc3-GIDI_DEV+
dpkg: warning: version '5.12.0-rc3-GIDI_DEV+' has bad syntax: invalid
character in revision number
dpkg: warning: version '5.12.0-rc3-GIDI_DEV+' has bad syntax: invalid
character in revision number
W: Possible missing firmware /lib/firmware/amdgpu/vangogh_gpu_info.bin for
module amdgpu
...
W: Possible missing firmware /lib/firmware/i915/dg1_dmc_ver2_02.bin for
module i915
dpkg: warning: version '5.12.0-rc3-GIDI_DEV+' has bad syntax: invalid
character in revision number
dpkg: warning: version '5.12.0-rc3-GIDI_DEV+' has bad syntax: invalid
character in revision number
run-parts: executing /etc/kernel/postinst.d/pm-utils 5.12.0-rc3-GIDI_DEV+
/boot/vmlinuz-5.12.0-rc3-GIDI_DEV+
run-parts: executing /etc/kernel/postinst.d/zz-update-grub
5.12.0-rc3-GIDI_DEV+ /boot/vmlinuz-5.12.0-rc3-GIDI_DEV+
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/50_linuxmint.cfg'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
dpkg: warning: version '5.12.0~rc3-GIDI_DEV+~old' has bad syntax: invalid
character in revision number
dpkg: warning: version '5.12.0~rc3-GIDI_DEV+' has bad syntax: invalid
character in revision number
dpkg: warning: version '5.12.0~rc3-GIDI_DEV+' has bad syntax: invalid
character in revision number
dpkg: warning: version '5.12.0~rc3-GIDI_DEV+' has bad syntax: invalid
character in revision number
Found linux image: /boot/vmlinuz-5.12.0-rc3-GIDI_DEV+
Found initrd image: /boot/initrd.img-5.12.0-rc3-GIDI_DEV+
dpkg: warning: version '5.12.0~rc3-GIDI_DEV+~old' has bad syntax: invalid
character in revision number
dpkg: warning: version '5.12.0~rc3-GIDI_DEV+~old' has bad syntax: invalid
character in revision number
Found linux image: /boot/vmlinuz-5.12.0-rc3-GIDI_DEV+.old
Found initrd image: /boot/initrd.img-5.12.0-rc3-GIDI_DEV+
Found linux image: /boot/vmlinuz-5.4.0-64-generic
Found initrd image: /boot/initrd.img-5.4.0-64-generic
Found linux image: /boot/vmlinuz-5.4.0-58-generic
Found initrd image: /boot/initrd.img-5.4.0-58-generic
Adding boot menu entry for UEFI Firmware Settings
done

Thanks,
Gidi


On Mon, Mar 22, 2021 at 2:59 PM Bjørn Mork <bjorn@mork.no> wrote:

> Gidi Gal <gidi.gal.linux@gmail.com> writes:
>
> > I am new to kernel development, currently working on
> > https://kernelnewbies.org/FirstKernelPatch. I reached the step "Install
> > your changes" in "Modifying a driver on native Linux". I would like to
> > separate my developed kernel and my installed kernel and to switch
> between
> > the two in order to test my changes. I am not sure that my tutorial
> > explains how to do that. If you have a link that proposes a workflow for
> > this request (or if my tutorial does explain this workflow and I'm
> missing
> > the exact paragraph that does that) please let me know.
>
> The answer depends on your choice of bootloader, distro etc.
>
> But one way to do this is to build a native kernel package for your
> distro and simply install that like any other package. So instead of
>
>  make -j2; sudo make modules_install install
>
> you'll do somethong like (or maybe give a more explicit version than '*')
>
>  make -j2 bindeb-pkg; sudo dpkg -i ../linux-image-*.deb
>
> or similare with "binrpm-pkg" for the RPM based distros.
>
> With this you'll end up with your testing kernel as an additional choice
> in the bootloader menu, keeping all your previously installed kernels as
> alternatives.
>
> Note that this way of testing is quite slow since you'll rebuild
> everythng and reboot a bare metal machine.  There are easier ways to
> test many kernel changes, like rebuilding only one module and load it in
> your running kernel. And there is of course always a very real risk of
> crashing, and possibly thrashing too...  So if you can, you might want
> to run test your kernels on a virtual machine, or some other test
> machine, instead of your development machine.
>
>
> Bjørn
>

[-- Attachment #1.2: Type: text/html, Size: 8440 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to switch between installed kernel and developed kernel

[Aruna Hewapathirane]

[-- Attachment #1.1: Type: text/plain, Size: 498 bytes --]

<snip>

> update-initramfs: Generating /boot/initrd.img-5.12.0-rc3-GIDI_DEV+
> dpkg: warning: version '5.12.0-rc3-GIDI_DEV+' has bad syntax: invalid
> character in revision number
> dpkg: warning: version '5.12.0-rc3-GIDI_DEV+' has bad syntax: invalid
> character in revision number
>
 <snip>

This is a standard warning, arising because the version contains an
underscore, which is against Debian Policy.
Remove the underscore and retry :-)

Try CONFIG_LOCALVERSION="-GIDI-DEV"

Good luck - Aruna

[-- Attachment #1.2: Type: text/html, Size: 1176 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to switch between installed kernel and developed kernel

[Aruna Hewapathirane]

[-- Attachment #1.1: Type: text/plain, Size: 566 bytes --]

On Mon, Mar 22, 2021 at 5:18 PM Aruna Hewapathirane <
aruna.hewapathirane@gmail.com> wrote:

> <snip>
>
>> update-initramfs: Generating /boot/initrd.img-5.12.0-rc3-GIDI_DEV+
>> dpkg: warning: version '5.12.0-rc3-GIDI_DEV+' has bad syntax: invalid
>> character in revision number
>> dpkg: warning: version '5.12.0-rc3-GIDI_DEV+' has bad syntax: invalid
>> character in revision number
>>
>  <snip>
>

Sorry I forgot to tell you if you look carefully the warning actually says
:  version '5.12.0-rc3-GIDI_DEV+' has bad syntax: invalid character in
revision number :-)

[-- Attachment #1.2: Type: text/html, Size: 1300 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to switch between installed kernel and developed kernel

[Gidi Gal]

[-- Attachment #1.1: Type: text/plain, Size: 1047 bytes --]

Many thanks for your reply, Aruna. Is there a way to remove the installed
'5.12.0-rc3-GIDI_DEV+' 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.

Thanks,
Gidi

On Mon, Mar 22, 2021 at 11:20 PM Aruna Hewapathirane <
aruna.hewapathirane@gmail.com> wrote:

>
> On Mon, Mar 22, 2021 at 5:18 PM Aruna Hewapathirane <
> aruna.hewapathirane@gmail.com> wrote:
>
>> <snip>
>>
>>> update-initramfs: Generating /boot/initrd.img-5.12.0-rc3-GIDI_DEV+
>>> dpkg: warning: version '5.12.0-rc3-GIDI_DEV+' has bad syntax: invalid
>>> character in revision number
>>> dpkg: warning: version '5.12.0-rc3-GIDI_DEV+' has bad syntax: invalid
>>> character in revision number
>>>
>>  <snip>
>>
>
> Sorry I forgot to tell you if you look carefully the warning actually says
> :  version '5.12.0-rc3-GIDI_DEV+' has bad syntax: invalid character in
> revision number :-)
>
>

[-- Attachment #1.2: Type: text/html, Size: 2213 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to switch between installed kernel and developed kernel

[Valdis Klētnieks]

[-- Attachment #1.1: Type: text/plain, Size: 2008 bytes --]

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

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? :)

And if you followed my recommendation and back up /boot, you'll be all
set to restore whatever you mess up.  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... 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.

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to switch between installed kernel and developed kernel

[Aruna Hewapathirane]

[-- Attachment #1.1: Type: text/plain, Size: 3798 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 5572 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to switch between installed kernel and developed kernel

[Valdis Klētnieks]

[-- Attachment #1.1: Type: text/plain, Size: 884 bytes --]

On Tue, 23 Mar 2021 00:29:10 -0400, Aruna Hewapathirane said:

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

That's a debian-specific thing...

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

That's not what I said.

What I *said* was "if you're a newbie who's all "ZOMG I'm going to accidentally break it"
maybe you shouldn't be a kernel hacker. :)

> And listen to more experienced folk like Valdis who probably knows more
> about all the subsystems than anyone.

Oh, there's people like Greg KH who know a lot more than I do.  He's also
*paid* to know a lot more than I do. :) After 4 decades in IT, I've just gotten
good at debugging and knowing where to start checking for more data on
something.


[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to switch between installed kernel and developed kernel

[Aruna Hewapathirane]

[-- Attachment #1.1: Type: text/plain, Size: 1402 bytes --]

On Tue, Mar 23, 2021 at 11:06 AM Valdis Klētnieks <valdis.kletnieks@vt.edu>
wrote:

> On Tue, 23 Mar 2021 00:29:10 -0400, Aruna Hewapathirane said:
>
> > Use : linux-check-removal <uname-r of your kernel to remove>
>
> That's a debian-specific thing...
>

Yep and he is running Ubuntu which is a derivative of Debian ? His .config
just told me this :-)
But valid point will keep things generic in future.
CONFIG_CC_VERSION_TEXT="gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0"

>
> > > 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
>
> That's not what I said.
>
> What I *said* was "if you're a newbie who's all "ZOMG I'm going to
> accidentally break it"
> maybe you shouldn't be a kernel hacker. :)
>
> So he breaks it. Then comes the fun part when he learns how to fix it :-)


> > And listen to more experienced folk like Valdis who probably knows more
> > about all the subsystems than anyone.
>
> Oh, there's people like Greg KH who know a lot more than I do.  He's also
> *paid* to know a lot more than I do. :) After 4 decades in IT, I've just
> gotten
> good at debugging and knowing where to start checking for more data on
> something.
>
> Why don't any of us ever get paid ? Ouch...

[-- Attachment #1.2: Type: text/html, Size: 2245 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to switch between installed kernel and developed kernel

[Gidi Gal]

[-- Attachment #1.1: Type: text/plain, Size: 5739 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 8600 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to switch between installed kernel and developed kernel

[Valdis Klētnieks]

[-- Attachment #1.1: Type: text/plain, Size: 1193 bytes --]

On Tue, 23 Mar 2021 16:37:13 +0200, you said:

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

Well, here's the thing.. the just-built kernel tree know what it has to install
because it was just built with that .config, and it knows what files it just
built.

But how is that 5.12-rc4 build supposed to know what to remove that belonged
to a 5.9 kernel built with a different .config that the 5.12-rc4 used, and which
potentially had more modules enabled than the current source tree? Bonus
points for knowing how to figure out if the 5.9 kernel was installed via rpm or
dpkg or opkg or 'make install', and whether the 'make install' invoked the
system-supplied /sbin/installkernel script, or the user provided a variant that
installed more/less/different files?

Especially as you noted, that it's a 3 or 4 line bash script to remove the
files.  And you hopefully know what extra rpm/dkpg stuff you need to
clean up....

[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to switch between installed kernel and developed kernel

[Aruna Hewapathirane]

[-- Attachment #1.1: Type: text/plain, Size: 6275 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 9802 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to switch between installed kernel and developed kernel

[Ahmad Fatoum]

Hello Gidi,

On 22.03.21 13:11, Gidi Gal wrote:
> Hello,
> 
> I am new to kernel development, currently working on
> https://kernelnewbies.org/FirstKernelPatch. I reached the step "Install
> your changes" in "Modifying a driver on native Linux". I would like to
> separate my developed kernel and my installed kernel and to switch between
> the two in order to test my changes. I am not sure that my tutorial
> explains how to do that. If you have a link that proposes a workflow for
> this request (or if my tutorial does explain this workflow and I'm missing
> the exact paragraph that does that) please let me know.

I've found running a kernel under qemu with my normal rootfs to be quite
useful to quickly try out things. See the qemu-test script in the RAUC project
for an example: https://github.com/rauc/rauc/blob/master/qemu-test

Don't forget to backup of course. Maybe you could even read-only mount
the rootfs for added safety.

Good luck,
Ahmad

> 
> Thanks,
> Gidi
> 
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: How to switch between installed kernel and developed kernel

[jim.cromie]

[-- Attachment #1.1: Type: text/plain, Size: 2537 bytes --]

>
>
>
> I've found running a kernel under qemu with my normal rootfs to be quite
> useful to quickly try out things. See the qemu-test script in the RAUC
> project
> for an example: https://github.com/rauc/rauc/blob/master/qemu-test
>
>

I would agree.
I find "virtme" tool to be super simple and effective.
It reuses your running system install, mounted with 9P,
no need to futz with a 2nd system image.
I barely had to tinker with all the qemu options and args...

heres my every-day usage (w my own boring shell funcs wrapping)
function krun () {
    echo vm    $KRUN_SHOW $KRUN_STDS $KDBG_OPTS $QM_OPTS $*
    virtme-run $KRUN_SHOW $KRUN_STDS $KDBG_OPTS $QM_OPTS $*
    # -qmp tcp:localhost:4444,server,nowait
}
[jimc@frodo local-i915m]$ krun
vm --show-command --show-boot-console --kdir . --mods=auto --kopt nokaslr
--kopt dynamic_debug.verbose=3 --kopt module.dyndbg=+pmf --qemu-opts
-machine dump-guest-core=on -m 2G
./.virtme_mods/lib/modules/0.0.0
/usr/bin/qemu-system-x86_64 -fsdev
local,id=virtfs1,path=/,security_model=none,readonly,multidevs=remap
-device virtio-9p-pci,fsdev=virtfs1,mount_tag=/dev/root -fsdev
local,id=virtfs5,path=/usr/local/lib/python3.9/site-packages/virtme-0.1.1-py3.9.egg/virtme/guest,security_model=none,readonly,multidevs=remap
-device virtio-9p-pci,fsdev=virtfs5,mount_tag=virtme.guesttools -machine
accel=kvm:tcg -watchdog i6300esb -cpu host -parallel none -net none -echr 1
-serial none -chardev stdio,id=console,signal=off,mux=on -serial
chardev:console -mon chardev=console -vga none -display none -kernel
./arch/x86/boot/bzImage -append
'virtme_link_mods=/home/jimc/projects/lx/wk-next/builds/local-i915m/.virtme_mods/lib/modules/0.0.0
earlyprintk=serial,ttyS0,115200 console=ttyS0 psmouse.proto=exps
"virtme_stty_con=rows 24 cols 141 iutf8" TERM=xterm-256color rootfstype=9p
rootflags=version=9p2000.L,trans=virtio,access=any raid=noautodetect ro
nokaslr dynamic_debug.verbose=3 module.dyndbg=+pmf init=/bin/sh -- -c
"mount -t tmpfs run /run;mkdir -p /run/virtme/guesttools;/bin/mount -n -t
9p -o ro,version=9p2000.L,trans=virtio,access=any virtme.guesttools
/run/virtme/guesttools;exec /run/virtme/guesttools/virtme-init"' -machine
dump-guest-core=on -m 2G
Wrong EFI loader signature.
early console in extract_kernel
input_data: 0x00000000047a340d
input_len: 0x00000000009f7f00
output: 0x0000000001000000
output_len: 0x0000000004139814
kernel_total_size: 0x0000000003630000
needed_size: 0x0000000004200000
trampoline_32bit: 0x000000000009d000


KASLR disabled: 'nokaslr' on cmdline.

......

[-- Attachment #1.2: Type: text/html, Size: 3113 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies