All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] Kernel panic while trying to boot qemu_x86_64_defconfig on notebook with dual boot.
@ 2015-10-16  2:41 Alexandre Oliveira
  2015-10-16  6:05 ` Arnout Vandecappelle
  0 siblings, 1 reply; 6+ messages in thread
From: Alexandre Oliveira @ 2015-10-16  2:41 UTC (permalink / raw
  To: buildroot

Hello everyone.

I am having a problem while trying to boot qemu_x86_64_defconfig on my
notebook. My configuration is really simple. The .config file is attached.

Following the manual, I first tried to boot and run my configuration with
QEMU, using the command:

============
$ qemu-system-x86_64 -M pc -kernel images/bzImage -drive
file=images/rootfs.ext2,if=ide -append root=/dev/sda -net nic,model=rtl8139
-net user
============

This command works properly and Linux boots normally. After that, I created
a ext4 partition on /dev/sda7, which I mapped on /mnt/btlinux/

==================
$ sudo tar -C /mnt/btlinux/ -xf images/rootfs.tar
==================


All files were correctly extracted to the partition. Then, I added one more
boot option on GRUB.cfg file.

My UBUNTU is booting with:


==================================
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os
$menuentry_id_option 'gnulinux-simple-339d246f-008b-4cdf-8bbc-5ed43ca2d4c6'
{
recordfail
load_video
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos6'
if [ x$feature_platform_search_hint = xy ]; then
 search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos6
--hint-efi=hd0,msdos6 --hint-baremetal=ahci0,msdos6
 339d246f-008b-4cdf-8bbc-5ed43ca2d4c6
else
 search --no-floppy --fs-uuid --set=root
339d246f-008b-4cdf-8bbc-5ed43ca2d4c6
fi
linux /boot/vmlinuz-3.19.0-30-generic
root=UUID=339d246f-008b-4cdf-8bbc-5ed43ca2d4c6 ro  quiet splash $vt_handoff
initrd /boot/initrd.img-3.19.0-30-generic
}
====================================

My new Linux is set with:



===================
menuentry 'BTLinux (em /dev/sda7)' --class gnu-linux --class gnu --class os
$menuentry_id_option
'osprober-gnulinux-simple-96eafc8c-0063-417a-9c32-4ea96ee97b55' {
insmod part_msdos
insmod ext2
set root='hd0,msdos7'
if [ x$feature_platform_search_hint = xy ]; then
 search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7
--hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7
 96eafc8c-0063-417a-9c32-4ea96ee97b55
else
 search --no-floppy --fs-uuid --set=root
96eafc8c-0063-417a-9c32-4ea96ee97b55
fi
linux /boot/bzImage root=/dev/sda7 console=tty1

}
===================


I add the following two lines for /etc/fstab from the new linux:


=================
/dev/sda7                 /          ext4                defaults 1 1
/dev/sda5                 swap  swap             defaults 0 0
=================


Ubuntu is on /dev/sda6 and BTLinux is on /dev/sda7.
After boot starts, i get the famous following error:


===========================
VFS: Cannot open root device "sda7" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available
partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)  error -6
===========================


1 - Why QEMU boot work properly and when I extract the same image to
/dev/sda7, the boot fails?
2 - What is QEMU doing that the 'normal boot' process are not doing?
3 - Why the file at /boot/bzImage can be found but the device /dev/sda7 can
not?
4 - Am I missing something?

Could someone please help?


Thanks in advance for the assistance.

Regards,
Alexandre Oliveira.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151016/2d5b920a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config
Type: application/octet-stream
Size: 53014 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151016/2d5b920a/attachment.obj>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Buildroot] Kernel panic while trying to boot qemu_x86_64_defconfig on notebook with dual boot.
  2015-10-16  2:41 [Buildroot] Kernel panic while trying to boot qemu_x86_64_defconfig on notebook with dual boot Alexandre Oliveira
@ 2015-10-16  6:05 ` Arnout Vandecappelle
  2015-10-16  9:33   ` Alexandre Oliveira
  0 siblings, 1 reply; 6+ messages in thread
From: Arnout Vandecappelle @ 2015-10-16  6:05 UTC (permalink / raw
  To: buildroot

 Hi Alexandre,

 I think you fail to understand what QEMU does. It emulates a complete PC. In
other words...

On 16-10-15 04:41, Alexandre Oliveira wrote:
> Hello everyone.
> 
> I am having a problem while trying to boot qemu_x86_64_defconfig on my notebook.
> My configuration is really simple. The .config file is attached.
> 
> Following the manual, I first tried to boot and run my configuration with QEMU,
> using the command: 
> 
> ============
> $ qemu-system-x86_64 -M pc -kernel images/bzImage -drive
> file=images/rootfs.ext2,if=ide -append root=/dev/sda -net nic,model=rtl8139 -net
> user

 ... it will take images/rootfs.ext2 and present it to the guest (= the
buildroot Linux) as if it's a complete hard disk. All the rest of your host
system (= your Ubuntu) is completely invisible to the guest. Similarly, the
guest will see an RTL8139 network interface even though you probably have a
completely different network card in your PC. The guest can only access things
that you explicitly pass to qemu.

> ============
> 
> This command works properly and Linux boots normally. After that, I created a
> ext4 partition on /dev/sda7, which I mapped on /mnt/btlinux/
> 
> ==================
> $ sudo tar -C /mnt/btlinux/ -xf images/rootfs.tar
> ==================

 To pass this to qemu, you could unmount /mnt/btlinux and then start qemu with:

qemu-system-x86_64 -M pc -kernel images/bzImage -drive file=/dev/sda7,if=ide
-append root=/dev/sda -net nic,model=rtl8139 -net user

i.e., replace images/rootfs.ext2 with /dev/sda7. This gives the guest direct
access to a single partition of your hard drive. Note that it is a very bad idea
to give the guest access to a mounted partition, since you'll have two OSes that
try to read and write it simultaneously and they'll have a different idea of
what is on there.

> 
> 
> All files were correctly extracted to the partition. Then, I added one more boot
> option on GRUB.cfg file.

 In fact, with the -kernel command line option, grub isn't even used. That's why
you don't see a menu and it starts Linux immediately.

[snip]

> 1 - Why QEMU boot work properly and when I extract the same image to /dev/sda7,
> the boot fails? 
> 2 - What is QEMU doing that the 'normal boot' process are not doing? 
> 3 - Why the file at /boot/bzImage can be found but the device /dev/sda7 can not?
> 4 - Am I missing something?

 Does this explain all your questions?

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Buildroot] Kernel panic while trying to boot qemu_x86_64_defconfig on notebook with dual boot.
  2015-10-16  6:05 ` Arnout Vandecappelle
