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

最後の編集者: kiyoshi (2008-05-22 22:15:01)

#2から引用

kiyoshiさん による投稿:

似たような人も居ますね。
https://bugs.launchpad.net/ubuntu/+sour … bug/223611
http://www.ubuntu-forum.de/index.php?pa … post198564

上のURLには、なかなか接続できないので確認できていないのですが、下のフォーラムのbandoさんの状態は、私の症状と全く同じです。
ドイツ語圏のフォーラムなので、私の行った検索ではヒットできませんでした。

また、当該フォーラムでは4月26日時点での投稿にそれ以上のコメントがついていませんので、解決した形跡がありません。
現時点では私のケースも修正方法が不明なのかも知れません。
ただ、このフォーラムの記事から、類似の症状が報告されていることがわかっただけでも、収穫になりました。

最後の編集者: 超初心者 (2008-05-23 17:57:54)

一度問題あるパッケージを削除して、最新のをインストールしてみてはどうでしょうか。
以前java関係のパッケージで同じような症状に遭遇したことがあるのですが、その際にパッケージを削除するという方法で解決できましたので。

原因が判明してきたようです。
職場では、なかなか下記のURLに接続できなかったので、自宅に帰ってから確認してみました。

Shibataさん による投稿:

他にも似たような状況が報告されています：
https://bugs.launchpad.net/ubuntu/+bug/222545
https://bugs.launchpad.net/ubuntu/+sour … bug/230582

ちなみに上のURLの人の場合、sysv-rcパッケージがおかしかった（なぜかDebianのパッケージを使っていた？）のが原因だったようです。
apt-cache policy sysv-rc
を実行した結果はどうなるでしょうか。通常は以下のようになるはずです（URLは違うと思います）：

そのフォーラムの記事を引用させていただきます。

上のURLの人のsysv-rcは、

sysv-rc:
  Installed: 2.86.ds1-38
  Candidate: 2.86.ds1-38
  Version table:
*** 2.86.ds1-38 0
        100 /var/lib/dpkg/status
     2.86.ds1-14.1ubuntu45 0
        500 http://ftp.freepark.org hardy/main Packages

で、私と全く同じです。

これに対するコメントが、

This problem is caused by the version of sysv-rc you have installed. That is a version from Debian. In Ubuntu Hardy you should have sysv-rc version 2.86.ds1-14.1ubuntu45. Unfortunately, the Debian version does not know the multiuser option to update-rc.d which is used in Ubuntu.
To solve the problem, you will need to downgrade sysv-rc to the Ubuntu version. You should be able to do that using Synaptic, select the sysv-rc package and use Package menu --> Force Version. Please remove the 2.86.ds1-38 sysv-rc package from /var/cache/apt/archives to prevent future problems. After that, you will probably need to run apt-get -f install, to fix the broken dependencies mentioned in your bug report.

で、この操作により解決したとのことです。

私のsysv-rcのバージョンもDebianのものになっているということですが、なぜこのようなことが起こるのでしょうか？

Debianバージョンの方がバージョンは上ですが、Ubuntuで採用されているマルチユーザーオプションを認識しないとのことで（このあたりの仕組みはよくわかりませんが）、ds1-38からds1-14に変更する必要があるとのことです。

さて、このコメントを見る限り修正は極めて簡単なようで、synapticマネージャか端末でsysv-rcのds1-38バージョンを削除してから、今までインストールに失敗していたパッケージをインストールすれば良いようです。
最近はガソリンが高いので、本日土曜日はおそらく職場に行かないと思いますので、月曜日に試みてみます。

Shibataさん による投稿:

sysv-rc自体は他のパッケージからも依存しているので、安全に削除するのは難しいと思います。Launchpadの解決策にもあるように、 Synapticの「バージョンの固定」を行ってから、ローカルアーカイブにキャッシュされている、Debian用パッケージの削除を行うという手順の方が、確実なんじゃないでしょうか。

そうですね。
今、手元に問題のマシンがないので、手順についてはまず問題のsysv-rcがSynapticにどのように表示されるか見てから判断しようと思っていましたが、このあたりの手順を先に聞いておいた方が良さそうですね。

