Re: Booting with SYSLINUX on Loopback Device: Kernel Panic - Where to Start?
On Fri, Mar 4, 2016 at 3:56 PM, Kristof Provost <kristof@sigsegv.be> wrote:
On 04 Mar 2016, at 23:50, Patrick <plafratt@gmail.com> wrote: Thanks for the response. I had seen that StackOverflow post and done that a couple of days ago. I was hoping there was another answer, since I wouldn't be able to do that if I weren't using QEMU.
If you weren’t using Qemu I’d point you at netconsole. The first step in debugging panics is always to figure out what the panic is.
When I looked at the output from QEMU a couple of days ago, the kernel was saying that it couldn't find a device to mount with the root filesystem. So I generated an initrd image on the host Linux system, and I used that on the guest which got me to a BusyBox prompt. But this was totally a hack, since I didn't even know if getting an initrd image was really the next thing I needed to do. I was hoping someone might be able to point me to something that might explain what to do to get the kernel to mount a device with the root filesystem.
You want to pass the ‘root=/dev/foo’ option to your kernel. Obviously change /dev/foo into whatever device you’re booting from.
Regards, Kristof
Ok, thanks. I will try to look into netconsole. I had tried changing the "root" option. I had noticed that the QEMU output showed the kernel printing out this: [ 4.312088] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6 [ 4.322029] Please append a correct "root=" boot option; here are the available partitions: [ 4.327850] 0100 65536 ram0 (driver?) [ 4.337399] 0101 65536 ram1 (driver?) [ 4.345170] 0102 65536 ram2 (driver?) [ 4.345691] 0103 65536 ram3 (driver?) [ 4.346251] 0104 65536 ram4 (driver?) [ 4.346825] 0105 65536 ram5 (driver?) [ 4.347442] 0106 65536 ram6 (driver?) [ 4.350055] 010a 65536 ram10 (driver?) [ 4.352624] 010b 65536 ram11 (driver?) [ 4.353597] 010c 65536 ram12 (driver?) [ 4.354517] 010d 65536 ram13 (driver?) [ 4.354977] 010e 65536 ram14 (driver?) [ 4.358393] 010f 65536 ram15 (driver?) [ 4.359420] 0b00 1048575 sr0 driver: sr [ 4.360499] 0800 102400 sda driver: sd [ 4.367898] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) I hadn't noticed "sda" before. So I tried pointing root at this. Then I got this: [ 4.375721] List of all partitions: [ 4.383491] 0100 65536 ram0 (driver?) [ 4.386418] 0101 65536 ram1 (driver?) [ 4.388736] 0102 65536 ram2 (driver?) [ 4.390931] 0103 65536 ram3 (driver?) [ 4.391266] 0104 65536 ram4 (driver?) [ 4.391726] 0105 65536 ram5 (driver?) [ 4.392812] 0106 65536 ram6 (driver?) [ 4.393340] 0107 65536 ram7 (driver?) [ 4.393932] 0108 65536 ram8 (driver?) [ 4.394906] 0109 65536 ram9 (driver?) [ 4.396283] 010a 65536 ram10 (driver?) [ 4.399212] 010b 65536 ram11 (driver?) [ 4.400067] 010c 65536 ram12 (driver?) [ 4.401832] 010d 65536 ram13 (driver?) [ 4.402775] 010e 65536 ram14 (driver?) [ 4.403572] 010f 65536 ram15 (driver?) [ 4.404046] 0800 102400 sda driver: sd [ 4.412148] 0b00 1048575 sr0 driver: sr [ 4.413323] No filesystem could mount root, tried: ext3 ext2 ext4 vfat fuseblk [ 4.415310] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,0) So, I think maybe now the kernel is missing some things it needs on /dev/sda. Right now, I don't think there is anything on it other than the bootloader. Do you happen to know where I can find what the kernel needs to proceed? Thanks, Patrick
On Fri, 04 Mar 2016 16:27:35 -0700, Patrick said:
[ 4.413323] No filesystem could mount root, tried: ext3 ext2 ext4 vfat fuseblk [ 4.415310] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,0)
So, I think maybe now the kernel is missing some things it needs on /dev/sda.
What filesystem is on the /dev/sda image that qemu is using? You'll need to either build your kernel with the support for that built into the kernel, or an initrd that modprobes the filesystem module, and then mounts the filesystem (then there's a few fun and games involved in pivoting from the ram filesystem the initrd is using as root, to the disk image filesystem that you want as the root filesystem after boot).
What filesystem is on the /dev/sda image that qemu is using? You'll need to either build your kernel with the support for that built into the kernel, or an initrd that modprobes the filesystem module, and then mounts the filesystem (then there's a few fun and games involved in pivoting from the ram filesystem the initrd is using as root, to the disk image filesystem that you want as the root filesystem after boot).
Thanks for the response. This is helpful. I copied the vmlinuz and initrd image from my host, and that seemed to get me further. Now blkid says: /dev/sda: SEC_TYPE="msdos" UUID="6815-7325" TYPE="vfat" The mount command indicates that it mounted successfully at /root. The contents of /root are just: vmlinuz syslinux.cfg initrd.img ldlinux.c32 ldlinux.sys I realize that isn't enough to get the system up, so I would like to try to figure out what I need to drop in there to get the system going. I think that the other responses that people have so kindly sent to my question might help me further, since they talk about init. Although I copied vmlinuz and initrd from the host to get this far, I hope to eventually figure out how to do something less hacky. I am able to build the kernel, but I don't really know what's involved with building initrd for the guest. (It seems I was able to build one on the host using initramfs, but I'd like to figure out how to build one for the host. I'd also like to better understand the "fun and games" you were talking about with pivoting from the ram filesystem to the disk image filesystem. ...but I'll take it one step at a time, I guess.) By the way, I'm a double alum (BS and MS) from VT. Go Hokies! Thanks again, Patrick
participants (2)
-
Patrick -
Valdis.Kletnieks＠vt.edu