[Top][All Lists]

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

Re: Locating a configuration file (*.cfg)

From: Arbiel (gmx)
Subject: Re: Locating a configuration file (*.cfg)
Date: Sat, 7 Nov 2015 20:41:25 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

I've just found at

      13.2 The GRUB environment block

For safety reasons, this storage is only available when installed on a
plain disk (no LVM or RAID), using a non-checksumming filesystem (no
ZFS), and using BIOS or EFI functions (no ATA, USB or IEEE1275).

As I don't quite understand "and using BIOS or EFI functions (no ATA,
USB or IEEE1275)", I want to state here that environment blocks on USB
FAT file systems are available.

Le 07/11/2015 19:54, Arbiel (gmx) a écrit :
> 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
> 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.
> _______________________________________________
> Help-grub mailing list
> address@hidden

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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