#703 Issue `closed`: Boot From GRUB asked for Username and Password¶

Labels: bug, documentation, cleanup, support / question, fixed / solved / done

firsttris opened issue at 2015-11-18 19:44:¶

Hello,

my first rear restore... i boot relax-and-recover from GRUB and it asks for a Username and Password...

wonderful.... i never set one... never read about this in the docs

Which credentials are they asking for?

i have tried rearadmin/REAR;REAR/REAR; root/REAR; admin/REAR; root/recovery; root/

no option is correct...

regards

gozora commented at 2015-11-18 20:25:¶

hi, if it is grub that asks you for password, default one is "SECRET" http://relax-and-recover.org/usage/

firsttris commented at 2015-11-18 20:33:¶

The entry in the bootloader is password protected. The default password is REAR. Change it in your own local.conf

default user/password seems to be rearadmin/REAR but its not working...

i already tried to change them in local.conf..

...without success can not pass the passwort protection in GRUB...

my config:
BACKUP=NETFS
USB_DEVICE=/dev/disk/by-label/REAR-000
OUTPUT=USB
GRUB_RESCUE=y
GRUB_RESCUE_PASSWORD="REAR"
GRUB_SUPERUSER="root"

gozora commented at 2015-11-18 22:05:¶

ok, it took me a while to figure it out.
Problem is that GRUB_RESCUE_PASSWORD needs to be set hashed. (as password_pbkdf2 option is in use)
Means that you should use should create hash from password:

grub-mkpasswd-pbkdf2¶

Enter password:
Reenter password:
Your PBKDF2 is grub.pbkdf2.sha512.10000.F876269F3E0A87C3F8820643C210C4A090CA1E57E013A089EF69101B211940B3EBDA67B3850BA74C95A05FD44C3C5D19F0614AAF64659D4609B8E7F2D755D32C.1B8F56B392C7381CED82B46AB79E5F6A2F6F86ADD7B3D9B6034522DDF8B46913F70C45AA64ED3AE66F54760673D1CF36049660265ACC220F2B5C48487784ED5A

And use this output as feed for GRUB_RESCUE_PASSWORD, so the final output would look something like this:

