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.
Related
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'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.
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
I've been doing operating system development (not building a Linux kernel), and have gotten to the point where I need a debugger, for my latest OS. I've tried Bochs (under my Win 7 partition), but that wouldn't recognize my USB (It's unformatted, I'm reading specific sectors right now.) and I would rather do something under Ubuntu 11.10.
Is there a Debugger that would let me debug a custom build OS for Ubuntu 11.10?
Personally, I use QEMU for debugging a custom OS (which has USB support).
Run QEMU as follows for a debugging session:
qemu -S -s [more options here]
-S tells QEMU to not start the cpu. This gives you time to set breakpoints etc.
-s is a shortcut for -gdb tcp::1234 which start a gdbserver at TCP port 1234.
Then connect GDB to QEMU:
$ gdb
(gdb) target remote localhost:1234
From that point, you can use the normal GDB commands.