Overlaying default grub.cfg makes qemu "fat:" partition inaccessible

Overlaying default grub.cfg makes qemu "fat:" partition inaccessible

[James Collier]

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]

Hi all,
I'm using GRUB2 from svn (r2039) with qemu.
Steps I take to reproduce:
1. create an overlay directory e.g. /grub2/overlay
2. populate the directory with
	overlay/boot
	overlay/boot/grub
	overlay/goot/grub/grub.cfg
Where grub.cfg contains "some-menuentry" for example I use:
menuentry "Viengoos" {
	multiboot /viengoos -D 3 -o serial
	module /hieronymus
}

3. run (option1): 
$ cd /grub2
$ grub-mkrescue --image-type=floppy --emulation=floppy \
--overlay=overlay  grub2-boot-floppy


or (option2): 
$ cd /grub2
$ grub-mkrescue --image-type=cdrom --overlay=overlay \ grub2-boot-cdrom

4. start qemu with:
$ cd /grub2
(option 1):
$ qemu --serial stdio -hda fat:kernel-dir -fda grub2-boot-floppy -boot a
or
(option 2):
$ qemu --serial stdio -hda fat:kernel-dir -fda grub2-boot-cdrom -boot d

In the case of option 1, grub2 boots straight to the menu as expected.
Typeing 'c' to get to the prompt then 'ls' at the prompt reveals only
the (memdisk) device.
It was expected that at least (hd0,1) for the -hda fat: partition would
be available

Option: following the above and typing 'ls' at the prompt reveals
(hd0) and (hd96) where (hd0,1) was also expected as above.

qemu version 0.9.1

Thanks,

James Collier

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Overlaying default grub.cfg makes qemu "fat:" partition inaccessible

[Pavel Roskin]

Quoting James Collier <james.collier412@gmail.com>:

> In the case of option 1, grub2 boots straight to the menu as expected.
> Typeing 'c' to get to the prompt then 'ls' at the prompt reveals only
> the (memdisk) device.
> It was expected that at least (hd0,1) for the -hda fat: partition would
> be available

Even without the -hda option, you should get (fd0).  I can reproduce  
the problem with the current GRUB.

My impression is that loading grub.cfg stops the initial automatic  
loading of the modules for the existing hardware.  You still can load  
such modules manually:

insmod biosdisk
insmod pc

After that, ls will show (fd0) and other devices.

It looks like a bug to me.

-- 
Regards,
Pavel Roskin

Re: Overlaying default grub.cfg makes qemu "fat:" partition inaccessible

[Neal H. Walfield]

Taking a look at grub-mkrescue, it seems that it creates a
boot/grub/grub.cfg that executes an insmod for each specified module.
It then copies the overlay files overwriting the just-created
grub.cfg.

The user's grub.cfg should either be appended to the one created by
grub-mkrescue or there should be a way to specify a config file, which
the generated grub.cfg loads.

Neal

Re: Overlaying default grub.cfg makes qemu "fat:" partition inaccessible

[Pavel Roskin]

On Wed, 2009-03-25 at 13:39 +0100, Neal H. Walfield wrote:
> Taking a look at grub-mkrescue, it seems that it creates a
> boot/grub/grub.cfg that executes an insmod for each specified module.
> It then copies the overlay files overwriting the just-created
> grub.cfg.
> 
> The user's grub.cfg should either be appended to the one created by
> grub-mkrescue or there should be a way to specify a config file, which
> the generated grub.cfg loads.

This behavior seems inconsistent to me.  It's not like loading grub.cfg
is the main goal of GRUB.  The main goal is loading an OS, which may
require more modules.

An equivalent in the OS world would be an OS failing to load network
drivers if X window system is started successfully.

Perhaps loading of grub.cfg should be separated from entering the normal
mode.

-- 
Regards,
Pavel Roskin