Bug 258981 - rootpw --iscrypt fails
rootpw --iscrypt fails
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All All
medium Severity low
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-08-27 23:10 EDT by Jonathan S. Shapiro
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-28 17:06:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jonathan S. Shapiro 2007-08-27 23:10:21 EDT
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-27 23:12:38 EDT
Sorry. That isn't the correct cross-reference. The scenario is described in

I guess I've been doing too much stuff with anaconda this week. :-)
Comment 2 Chris Lumens 2007-08-28 14:15:26 EDT
How is it failing?
Comment 3 Jonathan S. Shapiro 2007-08-28 14:28:28 EDT
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 17:06:45 EDT
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 17:18:27 EDT
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 17:21:55 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.