12:31 p.m.
Hi,
Since systemd requires root password to use emergency shell, shouldn't
there be a generic password set for the livecd? Right now I can't boot
single user mode for example, because a root password is required. If
I just control-D it continues onto graphical boot which isn't what I
want. I have found no work around for this.
Related: user has installed Fedora 21 without setting a root password.
After an update, he's getting dropped to emergency shell. And because
he has no root password set he can't get access to the
rdsosreport.txt.
What's the work around? And if there isn't a good work around then I
think maybe I need to bring it up on devel that setting a root
password is required in the installer (?) because being allowed to
install a system that can't be troubleshot seems like a bad idea.
Suggestions?
--
Chris Murphy
4:16 p.m.
On Thu, 2014-12-18 at 11:31 -0700, Chris Murphy wrote:
Hi,
Since systemd requires root password to use emergency shell,
shouldn't there be a generic password set for the livecd? Right now I
can't boot single user mode for example, because a root password is
required. If I just control-D it continues onto graphical boot which
isn't what I want. I have found no work around for this.
init=/bin/bash
There was a fun bug with that if you had encrypted filesystems in F20,
but I think it's fixed now.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4:30 p.m.
On Thu, Dec 18, 2014 at 3:16 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Thu, 2014-12-18 at 11:31 -0700, Chris Murphy wrote:
> Hi,
>
> Since systemd requires root password to use emergency shell,
> shouldn't there be a generic password set for the livecd? Right now I
> can't boot single user mode for example, because a root password is
> required. If I just control-D it continues onto graphical boot which
> isn't what I want. I have found no work around for this.
init=/bin/bash
There was a fun bug with that if you had encrypted filesystems in F20,
but I think it's fixed now.
WTH, I tried that earlier and got a kernel panic twice in a row, and I
just tried it again and now I'm not.
!
--
Chris Murphy
4:35 p.m.
On Thu, Dec 18, 2014 at 3:30 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Thu, Dec 18, 2014 at 3:16 PM, Adam Williamson
> init=/bin/bash
>
> There was a fun bug with that if you had encrypted filesystems in F20,
> but I think it's fixed now.
WTH, I tried that earlier and got a kernel panic twice in a row, and I
just tried it again and now I'm not.
Ahha! It matters where it goes in the argument line. If I put it in
the middle right after ro (changed to rw) then I get a kp. If I put it
at the end of the line where quiet rhgb are, then I don't get a kp.
However, after changing the root password, the command reboot is not
found. And exit causes a kernel panic!
--
Chris Murphy
5:14 p.m.
On Thu, 18 Dec 2014, Chris Murphy wrote:
However, after changing the root password, the command
reboot is not found. And exit causes a kernel panic!
WHen I hit the 'systemd wants a root password' issue, I loop
mounted the image I wished to boot, and set the root PW in
/etc/shadow to a blanked value (i.e., no passwd) to get around
the issue
-- Russ herrold
11:26 p.m.
On Thu, Dec 18, 2014 at 4:14 PM, R P Herrold <herrold(a)owlriver.com> wrote:
On Thu, 18 Dec 2014, Chris Murphy wrote:
> However, after changing the root password, the command
> reboot is not found. And exit causes a kernel panic!
WHen I hit the 'systemd wants a root password' issue, I loop
mounted the image I wished to boot, and set the root PW in
/etc/shadow to a blanked value (i.e., no passwd) to get around
the issue
I'm not sure what this means.
OS X and Windows have a basic recovery/repair environment that do not
require any sort of login to access, and that includes password
resetting. I'm not really grokking the point of systemd making
single/emergency target locked down like this; physical access is
assumed because in emergency mode there is no network. And physical
access has always meant full access unless the volumes are encrypted.
I'm a bit stumped how this is supposed to work without really esoteric
knowledge.
--
Chris Murphy
3:17 a.m.
On 19 December 2014 at 00:35, Chris Murphy <lists(a)colorremedies.com> wrote:
On Thu, Dec 18, 2014 at 3:30 PM, Chris Murphy
<lists(a)colorremedies.com> wrote:
> On Thu, Dec 18, 2014 at 3:16 PM, Adam Williamson
>> init=/bin/bash
>>
>> There was a fun bug with that if you had encrypted filesystems in F20,
>> but I think it's fixed now.
>
> WTH, I tried that earlier and got a kernel panic twice in a row, and I
> just tried it again and now I'm not.
Ahha! It matters where it goes in the argument line. If I put it in
the middle right after ro (changed to rw) then I get a kp. If I put it
at the end of the line where quiet rhgb are, then I don't get a kp.
However, after changing the root password, the command reboot is not
found. And exit causes a kernel panic!
You'd have to use:
/sbin/reboot -f
Have a look at https://fedoraproject.org/wiki/How_to_reset_a_root_password
(FWIW that bit, among others, was added by the systemd maintainer in Fedora).
--
Ahmad Samir
12:49 p.m.
On Fri, Dec 19, 2014 at 2:17 AM, Ahmad Samir <ahmadsamir3891(a)gmail.com> wrote:
You'd have to use:
/sbin/reboot -f
Right, thanks.
Have a look at
https://fedoraproject.org/wiki/How_to_reset_a_root_password
(FWIW that bit, among others, was added by the systemd maintainer in Fedora).
I referred to that same wiki earlier in this thread. It seemed dated
because it starts out saying that setting a root password is
mandatory, which isn't correct. And a big part of the problem is this
incongruence between systemd requiring a root password but the
installer not requiring a root password. So in the however likely
event the user needs emergency target, or is inadvertently dropped
there, some percent of users are stuck because they don't have a root
password and they're not really informed of this in advance. So it's a
catch-22.
Either systemd needs to back off on the root password requirement,
which seems unlikely, or the installer needs to insist the user set a
root password, which is sorta icky because two passwords to do an
installation? And then the most likely user who will fall into this
trap is the Fedora Workstation user, who also has media that can't
boot in rescue mode (i.e. anaconda rescue mode).
Still, short term I think it's better if the user is required to set a
root password. I think we have more users who end up getting dropped
to emergency shell with a reference to rdsosreport than users exposing
themselves to vulnerability by having a root password set (vs not
set).
--
Chris Murphy
1:56 p.m.
On Fri, Dec 19, 2014 at 10:49 AM, Chris Murphy <lists(a)colorremedies.com> wrote:
And then the most likely user who will fall into this
trap is the Fedora Workstation user, who also has media that can't
boot in rescue mode (i.e. anaconda rescue mode).
Still, short term I think it's better if the user is required to set a
root password. I think we have more users who end up getting dropped
to emergency shell with a reference to rdsosreport than users exposing
themselves to vulnerability by having a root password set (vs not
set).
Where is the documentation for a *Workstation end user* on what to do
if they get unceremoniously dumped into that emergency shell? I'm not
talking geeky command prompt stuff or filing bugzilla reports here,
but explicit steps to get back into a productive use case with no data
loss, assuming your hardware isn't broken or some rogue process hasn't
nuked a filesystem?
11:47 p.m.
On 19 December 2014 at 20:49, Chris Murphy <lists(a)colorremedies.com> wrote:
On Fri, Dec 19, 2014 at 2:17 AM, Ahmad Samir
<ahmadsamir3891(a)gmail.com> wrote:
> You'd have to use:
> /sbin/reboot -f
Right, thanks.
> Have a look at https://fedoraproject.org/wiki/How_to_reset_a_root_password
> (FWIW that bit, among others, was added by the systemd maintainer in Fedora).
I referred to that same wiki earlier in this thread. It seemed dated
because it starts out saying that setting a root password is
mandatory, which isn't correct. And a big part of the problem is this
incongruence between systemd requiring a root password but the
installer not requiring a root password. So in the however likely
event the user needs emergency target, or is inadvertently dropped
there, some percent of users are stuck because they don't have a root
password and they're not really informed of this in advance. So it's a
catch-22.
I've tested the F20 desktop live CD, the installer doesn't let me
continue unless I set a root password.
So the problem here is a corner case where you want to boot the live
CD to the emergency/rescue target where the live system doesn't have a
root password set.
Either systemd needs to back off on the root password requirement,
which seems unlikely,
I agree with what you said in a previous email; the emergency/rescue
target requiring the root password doesn't make much sense to me.
Having physical access to the machine means that the only practical
security against tampering is having your filesystems encrypted. (It's
cheaper to encrypt one's filesystems than buying a titanium vault to
store the box....).
So what's the point of using sulogin if that can be worked around
using 'init=/bin/bash'? (and I don't think a grub password is much
help against someone having physical access to the machine).
Previously the rescue/emergency target used sushell.
or the installer needs to insist the user set a
root password, which is sorta icky because two passwords to do an
installation? And then the most likely user who will fall into this
trap is the Fedora Workstation user, who also has media that can't
boot in rescue mode (i.e. anaconda rescue mode).
Still, short term I think it's better if the user is required to set a
root password. I think we have more users who end up getting dropped
to emergency shell with a reference to rdsosreport than users exposing
themselves to vulnerability by having a root password set (vs not
set).
[...]
--
Ahmad Samir
1:38 a.m.
On Sat, 2014-12-20 at 07:47 +0200, Ahmad Samir wrote:
I've tested the F20 desktop live CD, the installer doesn't
let me
continue unless I set a root password.
It is happy so long as you *either* set a root password *or* create an
admin user account.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8:11 a.m.
On 20 December 2014 at 09:38, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Sat, 2014-12-20 at 07:47 +0200, Ahmad Samir wrote:
> I've tested the F20 desktop live CD, the installer doesn't let me
> continue unless I set a root password.
It is happy so long as you *either* set a root password *or* create an
admin user account.
I missed the bit about the admin user account (I usually never enable
that option).
--
Ahmad Samir
3424
days inactive
3426
days old
11 comments
5 participants
participants (5)
-
Adam Williamson -
Ahmad Samir -
Chris Murphy -
M. Edward (Ed) Borasky -
R P Herrold