Quoting Robert Millan <[EMAIL PROTECTED]>:
> On Wed, Jan 30, 2008 at 06:48:11AM +0100, Tristan Gingold wrote:
>
> grub-probe is missing. Did you check if it works? Although, I think it
> should just move to common.rmk. I'll have a look at that.
Ok.
> > diff -ruNp -x '*~' -x CVS -x autom4te.cache -x '*.mk' -x configure
> grub2.orig/util/ia64/efi/grub-install.in grub2/util/ia64/efi/grub-install.in
> > --- grub2.orig/util/ia64/efi/grub-install.in 1970-01-01
> > 01:00:00.000000000
> +0100
> > +++ grub2/util/ia64/efi/grub-install.in 2008-01-28 16:29:58.000000000
> > +0100
> > [...]
> > +grub_probefs=${sbindir}/grub-probefs
>
> grub-probefs was renamed to grub-probe.
Ok, I missed that.
> > +# Create the core image. First, auto-detect the filesystme module.
> > +#fs_module=`$grub_probefs --device-map=${device_map} ${grubdir}`
> > +#if test "x$fs_module" = x -a "x$modules" = x; then
> > +# echo "Auto-detection of a filesystem module failed." 1>&2
> > +# echo "Please specify the module with the option \`--modules'
> explicitly." 1>&2
> > +# exit 1
> > +#fi
>
> Why is this commented out? Is ${grubdir} a mount point to efi's boot
> memory device?
Yes.
> We do that on i386 (I don't claim that it is a good way,
> in fact I dislike it and Okuji does as well, but if we want to change it I
> expect we'll want to change it in both).
>
> Also, missing partmap_module and devabstraction_module. I think you should
> resync this with the latest version of i386/efi/grub-install.in.
Will do.
> > +modules="kernel
>
> kernel isn't implicit?
Should be.
> > gpt
>
> Is gpt mandatory?
Almost.
> We can use gpt without efi; I wonder if we can also use
> efi without gpt. If you can access the raw disk, any partition map (even no
> partition map at all!) could be used, right?
Not really. EFI has to load grub, and EFI only always knows GPT+FAT.
> > fat
>
> Even if fat is mandated by the standard, I think it's safer to probe for
> that,
> since we have the mechanism to do it (grub-probe also performs some sanity
> checks that would detect if the fat is corrupted or so).
Sure.
> > gzio normal ls cat fshelp help _linux linux memmap systab boot
>
> Why this selection specificaly?
That's the one I used and tested :-)
> Other ports without significant size limit
> just encourage the user to do "grub-mkimage *.mod -o foo" or manually select
> what is needed.
Ok.
> Or it wasn't possible to load additional modules in runtime yet? I don't
> remember well..
Yes, you currently can't dynload modules.
> > +# Generate init/fini for modules.
> > +modfile=$tmpdir/mod.c
> > +echo "/* Dummy modules. */" > $modfile
> > +list=""
> > +init_list=""
> > +fini_list=""
> > +for m in $modules; do
> > + file="$pkglibdir/${m}.mod"
> > + name=`nm $file | sed -n "/ r grub_module_name/ s/.* r
> grub_module_name_\(.*\)/\1/p"`
> > + init=`nm $file | sed -n "/ T grub_module_.*_init/ s/.* T //p"`
> > + fini=`nm $file | sed -n "/ T grub_module_.*_fini/ s/.* T //p"`
> > + init_list="$init_list $init"
> > + fini_list="$fini_list $fini"
> > + arg="\"$name\",${init:-0},${fini:-0}"
> > + list="$list $arg"
> > +done
>
> Is there a way we can do this before to avoid runtime dependency on binutils?
This is part of the module trick ;-). If we build a grub with all modules,
this is not necessary anymore.
> Btw has this been tested on i386-efi ?
No. I only have access to an EFI simulator on i386.
Tristan.
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
