Re: F21 emergency.target when root pw isn't set
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)
On Thu, 18 Dec 2014, Chris Murphy wrote:
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
;(
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)
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