Comment 2 for bug 384148

> 1. First of all there should be a note that "password --md5 pass" string has not to be located under the title item but in a global area.

Clarification on global section could help avoid confusion, apparently. Although the menu.lst file already has the template for passwords and text regarding it's use. I guess that would require the reader of the documentation to also read the menu.lst file they are editing.

> 2. The string "# lockalternative=false" confused me, it is necessary to note that string has not to be copied without hash char. It has to be edited as "# lockalternative=true" because it as a template for grub-update scripts.

Further clarifying to the audience that the hash tag should NOT be removed might help. Many other app configuration files require the removal of hash tags (comments) while this serves as a grub string template. The instructions do explain the result should look like the example given, which includes a hash tag exactly as it should.

Here's an excerpt from the automagic section of menu.lst:

### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default options below

## DO NOT UNCOMMENT THEM, Just edit them to your needs

> 3. !!!This is a major bug!!! After editing lockalternative to true it is necessary to put "lock" parameter under the title with recover mode as follows:
(snipped)
> 4. !!!It is necessary to note, that lock parameter which has been added in the item 3 will not be modified by grub-update script(in case of kernel upgrade and other changes) because of "# lockalternative=true". Without "# lockalternative=true" single user mode will be unlocked on next grub-update.

> BTW, do we need to add lock parameter each time to the new title with a new kernel?

As for 3 and 4... The instructions are correct, however there is something missing. After making the change to the "# lockalternative" template, it is necessary to update grub for all existing and future recovery kernel entries to be locked.

sudo update-grub

As long as the lockalternative template and password have been implemented properly, every time a kernel update occurs, grub is updated and all alternative entries will be locked. When kernel updates occur, grub is updated and new kernel entries will automagically receive the lock parameter.

As Connor mentioned, as for new documentation (for version 9.10 and above), Grub 2 has since replaced Grub legacy. As of now, the process of applying passwords is now much more complicated, and does not permit any hashing of passwords. The suggestion of using grub password has always been lightweight security, because as it points out, someone could just boot the system using a LiveCD and gain access. If the passwords are in clear text... what's the point? So users should not use their favorite passphrase there, for sure. :-)

Until the ability to hash the passwords becomes available to Grub 2, I think removing the subsection altogether is probably a good idea.