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

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

[GNUser]

Maybe the imported kernel needs something from the other system's (Devuan's) initrd? I will explore this.

Another, albeit unlikely, possibility is that there is a compatibility issue between imported kernel and TCL13.1's glibc. But I don't think this is the issue because Devuan Chimaera's glibc (version 2.31) is older than TCL13.1's glibc (version 2.34). New glibc versions generally work just fine with binaries compiled using older glibc versions (a fortunate fact which TCL's repo takes full advantage of).

[Rich]

Hi GNUser
I would think the kernel might want the the matching libraries from its /lib (or is that /lib64) directory.
Does Devuan use systemd? I wonder if maybe it's waiting for a missing systemd to do something.

[mocore]

> Does Devuan use systemd?

 its a devian fork *apparently*  created to avoid that init system ! ( hard deps ect )

> I wonder if maybe it's waiting for a missing systemd to do something.

id guess turning kernel debugging "up to 11" might help lessen speculation  ?

[GNUser]

Hi, Rich and mocore.

Devuan does not use systemd. It supports a handful of init systems. I use the default, which is SysVinit. (BTW I only keep the Devuan partition around for this kind of inter-distro exploration. TCL does everything I need, extremely well and with elegance.)

I unpacked and explored Devuan's initrd. It turned out to contain a lot more than I expected--not just kernel modules and firmware, but even its own set of shared libraries and executables...which are only around for first part of Devuan's boot process, until the root filesystem is mounted and a whole different set of kernel modules etc. become available.

So it seems that I'm dealing with 3 sets of files: Those in Devuan initrd, those in Devuan root filesystem, and those in TCL (ingeniously, TCL never leaves the initrd stage). Figuring out how to create a Frankenstein monster out of these three sets of files just to enable booting TCL with an imported kernel does not sound like my idea of fun.

Thanks for your support. It was still an interesting exercise and reinforced my love for TCL and its tendency to make things as least complicated as possible

[curaga]

The only kernel version dependency is in glibc, it has a compile-time setting on which kernel version to require as a minimum. We usually set it to the previous version's kernel IIRC. So 5.10 should be new enough to boot TC 13.

There are a number of config options that may cause that. E.g. not having squashfs would mean extensions won't load. A hang at that point may be related to one of the config options that affect udev operation.

[nick65go]

@GNUser: in your bad_boot.jpg picture, it seams that "udev daemon.. Done", so the new-kernel all built-ins modules passed. But, as curaga said, if the squashfs is not loaded then no other tcz can load.

Maybe now you understand my pseudo-obsession with http://landley.net/toybox/about.html
Because a statically linked shell (busybox, toybox) does not need a "libc" and will let you to boot in a prompter with just two pieces: kernel (+modules), and a shell. And THEN a simple init script can automate the rest (like TC does).

My suggestion is to temporary REPLACE the original busybox from tinycore with a statically linked one (but full options included). So you pass the initial busybox (modprobe, mount, etc). THIS is what I did in similar cases to replace default TC kernel. Good luck.

[GNUser]

My suggestion is to temporary REPLACE the original busybox from tinycore with a statically linked one (but full options included). So you pass the initial busybox (modprobe, mount, etc). THIS is what I did in similar cases to replace default TC kernel. Good luck.

Hi, nick65go. Busybox is part of the base system. Since base system also contains the libraries that busybox needs, I don't think this is the problem. That being said, it doesn't hurt to try a statically-linked busybox binary. I'll give it a shot when I have time.

There are a number of config options that may cause that. E.g. not having squashfs would mean extensions won't load. A hang at that point may be related to one of the config options that affect udev operation.

Thank you, curaga. I strongly suspect that this is the problem. Wish I had thought of that TCL boot process assumes the kernel was compiled with certain config options. Among them, there are some config options which other distros would have no reason to enable (e.g., squashfs to load extensions).

This thread can be marked as "solved". The point was to figure out why the experiment was not working and I think now I know why.

[Rich]

Hi GNUser

... This thread can be marked as "solved". ...

Done. 

[curaga]

If there was any problem with busybox's libs, you wouldn't see any of the normal boot messages.

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

Not that I would ever use or recommend this Frankenstein configuration, but I finally figured this out--just for fun. There were two missing pieces:

1. Adding modprobe to top of tc-config
Some essential modules that are built-in to the TCL linux need to be explicitly loaded when booting the alien kernel (because alien kernel was configured with  FOO=m  rather than  FOO=y  for each of these important modules). So the first missing piece is to add a  modprobe  command to the very top of
 /etc/init.d/tc-config  in the remastered corepure64.gz:

Code: [Select]

#!/bin/busybox ash
modprobe -a squashfs zram ext4 sd_mod ahci

2. Removing foo-KERNEL.tcz from dep files
So that all extensions in  onboot.lst  can load normally, a tweak to the .dep files is needed:

Code: [Select]

$ cd /etc/sysconfig/tcedir/optional
$ sed -i '/KERNEL/d' *.dep
Without this tweak, extensions that depend on  wireless-KERNEL.tcz  for example will not be able to load because  wireless-5.10.0-9-amd64.tcz  does not exist in tce/optional.

Again, this was just a learning exercise. Don't try this at home

Thread is solved.