前の返事では、バージョンの固定作業を無視したわけではなく、引用した解決策に書かれているので、わざわざ書かなかったのです。
誤解を招くような記載で申し訳ありません。

私の環境で、適切なリポジトリ設定した場合、Synapticではsysv-rcパッケージのプロパティで、インストール可能バージョンにds1-14が表示されるはずと予想して、それを選択してバージョンの固定を行った上で、現バージョンを完全削除すればよろしいと思っておりました。

あるいは、ds1-38の削除は必要なく、すべてアップグレードとしてやればよろしいのでしょうか。
Synapticによるds1-38削除やds1-14の再インストールの手順は解決策に書かれていませんが、そもそもYou will needではなく、probably need to run apt-get -f installという表現から、何か別の削除やインストール作業の記載がlinux使いには自明のこととして省略されているのではないかと勝手に想像しておりました。

ds1-38アーカイブパッケージの削除は、念のためというくらいに考えておりました。
バージョンをロックしておけば、後は端末でapt-get -f installを実行すればDS1-14へのダウングレードも行われるのでしょうか。
解決策の文書をそのまま受け取れば、そのようになります。

もっとも単純な手順をまとめますと、
１．Synapticでsysv-rcを選択する。
２．プロパティを開く。
３．インストール可能バージョンからDS1-14選択する。
４．パッケージメニューからバージョンの固定を選択する。
５．/var/cache/apt/archivesにds1-38のdevパッケージがあるはずであるから、それを削除する。
６．sudo apt-get -f installを実行する。
これでよろしいでしょうか。
２、３の手順が正しいかどうか自信がありません。
解決策をそのまま受け取れば、２，３の作業は必要ないことになります。

問題は、ds1-14が表示されず、それにロックできない場合どうするか考えておりましたが、そもそも上記の私の予想手順は完全にピンずれかもしれませんので、問題点があれば、そして特にバージョンの固定について解決策に書かれていない手順がありましたらぜひご教示ください。

最後の編集者: 超初心者 (2008-05-24 23:32:15)

親切なお返事ありがとうございました。

結論から申し上げますと、うまくいきませんでした。

まず、バージョン固定は昨日の手順通りに行ってみましたが、不思議なことに/var/cache/apt/archives/にsysv-rc ds1-38のアーカイブパッケージは見つかりませんでした。
どこにあるのでしょう？

confのアーカイブを別ディレクトリに移動してapt-get installを行うと、以下のようなエラーが出ました。

