端末からの操作で「-」を含む文字列を使用して現象が確認出来ませんでした。

$ sudo passwd -S ユーザー名
でステータスを確認してみて下さい。
第3フィールドにパスワードを設定した日付が表示されます、その他の項目もヒントになるかも知れません。

お返事ありがとうございます。

実行してみたところ、以下のようになりました。
　$ sudo passwd -S nakasima
　[sudo] password for nakasima:
　nakasima P 01/10/2010 0 99999 7 -1
(1/10というのは9.10をインストールした日です。)
続いて
　$ sudo passwd nakasima
　新しいUNIXパスワードを入力してください:
　新しいUNIX パスワードを再入力してください:
　passwd: パスワードは正しく更新されました
　$ sudo passwd -S nakasima
　nakasima P 01/17/2010 0 99999 7 -1

変更できたはずなので、試しにアップデートマネージャを起動して、新しいパスワードを入力したところ無事認証されました。
しかし、念のため再起動して、端末で$ sudo passwd -S nakasimaとしてみると、
新しいパスワードは通らず、古いパスワードが通り、
　nakasima P 01/10/2010 0 99999 7 -1
と、再び表示されました。

何がいけないのでしょうか?

※規約違反により追放されたユーザの投稿は、ログインユーザにのみ表示されます。

みなさんご返事ありがとうございます。

kiyoshi　さんへ
クリーンインストールは、まず/dev/sda2(Ｗindows領域)だけ残して、他のパーティションを削除し、「連続する最大の空き領域を選択する」として行いました。

なお、システム>システム管理>ユーザとグループ　で、
パスワードを変更することは、依然としてできません。

このパスワード変更のGUIは、システムのアカウント(利用権を付加されたユーザー)についてのみ変更できます。

だから、最初にPCを起動したユーザーと、後から追加されたされたユーザーとは本質的に違う挙動をとるようです。
PCの持ち主は、起動したときのユーザー名とパスワードでログインしますが、このユーザー情報はどうやら
このGUIでは変更できないようです。追加されたユーザーのみの情報を変更する用途のようです。
なおユーザー情報は、/etc/passwd ファイルに、内容が保管されています。
また、パスワードをはじめとする機密情報は、このファイルには記録されていなくて、
/etc/shadow ファイルに保存され、セキュリティの関係から一部暗号化されたパスワードとして記録されています。
この情報を変更するコマンドとしては、useradd, userdel, passwdです。それもroot権限が必要です。
Ubuntuは、root情報がマスキングされたシステムいうか、本来rootとしてログインしない仕様です。
安全性優先で、root権限にて操作を推奨しないシステムとなっているようです。
どうしても管理者として実行する必要がある場合、
一時的にrootとして権限を付与された者として実行するコマンドが用意されています。sudo , gksuなどです。
最初、私もこの仕様が理解できず困惑しました。

私の環境では変更可能です。
8.10 -> 9.04 -> 9.10
登録ユーザー数名、root にパスワードを設定でインストール時のユーザーでログインしてパスワードの変更はOKでした。
nakasimamさんのUbuntuの使用状況や今後の運用方法によっては早めの対策をした方が良いかもしれません。
個人で使い、再インストールやデータの消失も大して気にかけないなら原因がつかめなくても大丈夫？かな。
システム上の何かがおかしい事は確かなので、忘れた頃に来るかも知れない障害に対しての心構え次第です。

・$ sudo fsck -y /dev/sdxxx   (Ubuntuのインストールパーティション)
・$ sudo apt-get install --reinstall gnome-system-tools
それで同じなら
$ sudo strace -o /tmp/test.log users-admin
としてGUIからパスワードの変更を実行。
最後のカーソルがクルクル回る箇所で終了させてください。
（素早く行なって下さい、ログは5万桁を軽く越えます。10万行以上はあっと言う間でしょう、素早く）
$ sudo tail -n 3k /tmp/test.log|grep open > ~/open.log
$ sudo tail -n 3k /tmp/test.log|grep close > ~/close.log
$ gedit open.log close.log
と実行して内容を張り付けてもらえると何かヒントが見えるかも。

