Re: [PATCH] Support OpenIndiana in GRUB2

Re: [PATCH] Support OpenIndiana in GRUB2

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

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.
> 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)
> 2) What's the best way to handle "local" keyword?
> 3) Does Illumos support* multiple kernels?
> 4) Does Illumos support* snapshot or subvolume booting
>
> *=support=kernel is capable of handling it, we can do whatever we want
> on bootloader level.
>


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



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

Re: [PATCH] Support OpenIndiana in GRUB2

[Seth Goldberg]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1307 bytes --]



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

>> 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).

>> 2) What's the best way to handle "local" keyword?

   Remove it ;) ?

>> 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.

  --S

Re: [PATCH] Support OpenIndiana in GRUB2

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

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.
>>> 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.
>>> 2) What's the best way to handle "local" keyword?
>
>   Remove it ;) ?
>
I have a patch for it few lines down in this ML.
>>> 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?
>
>  --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 --]

Re: [PATCH] Support OpenIndiana in GRUB2

[Seth Goldberg]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3022 bytes --]



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).

  Thanks,
  --S

Re: [PATCH] Support OpenIndiana in GRUB2

[Seth Goldberg]

>> (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.

   The key issue is that it's possible to have BEs on a system that predate the 
installation of GRUB2, so if one of THOSE BEs change the default bootfs (which 
they will, since the beadm activate subcommand does just that), the grub.cfg 
would be out of date.  I don't see any alternative to having GRUB2 do the scan 
to map the bootfs object to a zfs name :(.

  --S

Re: [PATCH] Support OpenIndiana in GRUB2

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- 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 --]

Re: [oi-dev] [PATCH] Support OpenIndiana in GRUB2

[Vladimir 'φ-coder/phcoder' Serbinenko]

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


> Once zfs boot/root came on the scene I stopped using Install entirely.
>
> You can find some documentation on Install.sh at
> http://hub.opensolaris.org/bin/view/Community+Group+on/devref_5 but I don't
> think it's worth going out of your way to support this use case.
>
Thanks for the information. Given that GRUB2 has a complete ZFS support
(including raidz and crypto) unless UFS installs are still a target I
see no reason resurrect something that didn't work properly in the first
place and probably is degraded by now.

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



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