Discussion:
F21 emergency.target when root pw isn't set
(too old to reply)
Chris Murphy
2014-12-18 18:31:02 UTC
Permalink
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
--
test mailing list
***@lists.fedoraproject.org
To unsubscribe:
ht
Adam Williamson
2014-12-18 22:16:13 UTC
Permalink
Post by Chris Murphy
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
--
test mailing list
***@lists.fedoraproject.org
To unsubscribe:
http
Chris Murphy
2014-12-18 22:30:41 UTC
Permalink
On Thu, Dec 18, 2014 at 3:16 PM, Adam Williamson
Post by Adam Williamson
Post by Chris Murphy
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
--
test mailing list
***@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/l
Chris Murphy
2014-12-18 22:35:12 UTC
Permalink
Post by Chris Murphy
On Thu, Dec 18, 2014 at 3:16 PM, Adam Williamson
Post by 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
--
test mailing list
***@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproj
R P Herrold
2014-12-18 23:14:27 UTC
Permalink
Post by Chris Murphy
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
--
test mailing list
***@lists.fedoraproject.org
To unsubscribe:
https://admin.fedora
Chris Murphy
2014-12-19 05:26:38 UTC
Permalink
Post by R P Herrold
Post by Chris Murphy
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
--
test mailing list
***@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listi
Ahmad Samir
2014-12-19 09:17:05 UTC
Permalink
Post by Chris Murphy
Post by Chris Murphy
On Thu, Dec 18, 2014 at 3:16 PM, Adam Williamson
Post by 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
--
test mailing list
***@lists.fedoraproject.org
To unsubscribe:
https://admin.fedo
Chris Murphy
2014-12-19 18:49:43 UTC
Permalink
Post by Ahmad Samir
/sbin/reboot -f
Right, thanks.
Post by Ahmad Samir
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
--
test mailing list
***@lists.fedoraproject.org
To unsubscri
M. Edward (Ed) Borasky
2014-12-19 19:56:36 UTC
Permalink
Post by Chris Murphy
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?
--
test mailing list
***@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mail
Ahmad Samir
2014-12-20 05:47:00 UTC
Permalink
Post by Chris Murphy
Post by Ahmad Samir
/sbin/reboot -f
Right, thanks.
Post by Ahmad Samir
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.
Post by Chris Murphy
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.
Post by Chris Murphy
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
--
test mailing list
***@lists.fedoraproject.org
To unsubscribe:
h
Adam Williamson
2014-12-20 07:38:11 UTC
Permalink
Post by Ahmad Samir
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
--
test mailing list
***@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman
Ahmad Samir
2014-12-20 14:11:25 UTC
Permalink
On 20 December 2014 at 09:38, Adam Williamson
Post by Adam Williamson
Post by Ahmad Samir
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
--
test mailing list
***@lists.fedoraproject.org
To unsubscri
R P Herrold
2014-12-19 19:17:31 UTC
Permalink
Chris had contacted me off list yesterday, and surfaced his
reply to the list earlier today. This was my response to that
piece

-- R


(Russ speaking, outside of the '>' markers)
Post by Chris Murphy
I'm not sure what this means.
I wanted to document in the ML thread, an alternative approach
which you might have used to avoid the unclean shutdown
problems you encountered (I did to, as I tried the approach
you documented) to the thread, and the d*mn systemd immaturity
shows that 'real' admins are not testing the systemd code.
The darn thing is just not ready yet, and RH had no business
basing its enterprise product off it in RHEL 7 ... Fedora --
sure -- go nuts, and keep all the broken pieces, but not RHEL
;(
Post by Chris Murphy
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.
the OS/X method I am familiar entails booting from alternative
media (a different partition or from media on older hardware,
and one assumes from USB on newer, and essentially having a
guided loop mount to not just blank, but actually set a new
hard passwd in the credentials database). So a variant of my
loopmounting and TUI manipulating the sick image under *nix

Windows is trickier as the credential 'lives' in a specific
hive segment in the registry (post Win 3.51 NT), and may
either be blanked, or have a hash of a credential stored on a
non-running client primary image, via a recovery instance
(sometimes secondary, sometimes media, etc)
Post by Chris Murphy
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.
all great questions / observations, but the systemd folks are
not to be criticized. It gets tiresome

best regards,

-- Russ
--
test mailing list
***@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinf
Chris Murphy
2014-12-20 20:56:51 UTC
Permalink
Post by R P Herrold
Chris had contacted me off list yesterday,
It was a gmail oops.
Post by R P Herrold
the OS/X method I am familiar entails booting from alternative
media (a different partition or from media on older hardware,
and one assumes from USB on newer, and essentially having a
guided loop mount to not just blank, but actually set a new
hard passwd in the credentials database).
For 5 major releases (5 years), a 650MB Recovery HD volume is created
at install time and boots into a minimal OS X: There's a Terminal
program for doing password resets from, web browser, Disk Utility, and
software restore. No password is needed for this environment. And
single user mode boot is also possible without a password.
Post by R P Herrold
Windows is trickier as the credential 'lives' in a specific
hive segment in the registry (post Win 3.51 NT), and may
either be blanked, or have a hash of a credential stored on a
non-running client primary image, via a recovery instance
(sometimes secondary, sometimes media, etc)
Looks like Windows has a really burdensome password reset. But startup
repair doesn't require any authentication to get into, and this
environment also includes access to a command line. So troubleshooting
and fixing boot problems is still possible without a password.
Post by R P Herrold
Post by Chris Murphy
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.
all great questions / observations, but the systemd folks are
not to be criticized. It gets tiresome
I'm not aware that there's been a discussion. It's roughly the same
time frame that anaconda lifted the set root password requirement, and
systemd starting requiring one. So I just don't think the consequences
of that combination was considered by anyone. I'll bring it up on
***@.
--
Chris Murphy
--
test mailing list
***@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/
Loading...