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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