GRUB_RESCUE=y
GRUB_RESCUE_PASSWORD="grub.pbkdf2.sha512.10000.26A20D64CFF7668AC6D6A8E98F2EB960E1F7CBE4E7E128C1A2C77801860FB1377020CD3109FBE3CC841FAC8BB7D09B5B51FDE9DDD39507DE741716E97D77C6FC.352F331A65F1665315F8639A94E994248A3EA5D618671DBD6C44787C6217249675F5E6AB3A80F95914A1AF046645C6E5811D73EC5D34D3D2FAFFEA55B9E40DD4"
GRUB_SUPERUSER="root"`

Hope it helps ...

gozora commented at 2015-11-18 22:08:¶

Just realized that hashes in my comment differ (dam you salt!), but the principle stays the same ...

firsttris commented at 2015-11-19 05:39:¶

thx very much gozora 👍 i will try after work

shoodle commented at 2016-03-10 12:28:¶

Hi,
i am opening this issue again, because i think it is not solved.

Today i wrote a config file like this /etc/rear/site.conf:

OUTPUT=USB
BACKUP_PROG=rsync
BACKUP_PROG_EXCLUDE=( '/dev/' '/proc/' '/sys/' '/tmp/' '/run/' '/mnt/' '/media/*' '/lost+found' )
BACKUP=NETFS
BACKUP_PROG_INCLUDE=( '/' )
MANUAL_INCLUDE=YES
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
GRUB_RESCUE=1

When the backup finished i found a modified /boot/grub/grub.cfg and a new entry /etc/grub.d/01_users.

When i booted my computer ALL menu entries in the grub menu were protected with "username" and "password". When i tried to access an entry with username "rearadmin" and password "REAR" i get the message

Failed to boot both default and fallback entries.

Therefore i cannot acces any of the different os entries in my system!

Booting with a rescue CD and removing /etc/grub.d/01_users and restoring the backup copy /boot/grub/grub.cfg.old to grub.cfg didn't help. (Because of a different os on the CD i couldn't chroot and run grub-config).

When i read https://help.ubuntu.com/community/Grub2/Passwords i get the impression that something is wrong with the line

password_pbkdf2 rearadmin REAR

in /etc/grub.d/01_users (it should be an encrypted passwod).

What can I do to get access to my computer again??

jsmeix commented at 2016-07-25 11:37:¶

FYI, regarding "all menu entries in the grub menu were protected with username and password":

I also noticed it while I made https://github.com/rear/rear/pull/942

jsmeix commented at 2016-07-25 11:41:¶

@firsttris
can you tell us why you need that GRUB_RESCUE functionality?

In short:
Currently we are thinking about if we perhaps better
drop that scaring GRUB_RESCUE functionality,
cf.https://github.com/rear/rear/issues/938
and https://github.com/rear/rear/issues/935
and https://github.com/rear/rear/issues/913

jsmeix commented at 2016-07-25 11:43:¶

@gozora
did you ever successfully use the GRUB_RESCUE functionality
on a system with GRUB 2?

I ask because for me it did not at all work on SLE12.

I needed https://github.com/rear/rear/pull/942
to make it somewhat working on SLE12,
see also https://github.com/rear/rear/issues/938#issuecomment-234929757

firsttris commented at 2016-07-25 11:52:¶

i just wanted to recover from usb:
http://relax-and-recover.org/usage/#recovery_from_usb
actually i thought this would be the default way....
my disk is gone i boot from usb to restore my main disk..
regards
firsttris

gozora commented at 2016-07-25 12:09:¶

@jsmeix well, some time has passed, so I don't really remember, but I guess that it worked fine for me...
I can do tests again if you want...
@shoodle can you share information like, what OS and ReaR version are you using? Is the only problem here that you can't boot rescue image because it is protected by password?

jsmeix commented at 2016-07-25 12:11:¶

As far as I understand
http://relax-and-recover.org/usage/#recovery_from_usb
therein the items

Recovery from USB
Rescue system
Storing on a central NFS server
...

are all separated "Usage scenarios".

In particular as far as I understand it
for "Recovery from USB" you do not need
that locally installed "Rescue system" via GRUB_RESCUE.

gozora commented at 2016-07-25 17:29:¶

Quite strange, when I setup similar config:

BACKUP=NETFS
OUTPUT=USB
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
USB_DEVICE=/dev/disk/by-label/REAR-000
EXCLUDE_MD=( $(grep -o -E '^md[0-9]+' /proc/mdstat) ) # exclude all md devices
GRUB_RESCUE=1
COPY_AS_IS=( ${COPY_AS_IS[@]} /sbin/sysctl /etc/sysctl.conf /sbin/vconfig /sbin/if* /etc/sysconfig/network /sbin/shutdown.wrap )

I was stopped by following piece of code, telling me:

Message: GRUB_RESCUE_PASSWORD needs to be set. Run grub2-mkpasswd-pbkdf2 to generate pbkdf2 hash

Here I start to have problems with logic. because couple of lines above this code I read condition like this:

if is_true $USING_UEFI_BOOTLOADER ; then ...

What is the purpose to check if GRUB_RESCUE_PASSWORD is set ONLY when using UEFI? Or do I read it wrong?

BTW when I set GRUB_RESCUE=1 and used GRUB_RESCUE_PASSWORD hence allow ReaR to modify my grub.cfg, only grub entry protected with password was that created by rear.

Unfortunately (most probably) systemd started to play tricks on me and for some reason avoided me to create another backup :-/ (most probably some race condition when discovering USB devices), so I have to solve this first before I continue to investigate this further...

This looks to be bigger than I've expected so I need to get a beer or two and think about it a bit.
I'll report back with findings soon.

P.S. all tests have been done on CentOS Linux release 7.2.1511 (Core) with UEFI enabled

gozora commented at 2016-07-25 19:50:¶

What is the purpose to check if GRUB_RESCUE_PASSWORD is set ONLY when using UEFI? Or do I read it wrong?

Yes, Vladimir you read it wrong! The condition was closed couple of lines before ;-), You should read code more carefully next time ...

jsmeix commented at 2016-07-26 10:13:¶

@gozora
The "GRUB_RESCUE_PASSWORD needs to be set ..." message
is from older code where I also had issues with,
cf. https://github.com/rear/rear/issues/938#issuecomment-234899163

My current code for 94_grub2_rescue.sh
in https://github.com/rear/rear/pull/942
works much better for me (on SLES12-SP1).

Now it supports to set GRUB2 password only optionally
and additionally one can (also optionally) use an existing
GRUB2 user via GRUB_RESCUE_USER without the need
to let rear create a GRUB2 superuser.

I would very much appreciate if if you test it with my
current code in https://github.com/rear/rear/pull/942

gozora commented at 2016-07-26 12:16:¶

@jsmeix sure will do ...
I guess #942 is not yet merged with ReaR, so I have to use sources from your repo, right?

jsmeix commented at 2016-07-26 13:16:¶

In general regarding how to test
some newest rear GitHub code in whatever other git branch
that is not yet merged with rear upstream master code,
see https://github.com/rear/rear/issues/895#issuecomment-229655856

gozora commented at 2016-07-26 13:24:¶

@jsmeix thanks, will do ...
Did you test this code with EFI enabled or legacy boot?

jsmeix commented at 2016-07-26 13:28:¶

@gozora
What a question ;-)
Do you think I like to notice more problems than I already see?
Does this answer your question?
.
.
.
If not:
.
.
.
I tested only with legacy BIOS boot.

gozora commented at 2016-07-26 13:29:¶

:D

gozora commented at 2016-07-26 21:02:¶

I've made my life easier and switched (after long time) to legacy boot as well. I've done testing on CentOS Linux release 7.2.1511 (Core).
First and only problem I've encounter was that grub2 menuentry "Relax-and-Recover" did not boot because wrong path to initrd and kernel.

ReaR created:

search --no-floppy --fs-uuid  --set=root c3e2e7b1-2849-4797-a4ee-b2923c157e7c
linux  /boot/rear-kernel  selinux=0
initrd /boot/rear-initrd.cgz

but only following worked:

search --no-floppy --fs-uuid  --set=root c3e2e7b1-2849-4797-a4ee-b2923c157e7c
linux  /rear-kernel  selinux=0
initrd /rear-initrd.cgz

I was thinking how to determine correct boot entries/paths for all possible distros and come to conclusion that maybe we could copy it from existing grug.cfg. Something like

grep -E initrd|kernel /boot/grub2/grub.cfg | sed awk parse hell whatever we need to know ...

What do you think?

To my opinion more severe thing is that once user sets GRUB_RESCUE_PASSWORD and GRUB_SUPERUSER it will never change in actual grub.cfg configuration until /etc/grub.d/01_users exists. (hope I've understood code right this time ;-) ).
This can be quite confusing.

Didn't you think about removing condition (on line 106 of 94_grub2_rescue.sh)
if [[ ! -f $grub_users_file ]] ; then
so that grub use and password is changed every time?

jsmeix commented at 2016-07-27 07:20:¶

Seems to be again a nice mess how GRUB 2 works
on different Linux distributions.

On my SLES12-SP1 "linux /rear-kernel" and "initrd /rear-initrd.cgz"
just failed to boot so that I changed it to the absolute path
where the files actually are in the system, cf.
https://github.com/rear/rear/pull/942#issuecomment-234944705
and
https://github.com/rear/rear/issues/938#issuecomment-234929757

In contrast this does not work on CentOS.

Currently I don't know how to fix such Linux distribution mess
so that it works in a generic way on all Linux distributions.

Regarding the GRUB 2 password protection,
see my comments in default.conf and
https://github.com/rear/rear/pull/942#issuecomment-235262557

My general problem with the GRUB 2 password protection stuff
is that I do not want that rear behaves as if it was the ultimate
master of the whole GRUB 2 configuration.

The whole GRUB 2 password protection setup in rear is
already scaring enough because it can change how other
GRUB 2 boot entries behave (at least on SLE12)
because it does general changes of the whole GRUB 2
configuration - in particular with GRUB_SUPERUSER
rear creates a new GRUB 2 superuser which is a general
change of the whole GRUB 2 configuration.

The more I think about the GRUB 2 password protection setup
in rear the less I like it at all.

Perhaps I should completely remove that scaring part of the
GRUB_RESCUE setup.
This would keep things simple and straightforward (KISS)
because such a simplified GRUB_RESCUE setup
would only add the one more GRUB 2 menue entry and
leaves the rest of the GRUB 2 configuration unchanged.

If a user wants GRUB 2 password protection
he can do that on his own as he likes and needs it.
I think there is no real need that rear does that.
I think GRUB 2 password protection setup in the
currently running system is really not at all an
expected native functionality of rear.

jsmeix commented at 2016-07-27 07:32:¶

@gozora
many thanks for your testing!
Your always valuable contributions to rear help a lot
and are very much appreciated!

gozora commented at 2016-07-27 08:04:¶

@jsmeix

Pleasure ;-)

Currently I don't know how to fix such Linux distribution mess
so that it works in a generic way on all Linux distributions.

I was thinking of a function that would discover correct values from current boot loader setting, as that looks to be most precise way how to get correct boot data.
I'll start to work on it hopefully today.

If a user wants GRUB 2 password protection
he can do that on his own as he likes and needs it.
I think there is no real need that rear does that.
I think GRUB 2 password protection setup in the
currently running system is really not at all an
expected native functionality of rear.

I share your opinion here. however this could be applied to ReaR grub entry it self. "if a user wants GRUB 2 ReaR entry, he can do that on his own as he likes and needs it" ;-)
But I agree that GRUB_RESCUE option might be convenient in some cases.

jsmeix commented at 2016-07-27 08:29:¶

I think what actually causes pain with the current
GRUB 2 password protection setup in rear
is the GRUB_SUPERUSER setup because that
changes how GRUB 2 as a whole behaves.

I think what is o.k. is my new GRUB_RESCUE_USER
setup because that (plus a GRUB_RESCUE_PASSWORD) only
adds a password_pbkdf2 line to the 'Relax-and-Recover' entry
but it does not change the general GRUB 2 configuration
(in particular it does not change what GRUB 2 users
or superuser exists).

I think I will remove GRUB_SUPERUSER setup
from rear and keep GRUB_RESCUE_USER plus
GRUB_RESCUE_PASSWORD setup support in rear
so that the user can have GRUB 2 password protection
for the 'Relax-and-Recover' entry provided he already
has a GRUB 2 user or superuser.

jsmeix commented at 2016-07-27 09:13:¶

@gozora
regarding correct values for boot loader setting,
see what @gdha asked in
https://github.com/rear/rear/pull/942#discussion-diff-72051269

are you sure /boot is required?
Does the --set=root not fulfil this?
Just want to double check (I could be wrong).

I am not a sufficient GRUB 2 setup expert to know
what the best way is so that it works generically
on all Linux distributions.

I guess the less special GRUB 2 automatisms are used
the more reliable it could (hopefully) work everywhere?

gozora commented at 2016-07-27 10:22:¶

@jsmeix I'm not grub expert neither, but I think that this is the only prerequisite you need to become one :-).
Like I said, I'll try to put something together and then we can discuss whether is can be useful for the future or not.

jsmeix commented at 2016-07-27 13:19:¶

Guess what - I use fixing the GRUB_RESCUE stuff
as an opportunity to learn a bit how to deal
with GRUB 2 issues in rear ;-)

jsmeix commented at 2016-07-28 13:02:¶

With the now merged https://github.com/rear/rear/pull/942
I consider this issue here as sufficiently solved.

Note that with https://github.com/rear/rear/pull/942
the whole GRUB_RESCUE feature for GRUB2
was completely overhauled.

I made GRUB_RESCUE work for GRUB2
on SUSE and Red Hat based Linux distributions.

The former GRUB2 superuser setup support in rear
via GRUB_SUPERUSER is dropped and also
the former GRUB2 password setup support
in rear via GRUB_RESCUE_PASSWORD is dropped.
Both kind of setup can change the behaviour
of the GRUB2 bootloader as a whole in unexpected
ways but rear is not meant to change the general
GRUB2 configuration of the currently running system.
It should work by default reasonably backward compatible
when formerly a GRUB_SUPERUSER was used.

Now the optional GRUB2 password protection
only works via the new GRUB_RESCUE_USER setting.
It must specify an already configured GRUB2 user
except the special value 'unrestricted' is set
via GRUB_RESCUE_USER="unrestricted"
which creates the 'Relax-and-Recover' GRUB2
menue entry so that it can be booted by anyone.

For more details see the description in default.conf

jsmeix commented at 2016-07-28 13:15:¶

@gozora
regarding
https://github.com/rear/rear/issues/703#issuecomment-235515034
"discover correct values from current boot loader setting":

At least for now this is not needed because in
output/default/94_grub2_rescue.sh
I use now different values for 'linux' and 'initrd'
depending on the Linux distribution.

This is of course not the preferred generic solution
but probably it is "good enough for now".

gdha commented at 2017-01-19 08:50:¶

@jsmeix The above was not yet added to any kind of documentation except for the default.conf file, right?

jsmeix commented at 2017-01-19 09:27:¶

@gdha
I assume with "The above" you mean
https://github.com/rear/rear/issues/703#issuecomment-235887700

Don't worry about documentation regarding "GRUB_RESCUE" ;-)
It never was documented except in default.conf.
Accordingly I documented my changes only in default.conf.

And for GRUB2 my code informs the user about the changes,
see output/default/940_grub2_rescue.sh

    # Report no longer supported GRUB 2 superuser setup if GRUB_SUPERUSER is non-empty
    # (be prepared for 'set -u' by specifying an empty fallback value if GRUB_SUPERUSER is not set):
    test ${GRUB_SUPERUSER:-} && LogPrint "Skipping GRUB 2 superuser setup: GRUB_SUPERUSER is no longer supported (see default.conf)."
    # Report no longer supported GRUB 2 password setup if GRUB_RESCUE_PASSWORD is non-empty
    # (be prepared for 'set -u' by specifying an empty fallback value if GRUB_RESCUE_PASSWORD is not set):
    test ${GRUB_RESCUE_PASSWORD:-} && LogPrint "Skipping GRUB 2 password setup: GRUB_RESCUE_PASSWORD is no longer supported (see default.conf)."

I did not change anything regarding "GRUB_RESCUE"
for GRUB Legacy because I never tested it with GRUB Legacy.

[Export of Github issue for rear/rear.]

#703 Issue closed: Boot From GRUB asked for Username and Password¶