Re: [PATCH] Support OpenIndiana in GRUB2

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

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

On 08.11.2011 20:37, Seth Goldberg wrote:
>
>
> Quoting Vladimir 'φ-coder/phcoder' Serbinenko, who wrote the following
> on...:
>
>> On 08.11.2011 19:16, Seth Goldberg wrote:
>>>
>>>
>>> Quoting Vladimir 'φ-coder/phcoder' Serbinenko, who wrote the following
>>> on...:
>>>
>>>> Resending because of wrong oi-dev address at first try which caused it
>>>> to be rejected from other 2 lists as well
>>>> On 08.11.2011 02:19, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>>> With this patch on top of trunk I was able to compile (using
>>>>> GCC+GAS+GNU
>>>>> LD), install, generate config and boot OpenIndiana. Some areas are
>>>>> grey
>>>>> to me. As like:
>>>>> 1) Is it better to determine zfs-bootfs parameter on boot or on
>>>>> config.
>>>
>>> (These opinions are based on Oracle Solaris):
>>> Some grub entries may not specify a bootfs, in which case, GRUB should
>>> derive it from the bootfs property in the pool
>>>
>> bootfs is an annoying one since on-disk AFAIK only its objnum is stored
>> so we need to scan to determine its name. But for me it's only
>> backward-compatibility issue. This property shouldn't be necessary with
>> new or autodetected config.
>
>   It's true you can get around it by triggering a config file
> autogeneration when the bootfs property is changed.
>
>>>>> GRUB-Legacy does former but it has the problem that rpool may be
>>>>> inaccessible to GRUB (it may be that only /boot/grub is accessible
>>>>> to it)
>>>
>>>   If the rpool is in accessible, then the top-level dataset should
>>> also be inaccessible (unless I'm misunderstanding what you mean).
>>>
>> You can have a small disk locally holding only GRUB2, kernel and boot
>> archive and rpool in a SAN, boot_archive taking care of mounting rpool.
>
>   I'm not aware of any OpenSolaris distro doing that, but it is
> possible.  In that case, it's up to the administrator to ensure that
> the bootfs value used is correct and that the pool is accessible to
> GRUB2.
>
>
>>>>> 2) What's the best way to handle "local" keyword?
>>>
>>>   Remove it ;) ?
>>>
>> I have a patch for it few lines down in this ML.
>
>   LGTM.
>
>>>>> 3) Does Illumos support* multiple kernels?
>>>
>>> (For O.S.)  This is something that developers would use, IMHO, but not
>>> something for production, because the boot environment construct is
>>> used to isolate different bootable instances.
>> Could you explain better what's boot environment is? Is it separate
>> subvolume? How do we discover them. Should it be on runtime or config
>> time?
>
>   A boot environment is a child zfs dataset whose name is of a
> specific form (<poolname>/ROOT/<BEname>).  Each boot environment is a
> separate, fully-contained bootable instance of Solaris.  As of the
> last OpenSolaris release, the only shared state is that state stored
> on the top-level dataset of the root pool (that include the Legacy
> GRUB menu.lst, boot signature (just a file that can be used to
> identify the pool with findroot()), and some other miscellaneous
> data). (See the beadm(1M) command for a better explanation).
>
Sounds like something trivial to scan for at boot time (and we already
have everything we need to) thus reducing transition difficulty.
>  Thanks,
>  --S
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]