Le 19/05/2015 18:47, Andrei Borzenkov a écrit : > Ð’ Tue, 19 May 2015 16:14:09 +0200 > "Arbiel (gmx)" <[email protected]> пишет: > >> >> Le 19/05/2015 05:39, Andrei Borzenkov a écrit : >> >> Let me explain what I want to do. >> Running a GNU/Linux system, I want the user to set a grub environment >> variable into >> the grubenv environment block to instruct grub to perform a specific >> task at next boot, >> but only once, at that specific next boot. >> When grub performs that specific task, it resets the environment >> variable with a "save_env" statement. >> Unfortunetaly, grub cannot write into a LVM partition neither in some >> specific file systems >> (btrfs, cpiofs, newc, odc, romfs, …). >> So, if the save_env statement returns an error condition, I want grub to >> 1)instruct the user either to press "Ctrl" key to perform the task or >> "Alt" to forget about it and boot normally and >> 2) wait until the user has got time to read and understand the >> instructions and pressed the desired key. >> >>> Ã’ Mon, 18 May 2015 22:24:00 +0200 >>> "Arbiel (gmx)" <[email protected]> ÿøшõт: >>> >>>> Hi >>>> >>>> I wish to have grub wait until the user has taken a specific action and >>>> presses down a key, such as control, shift or alt keys to inform the >>>> action has been taken. It's possible to test this with the keystatus >>>> --<key> function. >>>> >>>> With the following lines >>>> >>>> echo "Press Ctrl key down to go on." ; >>>> until keystatus --ctrl ; do true ; done ; >>>> echo "Ctrl key pressed down." ; >>>> >>>> grub seems to enter and endless loop. However, if the Ctrl key is >>>> pressed before the "Press Ctrl key down to go on." message is displayed, >>>> grub immediately exits the loop. >>>> >>> keystatus checks whether key state is "pressed". It has no way to know >>> since when key is pressed. It does not check for transition, it checks >>> for state. What behavior you expect when key is pressed before loop >>> starts? >> I do not expect anything else than what you explain : keystatus checking >> the state >> of the key in real time and returning it into a boolean value, true if >> the key is down at the time of >> the statement being executed, false if it is up. >> It turns out that, if I press the key after the first message and so >> after the first keystatus statement, >> grub seems to loop endlessly, as if never finding the key to be down, >> even if it really is down. > Ah, sorry, I misunderstood. Yes, I see this behavior. The problem is, > on PC BIOS getkeystatus simply checks flags in BIOS Data Area and in > your first loop BIOS never gets chance to run and update these flags. > While in your second loop sleep actually polls for input characters and > so allows BIOS to set flags. > > I see two possible solutions. > > Brute force and easy one - add --milliseconds switch to sleep command > to minimize delay. Internally sleep is using milliseconds anyway. Care > to send patch to grub-devel? This solution will do it. However I don't know how to add the milliseconds switch to the sleep command. The only information I found concerning this command http://members.iinet.net/~herman546/p20/GRUB2%20CLI%20Mode%20Commands.html#cli_sleep only mentions waiting time in seconds. > > Long term getkeystatus on PC BIOS should probably actually poll > keyboard. Unfortunately it is less trivial. Do you have experience with > low level PC programming? I have no experience in low level PC programming. > > ... >> If the plateform is not able to check the status of the keys, what do >> you suggest me >> to do ? >> >> > It probably depends on how often you are expecting to see such > configuration. It does not really depend on platform - serial console > on any system has no way to do it, so you can in principle see it > anywhere. > > It is not really specific to GRUB in any way. How would you implement > it when logged into remote system over telnet/ssh? The option I am currently implementing is supposed to run locally only. As for serial console, I will document the incompatibility.
Thank's you for the help. >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
