General TC > General TC Talk

[Solved]: how to boot alternate kernel of same architecture

(1/4) > >>

GNUser:
FYI - This is just a learning exercise. There is no problem I'm trying to solve other than my ignorance.

I'm on TCL13.1 x86_64, using grub2, on a laptop with legacy BIOS. It's my daily driver laptop and everything works great.

As an experiment, I took the 64-bit linux kernel image from Devuan Chimaera (kernel version 5.10.0-9), renamed it vmlinuz64, and replaced TCL13.1's kernel image with it. I then remastered corepure64.gz to include /lib/modules/5.10.0-9-amd64 (which I copied from a working Devuan system). Then I tried to boot this monster.

Boot process hangs indefinitely after the first few steps. I took a picture of the step where it hangs.

Any idea why the boot process is hanging and how to fix it? Is there anything in corepure64.gz (other than /lib/modules/<version>-tinycore64) that is hardwired for a specific kernel version?

nick65go:
Hi, I have few naive things in my mind, maybe one of it will help you.

1. Even with the same architecture (64 bits), there can be kernel compiled with CPU instructions (AVX2, whatever) that your laptop CPU does not support.

2. Tinycore has built-in modules (like for controllers, HDD, USB) that your new imported kernel has as external modules only.

3. Test in Qemu, where you can have its ctrl-1 console debug, etc. Or you can even make a virtual hdd, put kernel +modules on this file,and  modify tc-config to not load in RAM, etc... same like you would do a tinycore not-recommended /scatted HDD installation, but on virtual hdd (hdd is basically a file, so you have the kernel log).

The best way to test is to put echos/pause instructions inside tc-config on important steps-blocks.
PS:if You know, the half algorithm, where you guess a number less than 256 (=2^8) in 8 steps... first step test if your guess is less than half, so 128. If is true, then second guess is test if less than next half, so 64. You know the drill. By this method you identify the offending piece/instruction or its arguments/parameters. Good luck.

GNUser:
Thanks, nick65go.

1. That's not the issue. Devuan partition on this same laptop using the alternate kernel boots just fine.

2. The imported kernel boots fine with its external modules on this machine (see #1 above).

3. I have no experience with qemu, unfortunately.

I don't want anyone to waste too much time with this. I mostly just want to exclude something obvious and easy such as any files in corepure64.gz that point to a specific kernel version.

nick65go:
IMHO nothing is specific to some kernel version (except glibc and its umbilical symbols linked to kernel functions).

1. Did you properly check that your NEW symlink "kernel.local" from (seen with 7zip in win10):
TinyCorePure64-abc.iso\boot\corepure64.gz\corepure64.cpio\lib\modules\5.10.0-9-amd64\kernel.local 
point to the NEW kernel branch "lib\modules\5.10.0-9-amd64" ?

2. Did you updated also the modules.* [dep, alias] ?

I think that is all, from my experience.

GNUser:
Thanks, nick65go.

1. When booted into Devuan I do not see a symlink called kernel.local anywhere in the filesystem

2. Yes, modules.dep and modules.alias are inside the /lib/modules/5.10.0-9-amd64/ directory. I put the entire directory inside the remastered corepure64.gz.

I guess there must be something else that's required to boot a kernel in addition to the kernel image and the /lib/modules/<kernel_version> directory.

Navigation

[0] Message Index

[#] Next page