@ 2015-10-16  9:33   ` Alexandre Oliveira
  2015-10-16  9:55     ` Arnout Vandecappelle
  0 siblings, 1 reply; 6+ messages in thread
From: Alexandre Oliveira @ 2015-10-16  9:33 UTC (permalink / raw
  To: buildroot

I realy Thank you Arnout for the asnwer.

There are still some questions to fully understand.

What I am trying to do now is do not use QEMU anymore.
I dont want to simulate a full computer. I want to boot the buildroot linux
after I reboot my notebook.

That's why I modified /boot/grub/grub.cfg from my Ubuntu, in order to
appear the new buildroot linux on bootloader after reboot.
There is not GRUB installed on buildroot linux.
After boot, GRUB will call /dev/sda7 operation system.
That's why I extracted the system image to /dev/sda7 partition. I wanna
boot it after reboot.

After reboot, I could start the kernel in /boot/bzImage inside /dev/sda7
partition.
However, kernel panics with:

===========================
VFS: Cannot open root device "sda7" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available
partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)  error -6
===========================

It looks like that in the new booting linux cannot find /dev/sda7 and mount
it on linux root directory /.

Do I explained it clearly now? Sorry about my poor english and explanation.
Is there another modification to do in order to boot buildroot linux on my
notebook?

Thanks again for the hurry answer and assistance !


Regards,
Alexandre Oliveira.



Em sex, 16 de out de 2015 ?s 03:47, Arnout Vandecappelle <arnout@mind.be>
escreveu:

