[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Support OpenIndiana in GRUB2

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [PATCH] Support OpenIndiana in GRUB2
Date: Tue, 08 Nov 2011 21:01:28 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15

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
>>>>> 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
> address@hidden

Vladimir 'φ-coder/phcoder' Serbinenko

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]