Opened 12 years ago
Last modified 12 years ago
#648 assigned enhancement
Additional Control Over Boot in Mindi Configuration
Reported by: | Matthew Ross | Owned by: | Bruno Cornec |
---|---|---|---|
Priority: | low | Milestone: | 3.0.5 |
Component: | mindi | Version: | 3.0.2 |
Severity: | trivial | Keywords: | |
Cc: |
Description
I have run into a scenario where it would be useful to have a little more control over how recovery media boots. In particular, the boot loader timeout and default boot option.
For my purposes, it would be useful to have restoration media timeout quickly and boot into expert mode as a default. Once booted the user will be able to select backups from library disk to restore from via a script (that eventually call on mondorestore).
Using mindi versus mondo would be an option to get expert working as the default but it would require that I handle the generation of CD/DVD media externally, something which mondo does nicely already.
The changes required to implement this are minimal.
Establish globals prior sourcing mindi.conf:
MINDI_ADDITIONAL_BOOT_PARAMS="..." MINDI_DEFAULT_BOOT_OPTION="" MINDI_BOOT_TIMEOUT=""
in MakeBootConfFile, handle the mindi.conf default option and timeout for mondoarchive non-CDRECOVERY only:
MakeBootConfFile() { ... # Compute which default option to boot from ... elif [ _"$MONDO_SHARE" != _"" ]; then if [ -e "$MINDI_TMP/NETFS-DEV" ]; then echo -en "default${sep}iso\n" elif [ "$MINDI_DEFAULT_BOOT_OPTION" != "" ]; then LogIt "Overriding default boot option: $MINDI_DEFAULT_BOOT_OPTION" echo -en "default${sep}${MINDI_DEFAULT_BOOT_OPTION}\n" else echo -en "default${sep}interactive\n" fi else .... # Handle timeout if [ "$CDRECOVERY" == "yes" ]; then echo -en "timeout${sep}1000\n" elif [ "$MINDI_BOOT_TIMEOUT" != "" ]; then LogIt "Overriding boot timeout: $MINDI_BOOT_TIMEOUT" echo -en "timeout${sep}${MINDI_BOOT_TIMEOUT}\n" else echo -en "timeout${sep}300\n" fi .... }
A small change but one that would be useful.
Attachments (2)
Change History (7)
follow-up: 3 comment:1 by , 12 years ago
follow-up: 4 comment:2 by , 12 years ago
Additionally, it can be difficult to determine which options in mindi are intended to be overridden by mindi.conf. It would be nice if this were more obvious and perhaps if there was an option to generate a default config.
I have supplied version 2.1.3-r3026 with the functionality included to do so, along with the changes from the original boot option enhancements. Calling "mindi --makemindiconfig output.conf" will generate a config (output.conf) with the config options and their default values (as defined in mindi). I was not 100% sure on what all configuration options should be so I took a best guess (on the comments too).
Perhaps a little out of scope for this ticket but I believe it would be useful. Realistically, it would probably be best to include a validation function to check that configuration option were set within bounds.
by , 12 years ago
mindi with additional boot configuration options and default configuration generation
comment:3 by , 12 years ago
Status: | new → assigned |
---|
Replying to msross:
Better yet ...
MINDI_ADDITIONAL_BOOT_PARAMS="..." MINDI_DEFAULT_BOOT_OPTION="interactive" MINDI_BOOT_TIMEOUT=300and ...
MakeBootConfFile() { ... # Compute which default option to boot from ... elif [ _"$MONDO_SHARE" != _"" ]; then if [ -e "$MINDI_TMP/NETFS-DEV" ]; then echo -en "default${sep}iso\n" else echo -en "default${sep}${MINDI_DEFAULT_BOOT_OPTION}\n" fi else .... # Handle timeout if [ "$CDRECOVERY" == "yes" ]; then echo -en "timeout${sep}1000\n" else echo -en "timeout${sep}${MINDI_BOOT_TIMEOUT}\n" fi .... }Perhaps with a check to validate the option.
Of we let users with good conf file, I'm assuming that when they will change it they know what they do. So for now seems sufficient.
I've added that modification to rev [3053]
follow-up: 5 comment:4 by , 12 years ago
Replying to msross:
Additionally, it can be difficult to determine which options in mindi are intended to be overridden by mindi.conf. It would be nice if this were more obvious and perhaps if there was an option to generate a default config.
I have supplied version 2.1.3-r3026 with the functionality included to do so, along with the changes from the original boot option enhancements. Calling "mindi --makemindiconfig output.conf" will generate a config (output.conf) with the config options and their default values (as defined in mindi). I was not 100% sure on what all configuration options should be so I took a best guess (on the comments too).
Perhaps a little out of scope for this ticket but I believe it would be useful. Realistically, it would probably be best to include a validation function to check that configuration option were set within bounds.
Don't want to do too much with that version while I'm trying to rewrite stuff in perl with a different more broad approach. However, I'm still interested by your idea. Instead of a full file, could you provide a patch vs SVN so it would be easier for see what you propose, check and incorporate it ? TIA.
comment:5 by , 12 years ago
Replying to bruno:
Replying to msross:
Additionally, it can be difficult to determine which options in mindi are intended to be overridden by mindi.conf. It would be nice if this were more obvious and perhaps if there was an option to generate a default config.
I have supplied version 2.1.3-r3026 with the functionality included to do so, along with the changes from the original boot option enhancements. Calling "mindi --makemindiconfig output.conf" will generate a config (output.conf) with the config options and their default values (as defined in mindi). I was not 100% sure on what all configuration options should be so I took a best guess (on the comments too).
Perhaps a little out of scope for this ticket but I believe it would be useful. Realistically, it would probably be best to include a validation function to check that configuration option were set within bounds.
Don't want to do too much with that version while I'm trying to rewrite stuff in perl with a different more broad approach. However, I'm still interested by your idea. Instead of a full file, could you provide a patch vs SVN so it would be easier for see what you propose, check and incorporate it ? TIA.
Certainly I can write up the changes against again the latest 3.0 mindi in the repo and post on this ticket (don't think I would have any commit permissions on the repo)? Will look at tomorrow to submit, in the middle of changing devel boxes.
Better yet ...
and ...
Perhaps with a check to validate the option.