On Tue, 2009-07-07 at 13:08 +0930, Arthur Marsh wrote:
Pavel Roskin wrote, on 07/07/09 11:28:
On Tue, 2009-07-07 at 10:41 +0930, Arthur Marsh wrote:
using grub-emu at the moment. I'll try in real grub when I reboot.
Could you please try booting Linux in grub-emu? You can interrupt qemu
before the kernel tries to mount anything. Or you can remove the
"linux" line. What matters is whether the "search" command works. That
would show if BIOS limitations play any role.
I haven't used grub-emu to boot linux.
Sorry, I was thinking about qemu when I wrote this.
In grub-emu I get:
sh:grub> ls -l
Device hd0: Partition table
Partition hd0,7: Filesystem type ext2, Last modification time
2009-07-07
03:21:45 Tuesday, UUID 96c96a61-8615-4715-86d0-09cb8c62638c
Partition hd0,6: Filesystem type fat, UUID 7417-5aff
Partition hd0,5: Unknown filesystem
Partition hd0,1: Filesystem type ext2, Last modification time
2009-07-07
03:23:54 Tuesday, UUID bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea
sh:grub> search -l ""
Segmentation fault
This should be fixed in Subversion. My mistake. Please test it. The
patch for unifying search won't help solve this problem.
In real grub:
ls -l
hd0: Partition table
Partition hd0,1: Filesystem cannot be accessed
Device hd1: filesysetm cannot be accessed
Device hd2: filesystem cannot be accessed
Device fd0: Filesystem cannot be accessed
error: no such disk
That means that grub_device_open() fails for all of them. Something is
seriously wrong here. Yet somehow the Linux kernel can be loaded.