Re: Locating a configuration file (*.cfg)

[Arbiel (gmx)]

Le 07/11/2015 07:06, Andrei Borzenkov a écrit :
> 07.11.2015 00:25, Arbiel (gmx) пишет:
>>
>>
>> Le 30/10/2015 16:25, Andrei Borzenkov a écrit :
>>> 30.10.2015 15:37, Arbiel (gmx) пишет:
>>>
>>>>>> 3) To complement this grub script, I want to write a bash script to
>>>>>> set
>>>>>> a environment variable which the grub script has to reset. grub
>>>>>> seems to
>>>>>> not support save_env to a grubenv file located on a logical
>>>>>> volume. Is
>>>>>> it possible to replace the load_env and a save_env commands by
>>>>>> identically named functions which would use these 2 commands with
>>>>>> the -f
>>>>>> parameter (and doing so, would allow for the correct operation of
>>>>>> recordfail) ?
>>>>>>
>>>>> There is no support for writing on top of diskfilter devices - LVM,
>>>>> Linux MD etc. It may be possible to implement limited support for
>>>>> linear and RAID0 type of storage. Anything else is too complicated to
>>>>> warrant doing it. I would be happy if someone could suggest
>>>>> implementation that allowed environment block to be located anywhere,
>>>>> not only as file on a filesystem. openSUSE does something similar for
>>>>> btrfs as special case.
>> My suggestion would be : not really anywhere, but in core.img. I
>
> a) this just changes the question to "how do you find location of
> core.img"
I suppose your question to concern boot-time (load_env and save_env), as
bootinfoscript perfectly knows where core.img is located. Couldn't a
grub variable (grubenv_location) be defined and set by core to hold this
information, as do prefix and config_dirertory.
> b) there could be any number of core.img located anywhere and all
> accessing the same /boot/grub. They all must see the same environment
> block belonging to their /boot/grub, which effectively defines *the*
> installed grub instance.
You are right, and I should have thought to this case, as it is my own
situation. To overcome the tentative writing into the read-only grubenv,
I've installed grub on several USB keys, however all of them with their
own read-write /boot/grub/{grub.cfg,grubenv} and their grub.cfg locating
the effective grub.cfg to "configfile" it. In other words I've
replicated grubenv.

I really believe that there are two types of environment variables, the
ones which are only read by grub (users may wish to pass permanent
information to grub) and the ones which are intended to transfer
information from one run of grub to the next one (next_entry,
recordfail,…). The former can remain unique in *the* installed grub
instance, but the later could be located in the running core. The
advantage is obvious : grub will be able to set and reset those
variables, as it is supposed to do. The drawback also is obvious : if
the user changes their running core from one run to the next, they can
get a little confused. The grub manual will be essential to help them
understand the issue.

All environment variables should remain listed in grubenv, but their
value could be either in grubenv, as for now, and for "permanent"
variable, or in core.img, as I suggest, for "transient" ones. There are
many ways to implement such a mecanism.

By the way, how is "recordfail" reset to 0 ?
>
>> understand this would increase core.img's size by one block, which could
>> be a major drawback for older system. So, the inclusion of the
>> environment block into core.img should be controlled by a
>> "--grubenv-incore" parameter in grub-install. And this parameter could
>> also be discarted if there is not enough available room.
>> grub's load_env and save_env commands, linux grub-install and
>> grub-editenv commands should be the only ones to be modified.
>> If this suggestion fits you, I'm sure you will find a way to assume
>> compatibility with the current situation.
>>
>>
>>>> My question was maybe not clear enough. I meant in "to replace
>>>> load_env …"
>>>> writing in my script sort of an alias to overwrite the commands.
>>>>
>>>
>>> Can you "replace write system call" to write to a file system that is
>>> mounted read-only?
>> I do not understand your question.
>
> GRUB diskfilter device is read-only. Period. It does not matter how
> command is named - *no* command is able to write on diskfilter.
>

signature.asc
Description: OpenPGP digital signature