>  Hi Alexandre,
>
>  I think you fail to understand what QEMU does. It emulates a complete PC.
> In
> other words...
>
> On 16-10-15 04:41, Alexandre Oliveira wrote:
> > Hello everyone.
> >
> > I am having a problem while trying to boot qemu_x86_64_defconfig on my
> notebook.
> > My configuration is really simple. The .config file is attached.
> >
> > Following the manual, I first tried to boot and run my configuration
> with QEMU,
> > using the command:
> >
> > ============
> > $ qemu-system-x86_64 -M pc -kernel images/bzImage -drive
> > file=images/rootfs.ext2,if=ide -append root=/dev/sda -net
> nic,model=rtl8139 -net
> > user
>
>  ... it will take images/rootfs.ext2 and present it to the guest (= the
> buildroot Linux) as if it's a complete hard disk. All the rest of your host
> system (= your Ubuntu) is completely invisible to the guest. Similarly, the
> guest will see an RTL8139 network interface even though you probably have a
> completely different network card in your PC. The guest can only access
> things
> that you explicitly pass to qemu.
>
> > ============
> >
> > This command works properly and Linux boots normally. After that, I
> created a
> > ext4 partition on /dev/sda7, which I mapped on /mnt/btlinux/
> >
> > ==================
> > $ sudo tar -C /mnt/btlinux/ -xf images/rootfs.tar
> > ==================
>
>  To pass this to qemu, you could unmount /mnt/btlinux and then start qemu
> with:
>
> qemu-system-x86_64 -M pc -kernel images/bzImage -drive
> file=/dev/sda7,if=ide
> -append root=/dev/sda -net nic,model=rtl8139 -net user
>
> i.e., replace images/rootfs.ext2 with /dev/sda7. This gives the guest
> direct
> access to a single partition of your hard drive. Note that it is a very
> bad idea
> to give the guest access to a mounted partition, since you'll have two
> OSes that
> try to read and write it simultaneously and they'll have a different idea
> of
> what is on there.
>
> >
> >
> > All files were correctly extracted to the partition. Then, I added one
> more boot
> > option on GRUB.cfg file.
>
>  In fact, with the -kernel command line option, grub isn't even used.
> That's why
> you don't see a menu and it starts Linux immediately.
>
> [snip]
>
> > 1 - Why QEMU boot work properly and when I extract the same image to
> /dev/sda7,
> > the boot fails?
> > 2 - What is QEMU doing that the 'normal boot' process are not doing?
> > 3 - Why the file at /boot/bzImage can be found but the device /dev/sda7
> can not?
> > 4 - Am I missing something?
>
>  Does this explain all your questions?
>
>  Regards,
>  Arnout
>
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151016/77eac59c/attachment.html>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Buildroot] Kernel panic while trying to boot qemu_x86_64_defconfig on notebook with dual boot.
  2015-10-16  9:33   ` Alexandre Oliveira
@ 2015-10-16  9:55     ` Arnout Vandecappelle
  2015-10-17  1:51       ` Alexandre Oliveira
  0 siblings, 1 reply; 6+ messages in thread
From: Arnout Vandecappelle @ 2015-10-16  9:55 UTC (permalink / raw
  To: buildroot

 Hi Alexandre,

 [Please don't top-post, but reply in-line with the quoted text as is done
below. Also remove redundant pieces of quoted text.]

On 16-10-15 11:33, Alexandre Oliveira wrote:
> I realy Thank you Arnout for the asnwer.
> 
> There are still some questions to fully understand.
> 
> What I am trying to do now is do not use QEMU anymore.
> I dont want to simulate a full computer. I want to boot the buildroot linux
> after I reboot my notebook.

 Ah, OK, that really wasn't clear.

[snip]
> After reboot, I could start the kernel in /boot/bzImage inside /dev/sda7 partition.
> However, kernel panics with:
> 
> ===========================
> VFS: Cannot open root device "sda7" or unknown-block(0,0)
> Please append a correct "root=" boot option; here are the available partitions:
> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
>  error -6
> ===========================

 Normally, the kernel should also dump a list of block devices that it found. If
it doesn't, then probably the drivers for your disk are not built into the
kernel. In "big" distroes like Debian/Ubuntu, there is an initramfs which
contains all possible drivers are modules and the correct one is loaded at boot
time. The qemu defconfig in Buildroot is really minimal, it only contains a PIIX
driver.

 To find the correct driver(s), do 'lsmod' in your ubuntu system. You'll get a
long list of modules currently loaded, and you have to look for the ones that
are related to the disk. Most likely, it's CONFIG_SATA_AHCI (module ahci) that
you need. You'll probably also need CONFIG_MSDOS_PARTITION.

 To enable these, run 'make linux-menuconfig', type / to search for the options
you need, enable them (with y, not with m), and rebuild.

 Regards,
 Arnout


[snip]


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Buildroot] Kernel panic while trying to boot qemu_x86_64_defconfig on notebook with dual boot.
  2015-10-16  9:55     ` Arnout Vandecappelle
