I’m on 11.4 32-bit and have a nasty problem with running a few lines of code in halt.local, actually it’s just one command that fails, a read from the keyboard. This is a hybridgraphics system, so I thought it would be a good idea to put the graphics switching code in halt.local. It does work when I’m in Intel mode, but in nVidia mode it just locks up when I enter the menu selection, really strange, anyone got an idea where to look? I should also add that the script runs fine from the command line regardless what graphics mode I’m in.
When you want advice on a piece of script you wrote, it seems logical to me that you post it. All our crystal balls are still on holiday.
You got a point there, I was so focused on the different behavior between running it in Intel mode and nVidia mode. Anyway I’ve tested it on my desktop too, nVidia card and proprietary driver, same result as on the netbook, displays my menu on reboot, I select a menu option hits enter and it locks the machine, but runs fine from command line. I’ve stripped it down, just to reduce any other errors, also it wouldn’t be nice to run it on anything but a hybrid system.
#!/bin/sh while : do clear echo "-------------------------------------" echo " Select graphics mode " echo "-------------------------------------" echo " Intel mode" echo " nVidia mode" echo " Optimus mode" echo " Exit" echo "=======================" echo "Enter your menu choice [1-4]: " read yourch case $yourch in 1) echo "Intel chip will be activated" ; echo "Press a key. . ." ; read ;; 2) echo "nVidia card will be activated" ; echo "Press a key. . ." ; read ;; 3) echo "Optimus mode selected, both chips will be activated, X will run on Intel chip, consider this as experimental." ; echo "Press a key. . ." ; read ;; 4) exit 0 ;; *) echo "Opps!!! Please select choice 1,2,3 or 4"; echo "Press a key. . ." ; read ;; esac done
So you want to switch graphics mode just before your machine reboots/restarts? I ran your menu and it works fine for me. I take your word that the actual code does not work with certain switchable graphic selections, but if there is a code problem, it is not with your menu that you posted as far as I can tell. If you reduce your code to just what you posed here, place it in the same place, does one of the options (that does nothing) still lock up your computer?
No it doesn’t seem to be a code problem, if I have this code in halt.local the machine locks on the first menu selection, but only when running nVidia graphics, running it with Intel graphics is no problem. The rest of the code is system specifik for an ION hybrid graphics system and is confirmed to work, it’s just that read statement that locks the system. There are other ways to fix this switching logic, but not so elegant, I can run a script in /usr/sbin to make it, it’s just that then the user has to fire up a terminal and su to root, I would like to avoid that if possible. Switching graphics on those ION systems includes two steps, toggling a hardware switch with the help of the acpi_call module and changing some symlinks for libglx and libGL, at least the last step has to be done at shutdown.
So, instead of just saying “read”, why not say “read choice” or “read -n1 choice” at the end of each selection , which are more normal ways to use read?
As we are trying to find a problem here, it might be of interest to point to the fact that this script is interpreted by the POSIX shell and not by the BAshell. Differences between them are minor, but we had allready cases here in the forums where it was the source of a problem. As most people here automaticaly think everybody uses *bash, *I thought it being usefull to mention this.