$ sudo fsck -y /dev/sda5　が原因だとすると覚えてないと思いますが強制的に電源を切断した覚えはあるでしょうか？

と言うのも突然の電源遮断でファイルシステムが壊れる事が有ります。
それを軽減させる仕組みがジャーナリングシステムでUbuntuではExt3やExt4のファイルシステムが機能を備えています。
コマンドfsck は修復を行なうコマンドですが修復できない物は切り離して全体に一貫性を持たせて起動出来るようにします。切り離されたファイルは「lost+found」フォルダに格納されますが、復元は恐ろしく困難です。

（切り離しは生き物で言うと治療できない箇所は切断すると例えれます。
　　切断されて生きているがとても酷い状態だったり、お亡くなりになったり。
　　運が良ければどこを切断されたのかも感じず、切断さえもされずに治ることも。）

今回は使い込ライブCDで内蔵HDDをマウントしてデータの救出は出来ないでしょうか。

「enterを押してしまいました。」は恐らく因果関係は無いと思います。
2.6.31-18 でメモリの消費が異常になる現象が有ります。
起動時に650MBほど消費されて800Mb前後で落ち着くか酷いときには起動後1~2分で実メモリを食いつくしフリーズしますフリーズしますが、再起動時に「filesystemがmountできないといったエラー」が出るということは、やはり前者の急激な電源遮断による不具合が起こっていた可能性が大きいと考えます。

流れに乱れが生じますが、お許しを。
hir0さんが指摘された

root にパスワードを設定でインストール時のユーザーでログインしてパスワードの変更はOKでした。

について、試行しました。
システム　→　システム管理　→　ユーザーとグループ　で、
インストールしているユーザー名で、ログイン・パスワードの変更が問題なくできました。

私の環境では、この「ユーザーとグループ」は、使わないのでチェックマークを外して表示されない様にしていました。
「最初にPCを起動したユーザーと、後から追加されたされたユーザーとは本質的に違う挙動をとるようです。」
この#10のコメントは、間違いです。すみませんでした。

何だか混沌としてきましたね。

あっ、まず質問の件ですが正常です。
端末から起動するさいに、すでに管理者権限で実行しているので再手続きは必要ないのでアプリケーション側ではボタンを表示させない仕組みになっているのでしょう。

同じ現象と言うのはカーソルがクルクル回った状態で進まないのですよね？

$ sudo strace -o /tmp/test.log users-admin　はファイルシステムのtmpフォルダにtest.logと言うファイルを作ります。
やり直す場合は一度　$ sudo rm /tmp/test.log  として削除してから行なって下さい。

何を行なっている所で止まっているのかが分かると思いましたがクリーンインストール直後も同じ現象だとすると、また少し違う方向も考えなければいけないですね。　

・もう一度　fsck  を実行してみる。
前回の起動不能に落ちたファイルシステムの変調は、（電源遮断 or インストール時点から）の判断材料。
もしくは前回の起動不能は　fsck は関係していなかった。

・ライブCDをチェックしてみる。
ライブCDのメニュー画面にCDのチェック項目が有ると思いますのでディスク、ディスクデータの損傷を確認。

・HDDをチェックそてみる。
HDDに不良セクタの有無を確認する。　OSインストール時にデータを書き込む位置は＊同じなので偶然にソフトの実行部分の一部が不良セクタの上に書かれている可能性の確認。
読み込みでチェックをします。
$ sudo badblocks -vs /dev/sda5

もし読み書きでチェックをされるならかなりの時間は掛りますが
$ sudo badblocks -nvs /dev/sda5

・CDに収録されているソフトが壊れている？
$ sudo apt-get install --reinstall gnome-system-tools
を実行して再インストールしてみて下さい。
パッケージが無いとエラーが出た場合は
$ sudo apt-get update
を実行して、もう一度トライして下さい。

全てクリアすれば、、、さらに悩みますね。（安心してデータを保存して使用していく事が出きるかどうか）
・インストールディスクは正常である。
・HDDに問題は無い。
・ファイルシステムに異常は無い。
・ツールは最新の状態で再インストール済み。
後は何が関係してくるか思いつかないですね、う～ん