E: ロック /var/lib/dpkg/lock が取得できませんでした - open (11 Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?

そこで、どうせds1-38バージョンのsysv-rcでは、うまくいかず、依存関係にあるのはアップグレードできていないパッケージなので、#6のpadさんのやり方に相当しますが、思い切ってds1-38を削除してみました。
依存関係にあるcronやrsync、klogd、sysｋlogdなども削除されました。

その後、sysv-rcのds1-14バージョンををインストールすればよろしいはずである考えて実行してみましたところ、

dpkg: 'upgrade-rc.d'がPATH上に見つかりません。
dpkg:　一個のプログラムがPATH上に見つかりませんでした。
（注）：　rootのPATHは通常、/usr/local/sbin, /usr/sbin, /sbinを含んでいるはずです。
E: Sub-process /user/bin/dpkg returned an error code (2)

のエラーが返ってきました。

ということで、いつも再インストール可能である保証は無いので、＃７でお返事したように無碍に削除しない方がよろしいという予感は正しく、また、昨日のshibataさんの警告もしっかりと体験できました。

/var/cache/apt/archives/にds1-14パッケージはダウンロードされていましたので、手動でインストールを試みましたが、結果は同じでした。

さて、調べてみますと、ｄｐｋｇそのものはhardyのバージョンがインストールされています。
/usr/local/sbin/にupgrade-rc.dはあるのですが、リンク切れとなっており、リンク先の/usr/share/sysvinit/は存在していません。

再起動するとどういうことが起こるか楽しみにしていますが、何か解決法はありますでしょうか。
まことにお手数をおかけいたしますが、よろしくお願いいたします。

案の定、うまく再起動できません。

shibataさん による投稿:

なんらかの方法で（apt-get cleanを実行するとか、dselectを起動するとか）すると、キャッシュファイルがクリアされるので、そのへんで消えたのかもしれません。今回の手順に削除が入っているのは、キャッシュファイルが使われることを防ぐためですし、ないならないで問題ないんじゃないでしょうか。

ないのは問題ないのでしょうが、どうしてそのファイルがないのか不思議に思ったのです。どの時点でどの作業で削除されたのかはよくわかりません。

一昨日までのアップグレードの一連の作業で、端末で実際に実行したコマンドを一応羅列しておきます。
dpkg --reconfigure　(#2kiyoshiさんご指摘の通り実はdpkg-reconfigureの誤りだったようで、エラーが出た）

apt-get update
apt-get upgrade

dpkg --configure -a

apt-cache policy sysv-rc

くらいだったように記憶しています。

そして、本日はsysv-rc-conf_0.99-6_all.debをキャッシュから移動させてみることも試みたので、mvコマンドと、
apt-get install -f
apt-get update
apt-get upgrade
dpkg --configure -a
を実行したのみです。

ds1-３８バージョンはsynapticから削除しました。

shibataさん による投稿:

これは、メッセージどおりSynapticやアップデートマネージャなどAPT/dpkgを使う何らかのソフトウェアが起動しているためだと思います。 Synaptic・apt-getコマンド・アップデートマネージャなどは同時には使えませんので、ちゃんと終了させてから実行してください。終了させたつもりでも、システム・モニタを見ると残っているって場合もあります。それでも、一度再起動させたら問題はないはずです。

これは、経験上よくわかっているつもりでしたので、いろいろやってみたのですが、何が起動しているのかよくわかりませんでした。
当初はsynapticを起動したままapt-get installを実行してしまったのでエラーが出たと思い、synapticを終了してやってみたのですが、同じことだったように記憶しています。
また、アップデートマネージャもいったん起動してすぐに終了させてapt-get installを実行したのですが、やはり同じことだったように記憶しています。
それで、あまり関係ないとは思ったのですが、sysv-rc-conf_0.99-6_all.debをキャッシュフォルダから移動させてapt-get installを実行してみて、やはり関係なかったということです。
終了させたつもりでも、もし稼働していたとすると、それは想定外でした。

shibataさん による投稿:

"update-rc.d"ではなく、"upgrade-rc.d"でしょうか？
"update-rc.d"はsysv-rcパッケージに含まれているようですけど、"upgrade-rc.d"はどこにも見つかりませんでした。

基本的にパッケージからインストールを行った場合、"/usr/local/sbin/"にインストールされるファイルは存在しません（少なくとも公式リポジトリからインストールされるパッケージには存在しないはず）。/usr/local/sbin/upgrade-rc.dが存在するとしたら、それは例えば非公式リポジトリからパッケージをインストールしたとか、ソースアーカイブを./configure;make;sudo make installしただとか、超初心者さん自身が何らかの方法でそのファイルをインストールしたためだと思います（もちろん、アップデートマネージャの不具合という可能性もあるのですが……）。何か心当たりはございませんでしょうか。

これは、申し訳ありませんでした。
質問しておきながら、かなりいい加減な記載で本当に申し訳ありません。
年をとると、思いこみで書き始めるとそのように書いてしまうのでお許しください。
upgrade-rc.dではなく、update-rc.dです。

少し自信がなくなりましたが、/usr/loca/sbin/ではなく、/usr/sbin/だったかも知れません。
確認してみるとupdate-rc.dはperlスクリプトですか。
でも、/usr/share/sysvinit/update-rc.dのリンクファイルではなさそうですね。
私が確認した/usr/loca/sbin/update-rc.dか又は/usr/sbin/update-rc.dは確かに/usr/share/sysvinit/update-rc.dがリンク元でした。


過去、そのマシンにインストールするためにコンパイルしたとするとDazukoくらいだったと思うのですが。
また、リポジトリもsynapticに標準で用意されているもの以外は、確かにDebian用パッケージのリポジトリが表示されていました。
ただ、いまこの返事を記載しているマシンは、音楽用アプリ、動画用アプリを含めskypeなどはるかに多くのパッケージを導入しているのですが、Debianパッケージ用リポジトリ表示はなく、なぜシンプルに使用していた問題のデスクトップマシン(wineにもインストールしているアプリはありません）にそのリポジトリが導入されていたのか、どのように導入したのかよく覚えていません。

今思い返せば、一番最初にアップグレードに失敗したときに、うまくアップグレードできなかったメッセージとともに、どこかの作業で、「保証はないけれどDebian用パッケージを試みますか」という趣旨のメッセージが出てきて、「Yes」を選択したような、おぼろげながらそのようなことがあったような気がしてきました。
これとて定かではありませんが。
今思いますと、この作業が主要な原因の１つでしょうね。

最後の編集者: 超初心者 (2008-05-27 00:58:11)

shibataさん による投稿:

ごめんなさい。これ以上は手詰まりっぽいです。

大変なことにお付き合いいただいて、本当にありがとうございました。
このマシンは、ハードディスクが壊れて1年くらいほったらかしにしていたのを、メモリ増設してディスクを換装してUbuntuをインストールしていたマシンですので、何があっても個人的には困ることはありません。

昨日は、申し訳ありませんでしたが、本日調べてみるとupdate-rc.dは/usr/sbin/にありました。
昨日、初めて8.04のCDを焼いたのですが、ファイルの状況がわかってれば、CDからそのファイルをコピーしてアップグレードインストールを試してみても良かったのかもしれません。

shibataさん による投稿:

UbuntuでDebianのバイナリパッケージを利用することは推奨されないので、Debian用のリポジトリが表示されていること事態が不可解だと思うのです。

推奨されませんとは確かに表示されていましたが、なぜこれがリポジトリに入ったかその経緯については申し訳ありませんが、本当に記憶にないのです。
かなり初期（といってもこのマシンにUbuntuをインストールしたのが2ヶ月半前ですが）にDebianリポジトリを導入したのだと思います。

shibataさん による投稿:

Debianリポジトリの追加を尋ねてくるアプリケーションがあったということでしょうか。アップデートマネージャがそれを尋ねてきたのでしょうか。

リポジトリの追加を尋ねられたことはないと思います。
アップデートマネージャで8.04へのアップグレードを行う一連の作業中、しかも一部アップデートできなかったエラーの後に、「Debian用パッケージを試みますか」というメッセージが出てきたように記憶しています。
もともとエラーの段階で最終的にはクリーンインストールを考えていたので、「まあ、やってみるか」程度で「yes]を選択したのだと思います。

Ubuntuにおいては、非常に便利にできているので、インストールやアップデートをコマンドラインで行うことはまずありません。
外部からインストールしたのは、StarSuite,　Atok、AVG、Dazuko、キャノンプリンタードライバシリーズくらいでしょうか。
まあ、Dazukoはこのフォーラムでも話題になりましたが、apparmorをkillしてDazukoをロードする作業を行うためにinit関連のファイルをつついたことがあるので、そこに遠因があるかもしれません。

昨日からGUIでの再起動ができなくなっていたので、CUIでしばらく遊んでおりました。
丈夫なOSだと思います。
ファイルのコピーは普通にできますので、データ作業には問題ありません。

知識があれば必ず復旧作業はできると思うのですが、その知識を習得する時間や労力の問題がありますので、先ほどCDからクリーンインストールしました。
設定も含めすべての作業は1時間もかからなかったと思います。
NVIDIAの高性能グラフィックドライバも表示され仕様可能となりましたので、GUIも快適に使用できています。
昨日までより、非常に早く動作するように感じます。

教訓
１．クリーンインストールするのでなければ、できるだけデフォルト状態に戻してアップグレードする。
2．純正保証以外のパッケージはできるだけ使用しない（DebianとUbuntuは親戚でも別物）。
3．依存関係の復旧が保証されない場合、削除は行わない。

でも、今からもかなり失敗があると思いますので、その時はお助けください。

最後の編集者: 超初心者 (2008-05-27 16:44:54)