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

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

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

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.

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

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