@ 2015-10-17  1:51       ` Alexandre Oliveira
  2015-10-20  0:33         ` Alexandre Oliveira
  0 siblings, 1 reply; 6+ messages in thread
From: Alexandre Oliveira @ 2015-10-17  1:51 UTC (permalink / raw
  To: buildroot

>  Hi Alexandre,
>
>  [Please don't top-post, but reply in-line with the quoted text as is done
> below. Also remove redundant pieces of quoted text.]
>

I realized this right after sending the email. I am sorry.


>  Normally, the kernel should also dump a list of block devices that it
> found. If
> it doesn't, then probably the drivers for your disk are not built into the
> kernel. In "big" distroes like Debian/Ubuntu, there is an initramfs which
> contains all possible drivers are modules and the correct one is loaded at
> boot
> time. The qemu defconfig in Buildroot is really minimal, it only contains
> a PIIX
> driver.
>

I attached init RAM disk into kernel with the option:
[*] initial RAM  filesystem  linked into kernel. (Filesystem images menu).
This avoid the need of calling a initramfs in the GRUB options. That's
right?


>
>  To find the correct driver(s), do 'lsmod' in your ubuntu system. You'll
> get a
> long list of modules currently loaded, and you have to look for the ones
> that
> are related to the disk. Most likely, it's CONFIG_SATA_AHCI (module ahci)
> that
> you need. You'll probably also need CONFIG_MSDOS_PARTITION.

 To enable these, run 'make linux-menuconfig', type / to search for the
> options
> you need, enable them (with y, not with m), and rebuild.
>

'lsmod' command returns:
ahci                   36864  2
libahci                32768  1 ahci

'lspci' command returns:
00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6
port SATA AHCI Controller (rev 05)

The option CONFIG_SATA_AHCI  was not set.
I just add it and re-make the buildroot linux system.

After that, I run this script inside output directory:

========
#!/bin/bash
sudo umount /dev/sda7
sudo mount /dev/sda7 /mnt/btlinux/
sudo rm -rf /mnt/btlinux/*
sudo tar -C /mnt/btlinux/ -xf images/rootfs.tar
sudo cp fstab /mnt/btlinux/etc/
========

the fstab has two new lines:

====
/dev/sda7        / ext4         defaults 1 1
/dev/sda5        none swap defaults 0 0
====

Then, I reboot notebook an GRUB calls:

=======
menuentry 'Build root (em /dev/sda7)' --class gnu-linux --class gnu --class
os $menuentry_id_option
'osprober-gnulinux-simple-96eafc8c-0063-417a-9c32-4ea96ee97b55' {
insmod part_msdos
insmod ext2
set root='hd0,msdos7'
if [ x$feature_platform_search_hint = xy ]; then
 search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7
--hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7
 96eafc8c-0063-417a-9c32-4ea96ee97b55
else
 search --no-floppy --fs-uuid --set=root
96eafc8c-0063-417a-9c32-4ea96ee97b55
fi
linux /boot/bzImage root=/dev/sda7 console=tty1

}
=========

But, after reboot, the same error is happening...

===========================
VFS: Cannot open root device "sda7" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available
partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)  error -6
===========================


I already learned a lot with your answers.
I tried to add another Intel SATA drivers on Device Drivers menus from
$make linux-menuconfig but the same error occurs...

Do you have any new guess?
Thank you in advance for the help.


Best Regards,
Alexandre Oliveira.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151017/49d3f50b/attachment.html>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Buildroot] Kernel panic while trying to boot qemu_x86_64_defconfig on notebook with dual boot.
  2015-10-17  1:51       ` Alexandre Oliveira
@ 2015-10-20  0:33         ` Alexandre Oliveira
  0 siblings, 0 replies; 6+ messages in thread
From: Alexandre Oliveira @ 2015-10-20  0:33 UTC (permalink / raw
  To: buildroot

Hello again,

It looks like I had some trash compiling code.

I just clean everything and build again, with your advices and it works.

There is no need to change fstab file.

I attached initramdisk to kernel and AHCI support.
Then, I run the following commands.

$ sudo umount /dev/sda7
$ sudo mount /dev/sda7 /mnt/btlinux/
$ sudo rm -rf /mnt/btlinux/*
$ sudo tar -C /mnt/btlinux/ -xf images/rootfs.tar
$ sudo mkdir /mnt/btlinux/boot
$ sudo cp /home/alexandre/x86_64output/images/bzImage /mnt/btlinux/boot/
$ sudo umount /dev/sda7

After that, I reboot and boot with GRUB like the e-mails before.

Thank you for the help.

Att.
Alexandre Oliveira.


Em sex, 16 de out de 2015 ?s 22:51, Alexandre Oliveira <
alexandrenagy@gmail.com> escreveu:

>
>  Hi Alexandre,
>>
>>  [Please don't top-post, but reply in-line with the quoted text as is done
>> below. Also remove redundant pieces of quoted text.]
>>
>
> I realized this right after sending the email. I am sorry.
>
>
>>  Normally, the kernel should also dump a list of block devices that it
>> found. If
>> it doesn't, then probably the drivers for your disk are not built into the
>> kernel. In "big" distroes like Debian/Ubuntu, there is an initramfs which
>> contains all possible drivers are modules and the correct one is loaded
>> at boot
>> time. The qemu defconfig in Buildroot is really minimal, it only contains
>> a PIIX
>> driver.
>>
>
> I attached init RAM disk into kernel with the option:
> [*] initial RAM  filesystem  linked into kernel. (Filesystem images menu).
> This avoid the need of calling a initramfs in the GRUB options. That's
> right?
>
>
>>
>>  To find the correct driver(s), do 'lsmod' in your ubuntu system. You'll
>> get a
>> long list of modules currently loaded, and you have to look for the ones
>> that
>> are related to the disk. Most likely, it's CONFIG_SATA_AHCI (module ahci)
>> that
>> you need. You'll probably also need CONFIG_MSDOS_PARTITION.
>
>  To enable these, run 'make linux-menuconfig', type / to search for the
>> options
>> you need, enable them (with y, not with m), and rebuild.
>>
>
> 'lsmod' command returns:
> ahci                   36864  2
> libahci                32768  1 ahci
>
> 'lspci' command returns:
> 00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6
> port SATA AHCI Controller (rev 05)
>
> The option CONFIG_SATA_AHCI  was not set.
> I just add it and re-make the buildroot linux system.
>
> After that, I run this script inside output directory:
>
> ========
> #!/bin/bash
> sudo umount /dev/sda7
> sudo mount /dev/sda7 /mnt/btlinux/
> sudo rm -rf /mnt/btlinux/*
> sudo tar -C /mnt/btlinux/ -xf images/rootfs.tar
> sudo cp fstab /mnt/btlinux/etc/
> ========
>
> the fstab has two new lines:
>
> ====
> /dev/sda7        / ext4         defaults 1 1
> /dev/sda5        none swap defaults 0 0
> ====
>
> Then, I reboot notebook an GRUB calls:
>
> =======
> menuentry 'Build root (em /dev/sda7)' --class gnu-linux --class gnu
> --class os $menuentry_id_option
> 'osprober-gnulinux-simple-96eafc8c-0063-417a-9c32-4ea96ee97b55' {
> insmod part_msdos
> insmod ext2
> set root='hd0,msdos7'
> if [ x$feature_platform_search_hint = xy ]; then
>  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7
> --hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7
>  96eafc8c-0063-417a-9c32-4ea96ee97b55
> else
>  search --no-floppy --fs-uuid --set=root
> 96eafc8c-0063-417a-9c32-4ea96ee97b55
> fi
> linux /boot/bzImage root=/dev/sda7 console=tty1
>
> }
> =========
>
> But, after reboot, the same error is happening...
>
> ===========================
> VFS: Cannot open root device "sda7" or unknown-block(0,0)
> Please append a correct "root=" boot option; here are the available
> partitions:
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,0)  error -6
> ===========================
>
>
> I already learned a lot with your answers.
> I tried to add another Intel SATA drivers on Device Drivers menus from
> $make linux-menuconfig but the same error occurs...
>
> Do you have any new guess?
> Thank you in advance for the help.
>
>
> Best Regards,
> Alexandre Oliveira.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151020/f1291ee1/attachment.html>

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2015-10-20  0:33 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-16  2:41 [Buildroot] Kernel panic while trying to boot qemu_x86_64_defconfig on notebook with dual boot Alexandre Oliveira
2015-10-16  6:05 ` Arnout Vandecappelle
2015-10-16  9:33   ` Alexandre Oliveira
2015-10-16  9:55     ` Arnout Vandecappelle
2015-10-17  1:51       ` Alexandre Oliveira
2015-10-20  0:33         ` Alexandre Oliveira

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.