I'm using ubuntu 18.04 and trying to boot kernel 2.6.34.7 compiled from source. I tried to boot from ubuntu but it says "kernel too old", then I came up with the idea of using qemu, but I got the same problem... The version of my QEMU emulator is 2.11.1, the error code is:
...
FATAL: kernel too old
[ 5.299747] Kernel panic - not syncing: Attempted to kill init!
[ 5.300415] Pid: 1, comm: init Not tainted 2.6.34.7 #1
...
This is not a problem with QEMU. The "FATAL: kernel too old" message comes from your guest's userspace, specifically its glibc. Your guest's userspace binaries were built to require a newer kernel than the one you're trying to boot, so the two are not compatible. You need to either use a set of userspace binaries (ie a disk image) which was built to work with that old kernel, or you need to use a newer kernel that will work with the binaries you're using.
Related
I'm trying to test a SOM made by Variscite (VAR-SOM-6UL). On their website they have a precompiled Debian buster image. Unfortunately the cp210x module is not present on this image. This library automatically transforms a USB into UART channel. I use this library when I connect a sensor to the SoM so that they can both communicate via UART through USB.
I never had this problem before because the cp210x is preinstalled since kernel v3.x. For an unknown reason the cp210x module is not installed on the Debian buster image even tho the kernel version is v4.14.
$ uname -ar
Linux imx6ul-var-dart 4.14.78-g8e54a4b #1 SMP PREEMPT Tue Nov 19 16:42:38 PST 2019 armv7l GNU/Linux
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
This makes absolutely no sense but I have verified that there is indeed no cp210x on this image.
I'm stuck. I can't compile the cp210x module. I can't find another Linux library that does the same thing. I can't find the right linux-headers to compile the cp210x on my SoM.
I know that I should directly contact Variscite, but I cant even make an account it takes time to approve my account before I can post a question.
What I have tried so far:
installed the Linux-header
compiled the cp210x module from source to get a .ko file
put the .ko file in the right place and modprobe it
Did not work because the used Linux headers kernel version was higher than the running kernel. I can't find the right Linux headers version because the minimum version using apt get is v4.19.
I tried to use the https://snapshot.debian.org/ repository to download an older version of the Linux headers but it doesn't work because when I use the apt search linux-headers command the oldest Linux kernel is v4.19 (did not change).
I am trying to upgrade my current Buildroot build from 2019.11 to the newest 2020.02 release. With 2019.11 everything builds and produces a bootable image.
With the 2020.02 release everything still builds, but the device no longer boots and does not output any booting messages (no log data and no out via serial).
The Issue seems to be, the binutils version. In 2020.02 binutils 2.30 is no longer supported and the min version is 2.31.1 (this is the only legacy option in my config when upgrading).
Is this a known issue? are there any workarounds?
When I try building the 4.14 Kernel the build aborts during Kernel compilation. This post encountered the same issues I had during the compilation of the 4.14 Kernel. So I guess a Kernel upgrade is not a solution.
Edit: The kernel version that does build but not boot is 4.4 .
Edit 2: The target hardware is a Dual-core Intel Atom (x86_64).
I installed CentOS 7.6 on a system with NVME drive. Everything went successfuly and the system was behaving as expected. It came with kernel 3.10 by default so I upgraded the kernel to the latest (5.1.5) and changed kernel boot order in grub. However, whenever the system is rebooted with 5.x kernel version, it goes into emergency mode with the below error:
Could not boot
/dev/centos/root doesn't exist
/dev/centos/swap doesn't exist
/dev/mapper/centos-root doesn't exist
The system reboots just fine if I switch back to kernel version 3.10. I am getting this error only with 5.x version.
I compared /boot/initramfs for both 3.x and 5.x and saw below kernel drivers included in 3.x, but not in 5.x
lsinitrd -k <5.x kernel version>
usr/lib/modules/3.10.0-957.el7.x86_64/kernel/drivers/nvdimm
usr/lib/modules/3.10.0-957.el7.x86_64/kernel/drivers/nvdimm/libnvdimm.ko.xz
usr/lib/modules/3.10.0-957.el7.x86_64/kernel/drivers/nvdimm/nd_btt.ko.xz
usr/lib/modules/3.10.0-957.el7.x86_64/kernel/drivers/nvdimm/nd_pmem.ko.xz
usr/lib/modules/3.10.0-957.el7.x86_64/kernel/drivers/nvme
usr/lib/modules/3.10.0-57.el7.x86_64/kernel/drivers/nvme/host
usr/lib/modules/3.10.0-957.el7.x86_64/kernel/drivers/nvme/host/nvme-core.ko.xz
usr/lib/modules/3.10.0-957.el7.x86_64/kernel/drivers/nvme/host/nvme.ko.xz
Therefore, I performed the below command to include nvme drivers in 5.x and rebuilt initramfs.
echo 'add_drivers+=" nvme "' > /etc/dracut.conf.d/nvme.conf
Once I did this, I could see nvme drivers being included in 5.x initramfs (different filenames though).
usr/lib/modules/5.1.5-1.el7.elrepo.x86_64/kernel/drivers/nvdimm
usr/lib/modules/5.1.5-1.el7.elrepo.x86_64/kernel/drivers/nvdimm/nd_btt.ko
usr/lib/modules/5.1.5-1.el7.elrepo.x86_64/kernel/drivers/nvdimm/nd_pmem.ko
usr/lib/modules/5.1.5-1.el7.elrepo.x86_64/kernel/drivers/nvme
usr/lib/modules/5.1.5-1.el7.elrepo.x86_64/kernel/drivers/nvme/host
usr/lib/modules/5.1.5-1.el7.elrepo.x86_64/kernel/drivers/nvme/host/nvme-fabrics.ko
usr/lib/modules/5.1.5-1.el7.elrepo.x86_64/kernel/drivers/nvme/host/nvme-tcp.ko
I rebooted the system again with 5.x kernel version and again I get the same error. I also read up about some rootdelay in case the device is delayed in being detected by the kernel, however, I didn't try that given the system starts just fine with kernel 3.x.
Does anyone have any idea what might be going on here?
I was, until recently able to boot qemu-system-ppc (v1.7.0) using a customized cross compiled Linux kernel and BusyBox. I even posted it here: qemu kernel debugging with KGDB
However I am unable to do so now with v2.0.2. The command I use to invoke qemu is the very same I used previously
qemu-system-ppc -M mpc8544ds -m 512 -kernel zImage -s -nographic -initrd busyboxfs.img -append "root=/dev/ram rdinit=/bin/sh kgdboc=ttyS0,115200 kgdbwait
can anyone help me see the console log so I can understand if it is indeed booting and if not what is the problem. I've tried without the kgdb arguments to the kernel but still all I see is blank.
You might want to have a look at Buildroot (http://www.buildroot.org) : we have three PowerPC defconfigs that boot fine under recent versions of Qemu, including 2.0.2 and 2.1.2.
See especially the qemu_ppc_g3beige_defconfig, which boots fine under Qemu 2.1.2, the qemu_ppc_mpc8544ds_defconfig, which boots fine under Qemu 2.0.2, and qemu_ppc_virtex_ml507_defconfig, which boots fine under Qemu 2.1.2.
I am running Fedora 12 that runs on 2.6.31 linux kernel.
and have to compile some code run the binary on 2.6.11 kernel(supported by FC4).
Is there a way to do the same, without having to install FC4 or have a virtual machine running FC4?
Also, When you print file info of an elf image using file command, why does the part 'for GNU/Linux ', show an older kernel version?
For example, for me, on 2.6.31 kernel, it says compiled for 2.6.18, on 2.6.11 it says compiled for 2.2.5. This is the kernel version its talking about I suppose.
Thanks