RoboCup Junior Japan Rescue Kanto OB
2005~2013
2005~2013
バケツは常にカンストしてて貰っても使い道がなく消えていきます。イベントはよ
今日はyumの話です。
今日はyumの話です。
yum、redhat系linuxではおなじみのパッケージ管理ツールですね。
にゃーのですが、今日更新をかけてみたら、死んでいる事が発覚しました(´・ω・`)
所謂input/outputエラーです。updateやらinstallやらするとこんなエラーが。
つまるところのファイル欠損です。開けなくなっている訳ですね。
調べてみたら、色々わかりました。
まずは、欠損したファイル。これ以外にも
`/var/lib/yum/yumdb/p/c2873ddca31cd37e6ce60cf27d907ad773971bec-pcre-devel-8.32-15.el7-x86_64'
というファイルが死んでいるらしく、計2つのファイルがお亡くなりになっていることが発覚しました。
しかし、それ以外には異常はなし。
yumのデータベース内の上記2データが欠損しているだけで、
残りの機能自体は元気そうだったので、yumを再インストールするのも面倒だし、復旧させてみました。
まずは死んだファイルを移動します。ファイル単位で移動するとI/Oエラーを吐かれますが、
ディレクトリごとならエラーを吐くことなく移動することが出来ます。
移動できたら中身を全部cpで戻します。
死んでるファイルはI/Oエラーでコピーされないので生きてるファイルだけがコピーされます。
最後にlistの更新及びupdateします。
これでうちの子は復旧できました。
どうにもDBファイルの破損はyum checkで引っかからないようなので解決に時間がかかりました。
逆にyum checkしてみて何か問題があるようでしたらyumの方に問題がある可能性があるので
こんな汚い方法では直る可能性は低いでしょう。yum checkの実行には2時間以上かかりました(´・ω・`)
ただ、このままだと死んでいるファイル自体はyumdb.bak内に残されてしまいます。
どこからも参照されていないので動作に問題はありませんが、
時間がある時にe2fsckで削除しておくと良いのではないでしょうか。
当たり前ですが、yumdb.bak内の正常なファイルはe2fsckでは消えないので実行後にrmで消す必要がありますね
結局いつ死んだのだろうか・・・
yumのログを調べてみたのですが、去年の暮れのログがバグって死んでたので多分それなのかな。
postfixのインストール中に何かがあった。というところまではわかりましたが詳細は不明(´・ω・`)
そもそも入れた覚えがない・・・
恐らくインストール中に何らかの問題で固まってしまったのでしょう。
今年にyumを使ってインストールする機会がなかったのでずっと放置されていたということですね。
当然のごとくupdateもされていなかったので沢山updateが来ていました(updateシェル書いた意味・・・)
という訳で卒論のプレゼン書くつもりが酷い目にあってしまった今日この頃でした。
(^・ω・)ノ curonet at RadiumProduction
にゃーのですが、今日更新をかけてみたら、死んでいる事が発覚しました(´・ω・`)
OSError: [Errno 5] 入力/出力エラーです: '/var/lib/yum/yumdb/k/64b968d0890402aff193398e2019d5350e46ad83-keyutils-libs-devel-1.5.8-3.el7-x86_64/checksum_type'
所謂input/outputエラーです。updateやらinstallやらするとこんなエラーが。
つまるところのファイル欠損です。開けなくなっている訳ですね。
調べてみたら、色々わかりました。
まずは、欠損したファイル。これ以外にも
`/var/lib/yum/yumdb/p/c2873ddca31cd37e6ce60cf27d907ad773971bec-pcre-devel-8.32-15.el7-x86_64'
というファイルが死んでいるらしく、計2つのファイルがお亡くなりになっていることが発覚しました。
しかし、それ以外には異常はなし。
yumのデータベース内の上記2データが欠損しているだけで、
残りの機能自体は元気そうだったので、yumを再インストールするのも面倒だし、復旧させてみました。
まずは死んだファイルを移動します。ファイル単位で移動するとI/Oエラーを吐かれますが、
ディレクトリごとならエラーを吐くことなく移動することが出来ます。
sudo mv /var/lib/yum/yumdb /var/lib/yum/yumdb.bak
移動できたら中身を全部cpで戻します。
sudo cp /var/lib/yum/yumdb.bak /var/lib/yum/yumdb
死んでるファイルはI/Oエラーでコピーされないので生きてるファイルだけがコピーされます。
最後にlistの更新及びupdateします。
sudo yum list sudo yum update
これでうちの子は復旧できました。
どうにもDBファイルの破損はyum checkで引っかからないようなので解決に時間がかかりました。
逆にyum checkしてみて何か問題があるようでしたらyumの方に問題がある可能性があるので
こんな汚い方法では直る可能性は低いでしょう。yum checkの実行には2時間以上かかりました(´・ω・`)
ただ、このままだと死んでいるファイル自体はyumdb.bak内に残されてしまいます。
どこからも参照されていないので動作に問題はありませんが、
時間がある時にe2fsckで削除しておくと良いのではないでしょうか。
当たり前ですが、yumdb.bak内の正常なファイルはe2fsckでは消えないので実行後にrmで消す必要がありますね
結局いつ死んだのだろうか・・・
yumのログを調べてみたのですが、去年の暮れのログがバグって死んでたので多分それなのかな。
postfixのインストール中に何かがあった。というところまではわかりましたが詳細は不明(´・ω・`)
そもそも入れた覚えがない・・・
恐らくインストール中に何らかの問題で固まってしまったのでしょう。
今年にyumを使ってインストールする機会がなかったのでずっと放置されていたということですね。
当然のごとくupdateもされていなかったので沢山updateが来ていました(updateシェル書いた意味・・・)
という訳で卒論のプレゼン書くつもりが酷い目にあってしまった今日この頃でした。
(^・ω・)ノ curonet at RadiumProduction
カレンダー
最新CM
カテゴリー
らじぷろ目次
らじぷろ検索機
最新記事
(01/01)
(08/27)
(04/29)
(01/01)
(11/20)
(09/06)
(09/04)
(08/09)
(08/06)
(07/27)
(05/29)
(03/15)
(01/01)
(05/07)
(01/11)
プロフィール
HN:
Luz
性別:
男性
アーカイブ