Re: Anyone willing to sponsor an ARC case for grub2?

[Vladimir 'phcoder' Serbinenko]

>>> 2) The one thing from the prior thread which stood out was the need for
>>> netboot support.  Maybe Vladimir (phcoder) can comment on how far along this
>>> is in GRUB2
>>
>> If it isn't a complete replacement for what is in GRUB1 then switching to
>> GRUB2 is a complete non starter.
>>
>> If that isn't what you are saying and I'm miss interpreting it can you
>> explain what, if anything, we lose by moving to GRUB2 ?
>>
>>> Is it possible to limit the ARC case for only GRUB2 + zfs support?  Is
>>
>> So you are proposing that we intentionally break net install ?  That would
>> not lead to a successful ARC review and very likely cause it to be denied.
>>
GRUB2 already supports pxe. The only netboot present in grub1 and not
in grub2 is tftp support when grub is booted from hard drive. David
Miller was interested on coding TCP/IP stack for grub2 which would
mean FTP and network shell support. If he doesn't do it I'll do when I
have a bit more time (in September probably)
>
>  Switching to GRUB 2 is a medium sized undertaking that involves rolling all
> the things we've fixed and added in legacy GRUB into it.
Forgive me the harsh wording that follow but at least some "fixes" for
grub-solaris are junk and not to be considered ok. One example is the
function is_top_dataset file. Basically grub2 checks the filename and
depending on it takes it from different datasets. This is a workaround
for a limitation introduced by coding procedure which normally doesn't
allow to access multiple datasets in the same time. In my personal
repository you can find a port of zfs to grub2. It uses the following
syntax to access files:
(hdX,Y)/address@hidden/filename
as neither filesystem name nor snapshot name can contain @ and
snapshot name can't contain / this is unambiguous.
> It would be really
> nice if we could manage most of this in a manner that would allow  these
> changes to be accepted upstream.
I already did some fixes. AFAIK only one thing is missing: a command
to retrieve zfs information to pass it to kernel. Remaining fixes are
on the kernel side. I outlined it in
http://lists.gnu.org/archive/html/grub-devel/2009-03/msg00035.html
All 3 points are solaris bugs. One of them is workarounded in current
grub2 but it still has to be fixed on kernel side (you don't comply
with multiboot standard)
>
>  Since the menu changes significantly this will basically break all the
> legacy installers/upgraders and kill nevada for x86.
We now have a scripting support both for lua and sh. Both advance now
and with proposed patches lua scripting would be able to create menu
on runtime listing all installed OSes.
> I'm at peace with that,
> but this project can't be the one that drives that, so I'd suggest timing
> integration accordingly (this should roughly line up correctly if
> EFI drags GRUB 2 in).
I think multiboot standard could be extended to pass SMBIOS/RSDP
pointer to payload. It would allow kernel to stay unaware if it runs
on EFI, BIOS or Coreboot. We're also creating multiboot2 standard
which is meant to be portable. We have sparc64 grub port and in my git
grub2 already parses big-endian volumes. Perhaps solaris could use
multiboot2 everywhere? Your propositions for the multiboot2 standard
are welcome
>
>  The slim install and beadm will need to learn to deal with the new menus.
> Likely beadm will need to learn how to generate a new menu for existing
> entries. libgrubmgmt (which parses the GRUB menu for fast reboot) will need
> to learn to deal with the new menus.
>
> -jan
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git