Booting with SYSLINUX on Loopback Device: Kernel Panic - Where to Start?
Hello, I was able to install SYSLINUX on a disk image and get the kernel I built to start booting Linux with QEMU pointing to a loopback device associated with the disk image. However, at some point far into the boot process, I get a kernel panic. I can't read the beginning of the error messages that the kernel prints, because the errors run off the screen. I copied the bzImage onto the disk image, and I'm not sure where to go from there. Is the next step to build the initrd image? I don't yet know how to get the kernel to mount a device so it can find the root file system. Any help is appreciated. Patrick
On 2016-03-04 11:38:33 (-0700), Patrick <plafratt@gmail.com> wrote:
I was able to install SYSLINUX on a disk image and get the kernel I built to start booting Linux with QEMU pointing to a loopback device associated with the disk image. However, at some point far into the boot process, I get a kernel panic. I can't read the beginning of the error messages that the kernel prints, because the errors run off the screen.
You should be able to persuade qemu to be a bit more helpful. '-nographic' turns off graphical output and redirects the serial port to the console (or just use '-serial'). You can then configure your kernel to log to the serial port. This should get you started: http://stackoverflow.com/questions/19565116/redirect-qemu-window-output-to-t... Regards, Kristof
On Fri, Mar 4, 2016 at 3:33 PM, Kristof Provost <kristof@sigsegv.be> wrote:
On 2016-03-04 11:38:33 (-0700), Patrick <plafratt@gmail.com> wrote:
I was able to install SYSLINUX on a disk image and get the kernel I built to start booting Linux with QEMU pointing to a loopback device associated with the disk image. However, at some point far into the boot process, I get a kernel panic. I can't read the beginning of the error messages that the kernel prints, because the errors run off the screen.
You should be able to persuade qemu to be a bit more helpful. '-nographic' turns off graphical output and redirects the serial port to the console (or just use '-serial'). You can then configure your kernel to log to the serial port.
This should get you started:
http://stackoverflow.com/questions/19565116/redirect-qemu-window-output-to-t...
Regards, Kristof
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. 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. Thanks again, Patrick
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
First your must know exactly how linux boot (not at source code level). Most recent linux distributions boot as grub —> kernel —> initramfs’ /init executable All the userspace affair is started by initramfs’ /init. Kernel no longer join the boot process. From you description, I think you were blocked by the initramfs concept. Initramfs is the first root filesystem and reside in memeory. It’s loaded by grub, and the kernel automatically mount it, execute the /init. The /init executable can do some extra initialisation and switch to the real root filesystem on disk. for detail /Documentaion/filesystems/ramfs-rootfs-initramfs Hope that would be useful to your.
On Mar 5, 2016, at 2:38 AM, Patrick <plafratt@gmail.com> wrote:
Hello,
I was able to install SYSLINUX on a disk image and get the kernel I built to start booting Linux with QEMU pointing to a loopback device associated with the disk image. However, at some point far into the boot process, I get a kernel panic. I can't read the beginning of the error messages that the kernel prints, because the errors run off the screen.
I copied the bzImage onto the disk image, and I'm not sure where to go from there. Is the next step to build the initrd image? I don't yet know how to get the kernel to mount a device so it can find the root file system.
Any help is appreciated.
Patrick _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Fri, Mar 4, 2016 at 9:09 PM, 张云 <zyunone@163.com> wrote:
First your must know exactly how linux boot (not at source code level).
Most recent linux distributions boot as
grub —> kernel —> initramfs’ /init executable
All the userspace affair is started by initramfs’ /init. Kernel no longer join the boot process.
From you description, I think you were blocked by the initramfs concept. Initramfs is the first root filesystem and reside in memeory. It’s loaded by grub, and the kernel automatically mount it, execute the /init. The /init executable can do some extra initialisation and switch to the real root filesystem on disk. for detail /Documentaion/filesystems/ramfs-rootfs-initramfs
Hope that would be useful to your.
Thanks for the response. I was able to get a minimal boot using the files in the mini.iso image from Ubuntu. I just copied the kernel and the ramdisk image from that iso, and these have given me enough to start learning some things. It is still just dropping me into the prompt for the ramdisk image, so the kernel hasn't yet made the switch over to root filesystem on a drive, but this is at least enough to get me started. One thing I noticed that confused me was the result of the commands pasted below. It looks like the partition table on the disk image might be getting messed up. But, interestingly enough, it still seems to allow me to use the image for booting. In spite of this, fdisk is giving me strange output when I ask it to print out the partition tables after I build a file system on the disk image using mkfs. When I look at the disk image using gparted, on the other hand, it actually looks OK. It looks like I might be using mkfs incorrectly. Can anyone see anything obvious that I am doing wrong? ============== dd if=/dev/zero of=./disk.img bs=1M count=1000 sudo losetup /dev/loop0 ./disk.img sudo fdisk /dev/loop0 (commands in fdisk)
n (new partition)
p (primary partition)
1 (partition number)
(default start and end for partition)
t (change type of partition)
b (change type of partition to FAT32)
a (set boot flag)
1 (set boot flag for first partition)
w (write changes)
fdisk -lu /dev/loop0 Disk /dev/loop0 : 1048 MB, 1048576000 bytes 123 heads, 59 sectors/track, 282 cylinders, total 2048000 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x7b9351bf Device Boot Start End Blocks Id System /dev/loop 0 p1 * 2048 2047999 1022976 b W95 FAT32 mkfs -t vfat /dev/loop0 fdisk -lu /dev/loop0 Disk /dev/loop0: 1048 MB, 1048576000 bytes 255 heads, 63 sectors/track, 127 cylinders, total 2048000 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System ============== Thanks, Patrick
On Mar 8, 2016, at 7:29 AM, Patrick <plafratt@gmail.com> wrote:
On Fri, Mar 4, 2016 at 9:09 PM, 张云 <zyunone@163.com <mailto:zyunone@163.com>> wrote: First your must know exactly how linux boot (not at source code level).
Most recent linux distributions boot as
grub —> kernel —> initramfs’ /init executable
All the userspace affair is started by initramfs’ /init. Kernel no longer join the boot process.
From you description, I think you were blocked by the initramfs concept. Initramfs is the first root filesystem and reside in memeory. It’s loaded by grub, and the kernel automatically mount it, execute the /init. The /init executable can do some extra initialisation and switch to the real root filesystem on disk. for detail /Documentaion/filesystems/ramfs-rootfs-initramfs
Hope that would be useful to your.
Thanks for the response. I was able to get a minimal boot using the files in the mini.iso image from Ubuntu. I just copied the kernel and the ramdisk image from that iso, and these have given me enough to start learning some things. It is still just dropping me into the prompt for the ramdisk image, so the kernel hasn't yet made the switch over to root filesystem on a drive, but this is at least enough to get me started.
One thing I noticed that confused me was the result of the commands pasted below. It looks like the partition table on the disk image might be getting messed up. But, interestingly enough, it still seems to allow me to use the image for booting. In spite of this, fdisk is giving me strange output when I ask it to print out the partition tables after I build a file system on the disk image using mkfs. When I look at the disk image using gparted, on the other hand, it actually looks OK.
It looks like I might be using mkfs incorrectly. Can anyone see anything obvious that I am doing wrong?
==============
dd if=/dev/zero of=./disk.img bs=1M count=1000 sudo losetup /dev/loop0 ./disk.img sudo fdisk /dev/loop0 (commands in fdisk)
n (new partition) p (primary partition) 1 (partition number) (default start and end for partition) t (change type of partition) b (change type of partition to FAT32) a (set boot flag) 1 (set boot flag for first partition) w (write changes) fdisk -lu /dev/loop0 Disk /dev/loop0 : 1048 MB, 1048576000 bytes 123 heads, 59 sectors/track, 282 cylinders, total 2048000 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x7b9351bf
Device Boot Start End Blocks Id System /dev/loop0p1 * 2048 2047999 1022976 b W95 FAT32
The problem is caused by the command below
mkfs -t vfat /dev/loop0
/dev/loop0 is the whole disk, and /dev/loop0p1 is the partition. The command make a file system on the disk, thus overrides the disk’s partition table. I guess that it is the partition on which you want to make a filesystem. The right command is mkfs -t ext2 /dev/loop0p1 We prefer ext2,3,4 to fat32 on linux.
fdisk -lu /dev/loop0 Disk /dev/loop0: 1048 MB, 1048576000 bytes 255 heads, 63 sectors/track, 127 cylinders, total 2048000 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
==============
Thanks, Patrick
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
The problem is caused by the command below
mkfs -t vfat /dev/loop0
/dev/loop0 is the whole disk, and /dev/loop0p1 is the partition.
The command make a file system on the disk, thus overrides the disk’s partition table.
I guess that it is the partition on which you want to make a filesystem. The right command is
mkfs -t ext2 /dev/loop0p1
We prefer ext2,3,4 to fat32 on linux.
I see. Thanks! I used kpartx to map the partitions in /dev/mapper. If you know of a better way of doing what you suggest, could you please let me know? I was hoping to use ext4, but I wasn't able to grub-install to a loopback device. When I try to, I get the error:
grub-install: error: disk `lvm/loop1p1' not found.
From a searching around, it looks like this issue has been visited recently by the developers: https://lists.gnu.org/archive/html/grub-devel/2015-05/msg00011.html So I wasn't able to get it to work. So instead I've been using syslinux, which I believe requires FAT, rather than EXT. I read about extlinux, but from my reading, I've gotten the impression that syslinux has more history. So I figured it would be easier to find useful material for syslinux on message boards. Thanks again for all your help! I hope that at some point I'll be able to do more, such as customize the ram disk, the init system, and figure out how to get the system switched over to a root file system on a disk. -Patrick
You can circumvent the grub-install bug by substituting a USB memory for the disk image. 发自 网易邮箱大师 在2016年03月09日 00:56，Patrick 写道: The problem is caused by the command below mkfs -t vfat /dev/loop0 /dev/loop0 is the whole disk, and /dev/loop0p1 is the partition. The command make a file system on the disk, thus overrides the disk’s partition table. I guess that it is the partition on which you want to make a filesystem. The right command is mkfs -t ext2 /dev/loop0p1 We prefer ext2,3,4 to fat32 on linux. I see. Thanks! I used kpartx to map the partitions in /dev/mapper. If you know of a better way of doing what you suggest, could you please let me know? I was hoping to use ext4, but I wasn't able to grub-install to a loopback device. When I try to, I get the error:
grub-install: error: disk `lvm/loop1p1' not found.
From a searching around, it looks like this issue has been visited recently by the developers: https://lists.gnu.org/archive/html/grub-devel/2015-05/msg00011.html So I wasn't able to get it to work. So instead I've been using syslinux, which I believe requires FAT, rather than EXT. I read about extlinux, but from my reading, I've gotten the impression that syslinux has more history. So I figured it would be easier to find useful material for syslinux on message boards. Thanks again for all your help! I hope that at some point I'll be able to do more, such as customize the ram disk, the init system, and figure out how to get the system switched over to a root file system on a disk. -Patrick
On Tue, Mar 8, 2016 at 11:03 AM, 张云 <zyunone@163.com> wrote:
You can circumvent the grub-install bug by substituting a USB memory for the disk image.
发自 网易邮箱大师 <http://u.163.com/signature>
Ok, thanks! -Patrick
participants (3)
-
Kristof Provost -
Patrick -
张云