Is there a way so that whatever menu option the user chooses, this is set to the default option next boot with say a 5 second timeout?
Could we be really clever and say if there was no previous choice, or a particular menu option was chosen that no default is set, or at least no timeout?
Set default menu selection to whatever booted last time?
#1
Posted 17 August 2018 - 11:32 PM
#2
Posted 18 August 2018 - 09:18 AM
Not only there is, but it is also - strangely enough - documented AND with examples provided.
READ the README_GRUB4DOS.txt, look for a section:
****************************************************************************** *** New Syntax for the DEFAULT/SAVEDEFAULT Commands *** ******************************************************************************
Wonko
#3
Posted 18 August 2018 - 11:05 AM
Cheers, I should have looked there first
I can see how that would work, but how would I remove a default? Say I have 5 OS menu options and a recovery option, if choose an OS option to boot I want it to savedefault for next time, but if I choose recovery I want to clear the default so that you just get the menu next boot with no timeout.
#4
Posted 18 August 2018 - 01:17 PM
The savedefault directive is operated on a single menu.lst entry basis.
You want something *like*:
0 - OS1 with savedefault [0]
1 - OS2 with savedefault [1]
2 - OS3 with savedefault [2]
3 - OS4 with savedefault [3]
4 - OS5 with savedefault [4]
5 - Recover with a procedure to clear the default file? (but that would default to the 0 entry)
Simpler (to me) would be to add a (hidden[1]) entry that doesn't boot and just waits.
Look into the README_GRUB4DOS.txt for: "An unbootable title"
Something *like*:
title First boot after recovery
pause --wait=0 It seems like you just booted from Recovery
pause Press any key to return to menu and choose one of the Operating Systems entries
Would do nicely.
Wonko
[1] actually a conditional one, look into the README_GRUB4DOS.txt for:
******************************************************************************** Conditional Menu(iftitle) ********************************************************************************
#5
Posted 18 August 2018 - 08:46 PM
Are you talking about a default AND a timeout?
The default is the menu item that is highlighted when the menu is loaded - it will always be ONE of the menu items.
The timeout can be set to -1 (off) or a number.
http://dl.grub4dos.c...a-2018-07-01.7z
Special file default attached and in \sample folder of 0.4.6a download above.
default /default timeout 55 # if menu item 4 then no timeout cat --locate=4\x00 --length=2 /default > nul && timeout -1 && default 0 title test 0 savedefault chainloader /grldr title test 1 savedefault chainloader /grldr title test 2 savedefault chainloader /grldr title test 3 savedefault chainloader /grldr title reload savedefault chainloader /grldr
Attached Files
Edited by steve6375, 18 August 2018 - 11:53 PM.
#6
Posted 19 August 2018 - 05:59 AM
The default is the menu item that is highlighted when the menu is loaded - it will always be ONE of the menu items.
Yep , but once the hidden/conditional menu has been loaded, the timeout will have effectively be already "consumed" so the default will be selected but not automatically executed anymore.
Your solution is nice but it is "transparent" to the user, using iftitle the user would be "notified" explicitly that the particular boot is a "special case".
I.e. something like (provided it works ):
...
title recovery
savedefault +1
chainloader /grldr
iftitle [cat --locate=5\x00 --length=2 /default] First boot after recovery
pause --wait=0 It seems like you just booted from Recovery
pause Press any key to return to menu and choose one of the Operating Systems entries
Isn't there a way to check the current default without resolving to use cat --hex?
Wonko
#7
Posted 19 August 2018 - 08:04 AM
Byte at 0x8276 should contain the current menu item that is selected, but it does not seem to be updated - it always reads as 0.
According to the source files, I think it should be updated (at least by the 'default' command). I have reported it as an issue in case it is a bug, I tried one of the latest versions of 0.4.5c as well as the latest 0.4.6a and 0x8276 reads 0 with both of those.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users