Installed M6sta2 in Live mode from all 4 DVD's (2 from optical disk, 2 from usb) and with 2 or 3 I tried recording a password in the bootloader-grub2 entry fields that apply. (Screenshot to eb added)
However when next rebooting the live user is the only one known and the password is not accepted for the second bootmenu choice "Advanced options for Mageia", while the first entry ("Mageia") boots immediately without asking a password.
Frankfly I did not try entering a password in classical install yet, maybe it works there.
If this only fails in all Lives it should be fixed or written to errata. Will try classical after next build now nearly ready.
Created attachment 8770 [details]
stdout from "journalctl -ab" command at the end of Live install
Created attachment 8771 [details]
journal from installed m6sta2
This was obtained from current cauldron after first reboot in M6sta2 and subsequent boot to current cauldron, mounting /mnt/beta and cd to /mnt/beta/var/log/journal/blabla/ and giving command: journalctl -a -D .
Created attachment 8772 [details]
recording password during live install
Created attachment 8773 [details]
Boot entries available in first reboot
Created attachment 8774 [details]
trying "Advanced options for Mageia" with user Live and previously chosen password
Created attachment 8775 [details]
boot choice "Mageia" boots without password
The rpm's chosen are those listed for this iso (plasma 32 bits dated 10.DEC.2016)
I have saved /boot/grub and /etc/grub.d which can be attached upon request or given a URL for /boot (too large to attach)
Running drakboot in an installed cauldron and adding a password with it, doesn't result in needing to type a password when booting the same cauldron, either.
I didn't see anything related to a password in the diff of grub.cfg and grub.cfg.old, nor in the diff of grub.env and grub.env.old, but forgot to check the time stamp of the .old files when I did that :-(
/boot/grub2/user.cfg was correctly created
-rw------- 1 root root 297 dec 14 20:47 user.cfg
Making the file world readable didn't help :-Ã¾
(and then running update-grub2 and grub2-install again, didn't help either)
if you still have /boot/grub2/*.old files from before adding the password, can you then please diff them with the new files?
I don't know when this feature stopped working, I never tried to use it before, because I can set my BIOS to request a password to boot anything.
@(In reply to Marja van Waes from comment #9)
I cannot have an *.old file because Live provides only new installs and with latest classical isos I hadn't noticed that bug #15930 had been fixed. Will try this with next classical isos (currently building I heard), unless someone beats me to it.
(Your reason for not trying is less good if someone can take out the BIOS battery: that will probably revert the BIOS to original password-free settings).
Another user reported to have the non working password in grub:
It seems we misunderstood what the password is for /o\
We should have better read the second comment in bug 15930
> commit 9bb701c386fcb05068c4c02b372e0c0b754995b3
> Author: Thierry Vignaud <thierry.vignaud@...>
> Date: Tue Jun 21 17:21:13 2016 +0200
> grub2: enable to protect with a password
> thus restricting altering the config on boot (mga#15930)
It doesn't prevent starting a boot entry, it only prevents *editing* a boot entry. That is indeed impossible without giving the username root (I only tried root, because root is the only one who can read user.cfg) + the created password, and that works fine.
It looks like we have something to add to our documentation!
Reassigning to documentation team.
Btw, it should be possible to manually restrict who can start a boot entry, see:
(In reply to Dick Gevers from comment #10)
> (Your reason for not trying is less good if someone can take out the BIOS
> battery: that will probably revert the BIOS to original password-free
Didn't happen on my oldest ThinkPad, where I replaced the BIOS battery half a year after it died. The password was needed all the time, even to start a Live iso. I'll keep in mind that that isn't a guarantee for later ThinkPads, though ;-).
(In reply to Marja van Waes from comment #12)
> It seems we misunderstood what the password is for /o\
I do not quite agree: see below.
> We should have better read the second comment in bug 15930
> > grub2: enable to protect with a password
> > thus restricting altering the config on boot (mga#15930)
I get the meaning, so indeed 15930 is fixed. But the "drakboot --boot" has always (and this should not change) password protected the bootloader, be it lilo, grub legacy and should with grub2.
And it is possible, witness 1 exampel: https://help.ubuntu.com/community/Grub2/Passwords
> It looks like we have something to add to our documentation!
No not for me.
> Btw, it should be possible to manually restrict who can start a boot entry,
So it is not an enhancement but just getting back to what drakboot has usually been able to do (I think I remember requesting Pixel for a fix when we came from lilo to grub legacy in mdk/mdv and it fell out ;)
In fact IMHO it is a security issue and triage should judge it more important :P
(In reply to Dick Gevers from comment #14)
> So it is not an enhancement but just getting back to what drakboot has
> usually been able to do (I think I remember requesting Pixel for a fix when
> we came from lilo to grub legacy in mdk/mdv and it fell out ;)
> In fact IMHO it is a security issue and triage should judge it more
> important :P
Btw, the "Source RPM:" field is about the SRPM. It does not mean "the rpm that's the source of the problem", so not the RPM name is needed, but the SRPM it originates from ;-)
Forgot to tell: When trying to login to Windows, Grub2 did ask for a username (= root) and password here.
Marja, I am sure you are right, but I haven't used Windows since 14 years myself ;)
Applies to 6RC Live isos of 03 April 2017
As Martin suggested on the QA ML I mark this as release blocker. Feel free to disagree: that is my opinion.