Bug 258981

Summary:	rootpw --iscrypt fails
Product:	[Fedora] Fedora	Reporter:	Jonathan S. Shapiro <shap>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED CANTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	medium
Version:	7
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-08-28 21:06:45 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jonathan S. Shapiro 2007-08-28 03:10:21 UTC

I'm seeing a weird case where rootpw --iscrypt CRYPTEDPWD fails but rootpw
*without* the iscrypt works fine. I've tried several encrypted passwords,
including a full rootpw line that worked successfully on a previous FC6
kickstart config.

The install scenario is a netboot install using the workaround for the DCHP
problem that I described in https://bugzilla.redhat.com/show_bug.cgi?id=253624.

I would be happy to try to collect debugging info on this, but I'm not sure how
to go about that. If you have time to advise, I will be happy to do it.

Comment 1 Jonathan S. Shapiro 2007-08-28 03:12:38 UTC

Sorry. That isn't the correct cross-reference. The scenario is described in
https://bugzilla.redhat.com/show_bug.cgi?id=258881

I guess I've been doing too much stuff with anaconda this week. :-)

Comment 2 Chris Lumens 2007-08-28 18:15:26 UTC

How is it failing?

Comment 3 Jonathan S. Shapiro 2007-08-28 18:28:28 UTC

When --iscrypt is used, it stops at the root password screen to request a root
password and wait for input. The password fields presented are blank. This
happens whether or not autostep is enabled.

When --iscrypt is not used, the password request page stays up long enough that
I can see it getting populated.

Hmm. Just to eliminate user stupidity as cause, how long is the timeout for
autostep on that page? I should re-check, because I was pretty tired, but my
memory was that hands free install really was coming to a dead halt on that screen.

If it's useful, I'm also now in a position to compare behavior against FC6
anaconda, because I set up an autoinstall config for that as well. None of this
takes very long, so let me know if that would be helpful.

Comment 4 Chris Lumens 2007-08-28 21:06:45 UTC

It's not all that obvious, but this isn't fixable for the same reason as the bug
I'm duping this to.  The problem is that with crypted passwords, when we stop on
the root password screen, we don't know what to display in the boxes.  So we can
only throw away the encrypted password and display an empty box to get input. 
We're stopping on the password screen because you're in autostep mode, just like
if you were doing an interactive kickstart install.

Suggestions for what to do here are welcome.

*** This bug has been marked as a duplicate of 181740 ***

Comment 5 Jonathan S. Shapiro 2007-08-28 21:18:27 UTC

So far as I know, there are only two modes: interactive and autostep. I had
thought that autostep was the proper mode to use for completely "hands free"
install. Apparently I am mistaken. Either I'm about to be very red-faced or
something is missing in the documentation.

What mode should be used in a kickstart file to get a completely automated,
hands-free install that will *not* stop at the root password page?

Comment 6 Jonathan S. Shapiro 2007-08-28 21:21:55 UTC

Since you asked for suggestions, here is a fairly obvious one: allow autostep to
proceed past the password dialog, but set the input box in that case to
non-encrypting and populate it with "<From KickStart>".

There is probably some obvious reason why this will not work; I don't know much
about the anaconda internals.