・恐らくエラーログは出ない、エラーを出す前に止まっているから。
・straceで止まっている所で行なっている処理が分かれば良いのですが。
・端末からは問題が無いのでアカウント等のファイル類の変調ではなくツール単独の不具合。

更に違う観点から行くと、メモリ容量が少ない。-> 「システム」「システム管理」「システム・モニタ」「リソース」で確認。
視覚効果が有効になっている事が原因（GUI上での問題）-> 視覚効果を確認、有効なら無効にしてみる。

う～ん、取り敢えず実行することで余分な思いは切り分けられて行くので、手を拱いているよりはましだと思うのですが、、、。

一つ心配なのが＃１２に書いたように

nakasimamさんのUbuntuの使用状況や今後の運用方法によっては早めの対策をした方が良いかもしれません。
個人で使い、再インストールやデータの消失も大して気にかけないなら原因がつかめなくても大丈夫？かな。
システム上の何かがおかしい事は確かなので、忘れた頃に来るかも知れない障害に対しての心構え次第です。

なので、私がいろいろ書くことで本意と反して「それを実行して返事を書かなければ行けない」と負担になる事です。
気楽な気持ちで挑んで下さい。

私の考えが外れている場合も有りますし、見落とした物を見つけられる方もいるかと思いますので他の方の意見も参考にしてみて下さい。

＞ALL
OSクリーンインストールして間もないのに、fsckしただけで突然システム起動不可になった話や、通常当たり前に出来る事(=パスワード変更)が妙な動きをする話を聞くと、何となくですが、HDDがあまり健康でない気がします。

私は、2,3年ほど不健康なHDDで無理矢理Ubuntuを動かしてきた経験があります。(無茶なので真似しないでください)

不健康なHDDの末期状態は、システムファイルが頻繁に紛失し始め、通常ありえない「怪奇現象」に悩まされました。(Firefoxが起動しない、音が出なくなる、突然read-onlyでルートファイルシステムがremountされる、pythonが動かない、etc)
例えば、Firefoxが起動しない時は、xulrunnerのシステムファイルが紛失していた、そんな感じです。
ファイルを紛失するタイミングには、fsck -yで修復する時が一番多かったように覚えています。

＞nakasimamさんへ
そのHDDは健康ですか？
起動時の定期fsckで、やたらとエラーで引っかかる覚えはありませんか？

きのうは、時間がなくお返事が遅れてしまいすみませんでした。
みなさんからのお力添えにとても感謝しています。

しやすそうなことから試してみました。
ライブCDのチェック→問題無し
(CDはUbuntu Magazine Japan vol.02の付録です)
$ sudo apt-get install --reinstall gnome-system-toolsを実行
→パスワード変更ができました!

いただきもののPCなので、前の所有者のもとでどのように扱われていたかは不明ですが、
ディスク・ユーティリティでは、HDDの状態は正常と表示されます。
9.10を入れる前は、8.04を入れていましたが、少なくとも8.04.3になってからは、
その前がいつだったか覚えていない程度でしか定期fsckは行われませんでしたし、
その際でもエラーで引っかかることはありませんでした。

パスワードの変更ができたので一安心です。
どうもありがとうございました。
もしまだなにかしたほうがよいこと、お教えしたほうがよいことなどありましたら、お知らせください。

長らくお付き合いいただきありがとうございます。

$ sudo badblocks -nvs /dev/sda5 を実行しました。
(/dev/sda にすると、not safe と出て実行できませんでした)
badblock は見つかりません、となりました。
よかったです。

話は違ってしまいますが、職場のノートPCには、xubuntu9.10をwubiで入れています。(9.04からオンラインでアップグレード)
試しにGUIでのパスワード変更をしてみようと、パスワード変更のボタンをクリックしても反応がありませんでした。
カーソルがくるくる回るのでもなく、フリーズしたわけでもありません。ただ反応がないのです。
本当は変更するつもりがないので、CLIでは試していません。
同じ問題なのでしょうか？
いろいろとすみません。