Setting up a new configuration for our students’ lab with SLED12 SP1 I
am running in trouble with grub2: following chapter 12.2.6 of the
Administration guide I set up a user and encrypted password in
/etc/grub.d/40_custom. What the manual obviously is missing is that one
has to redefine the variables GRUB_CMDLINE_LINUX_DEFAULT and
GRUB_CMDLINE_LINUX_RECOVERY in /etc/default/grub with the option
“user=root” (or whatever the name of the grub superuser is) in order to
enforce the protection for the Linux entries in the grub.cfg.
Now with these settings for grub2 the system will ask for user and
password at every boot. With grub like in SLED11 I could set up a pass
phrase in the header section of the menu.lst like “password --md5
$1$s…”. This just protects the menu.lst and the grub shell from the
non-authorized user but still allows for automatic boot (WOL) or booting
by users who do not have the pass phrase.
Now with grub2 I am under the impression that I am stuck with just these
two options:
leave grub2 and thus the OS and hardware completely unprotected from
unwanted user interaction. This is not an option as students will
immediately start to mess up the installations.
Defining a user as above and not being able to boot the systems any
more. No WOL in the morning and the students will be asked for an
unknown password when they try to boot.
Is grub2 really that much messed up? Will I have support for a backport
of legacy grub (I did not find in the the repository)? Is there any way
to set up a protected boot loader for SLED12 that allows for automatic
booting the systems remotely and on place?
It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.
These forums are peer-to-peer, best effort, volunteer run and that if your issue
is urgent or not getting a response, you might try one of the following options:
Visit http://www.suse.com/support and search the knowledgebase and/or check all
the other support options available.
If this is a reply to a duplicate posting or otherwise posted in error, please
ignore and accept our apologies and rest assured we will issue a stern reprimand
to our posting bot…
You are not alone with this grub2 password issue@SLED12.
Forget chapter 12.2.6 of the Administration guide. Set the bootloader password with:
yast2 bootloader
You should set the brand new option “protect menu entry settings” (or similar) on tab “bootloader options”. This option doesn’t exist on SLED12. This option is new with SLED12 SP1. See chapter 3.1.4.2 of SLED12 SP1 release notes:
Thank you very much for the hint. Yet another case of RTFM…
Actually I have now a working configuration and I was wondering why it worked out of the blue. Must have been the upgrade to SP1. On my current test system I can’t try the YaST option as got rid of almost any entries in /etc/grub.d (too complicated, and I do not need the flexibility to boot multiple kernels or OS variants) and put everything in the custom file. So withe SLED12 SP1 this will let the user boot the system but prevents him or her hopefully from messing around with grub:
[FONT=Courier New]# 40_custom
#!/bin/sh
exec tail -n +3 $0
This file provides an easy way to add custom menu entries. Simply type the
menu entries you want to add after this comment. Be careful not to change
the ‘exec tail’ line above.
set superusers=“root”
password_pbkdf2 root grub.pbkdf2.sha512.10000.F4826CD5…
menuentry ‘Pool’ --class sled --class gnu-linux --class gnu --class os --unrestricted {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root=‘hd0,msdos1’
echo ‘Pool-Image wird geladen  ’
linux /vmlinuz root=/dev/mapper/vg0-root splash=none quiet showopts
echo ‘Initiale Ramdisk wird geladen  ’
initrd /initrd
}[/FONT]
Obviously the “set root” and “root=” entries will have to be adjusted. But these will never change for me.
Do you know what the magic is behind the YaST box “Protect Entry Modification Only”? I suppose it sets the option “–unrestricted” for the menu entry?
I don’t know what the magic is behind the YAST box “Protect Entry Modification Only”.
I paid money for a SLED subscription with standard support. If i have any technical issue, i will ask the SUSE support/hotline for a solution. I had the same grub2@SLED12 issue. I opened a “Service Request” and the SUSE support/hotline solved this issue in SLED12SP1.