Updated AwlsomeLinux 'Init' Kills Kernel

[AwlsomeAlex]

I'm not sure why or if something happened during compiling, but AwlsomeLinux will no longer be functional with the updated Linux Kernel 4.9.8, GlibC 2.25, and Busybox 1.26.2. It gets to the point where the 'init' (AwlsomeLinux Init) is called, but crashes when it tries to switch_root from the tmpfs/devfs to the overlayfs. Not sure why this is at all, but it could be something with Busybox and bad code for the AwlsomeLinux Busybox Init. Will experiment more tomorrow with different version Kernels, C Libraries, and Shells.

EDIT 1: One thing I would like to note that a suspicious config setting for GlibC wasn't set correctly and that could be the problem, along with it being compiled in a Virtual Machine of Lubuntu 14.04 with 2GB of RAM, 16GB of ROM, and only 1 core being utilized, so more resources will be allocated to this specific project, along with setting up a server of mine for constant compiling.

EDIT 2: So I'm not sure if the 'texinfo' dependency solved it or maybe something went wrong in x32, but it seems to compile and work fine under x64. Will further investigate for x32.

[AwlsomeAlex]

My plan is to try a series of compiling tests among different Component Version, Ubuntu Versions, and Architectures.
[/] - Test 1 of 6 [Kernel 4.4.x / GlibC 2.24 / Busybox 1.25.1 -- Ubuntu 14.04 x64]
[O] - Test 2 of 6 [Kernel 4.9.x / GlibC 2.25 / Busybox 1.26.2 -- Ubuntu 14.04 x64]

• Realized 'texinfo' was missing and that it gave me problems in the past. A possible solution?

[/] - Test 3 of 6 [Kernel 4.4.x / GlibC 2.25 / Busybox 1.26.2 -- Ubuntu 14.04 x64]
[/] - Test 4 of 6 [Kernel 4.9.x / GlibC 2.24 / Busybox 1.26.2 -- Ubuntu 14.04 x64]
[/] - Test 5 of 6 [Kernel 4.4.x / GlibC 2.25 / Busybox 1.26.2 -- Ubuntu 14.04 x64]
[/] - Test 5 of 6 [Kernel 4.4.x / GlibC 2.25 / Busybox 1.25.1 -- Ubuntu 14.04 x64]

[ivandavidov]

One suggestion how to track issues with init that ultimately leads to kernel panic.

Implement a rescue shell (i.e. shell that runs with PID 1, e.g. exec /bin/sh as first command in the /init script) and then manually apply the commands that should have been executed during the normal init process. After each command check the corresponding output. Are all directories really created? Is all the content really moved from folder A to folder B? Are the directories specified in the switch_root command really existing? Do you see any unexpected error messages? Is the /sbin/init file existing in the new mount location just before the switch_root command has been executed?

I believe it is much easier to find the answers to these questions if you use rescue shell.

[bauen1]

What exactly does the kernel panic say, redirecting the qemus output to the console (using serial0 ) could be helpful
(disregard the above, didn't fully think about it before posting)

[AwlsomeAlex]

@ivandavidov There was nothing wrong with the 'init' (I think) because it only happened with 32-bit and booted with 64-bit, I think something went wrong with compiling. But yeah that's a great suggestion! I'll have to do that next time I get an init error. Quite frankly when I start compiling more Overlay Packages, I might just drop x32 completely but leave traces of it in the script.