Re: Locating a configuration file (*.cfg)

[Arbiel (gmx)]

Le 07/11/2015 11:46, Andrei Borzenkov a écrit :
> 07.11.2015 13:25, Arbiel (gmx) пишет:
>>>> 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
>
> Both boot time and run time need to find it.
>
>> grub variable (grubenv_location) be defined and set by core to hold this
>> information, as do prefix and config_dirertory.
>
> Prefix and config are identified by filesystem UUID (or file with
> unique file name). How do you identify raw disk location?
>
>>
>> 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,…).
>
> Environment block only serves to pass information between grub
> invocations or between OS and GRUB.
>
>>
>> All environment variables should remain listed in grubenv, but their
>
> This is unfortunate confusion in using "environment" both for internal
> GRUB variables and external environment block. GRUB variables are not
> stored anywhere - they exist only when GRUB is running. Some of them
> may be initialized from environment block. Some of them from $prefix
> core.img section or by embedded config script.
>
>> 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.
>>
>
> There is no need or reason to store "transient" variables anywhere.
> They are stored in RAM when GRUB runs and are not required or needed
> after GRUB finished.
>
>> By the way, how is "recordfail" reset to 0 ?
>>>
>
> This variable does not exist upstream so you need to ask your distro
> which probably added it. I do not know what it does. Which distro is it?
>
>
It appears that I made some confusion as well at the terminology level
as at the role and responsability level.

Somehow, and even if this is clearly stated through the present mailing
list, as an end-user I forgot the role of the Ubuntu team in the
provisionning of grub. grub development team cannot be accountable for
the way Ubuntu's team use grub to boot their OSs, that is for the
grub.cfg file, and the way they use the environment block.

In Ubuntu OSs, at least those I feel comfortable with, $recordfail is
used to remember the failure of a boot process. It is set by grub.cfg
and probably reset after grub has released control to the booted OS. At
least, as it cannot be reset by the grub "boot" command, which does not
know anything about it, it has to be released somewhere down the control
chain. The fact that it is not reset at boot time means that the
preceding boot process has failed, and some specific action can then be
taken.

Regarding grubenv, and the fact that in some circonstances save_env will
fail, does not appear in the documentation, at least the one I just
accessed a few minutes ago at
http://www.gnu.org/software/grub/manual/grub.html. No mention of any
write restriction on some file systems or file organisations prevents
the various system designers.

I thank you for the time you spend in answering my questions.

signature.asc
Description: OpenPGP digital signature