Ari's Blog

Reading makes me rich !

Posts Tagged ‘fedora

元旦アップグレード(Fedora 20→21)

leave a comment »

2015 元旦アップグレード敢行!そしてめでたく Fedora 21 へアップグレード完了。

実は 2014 年中に完了したかったのだが、yum がアップグレード時にパッケージの依存関係を解決出来ず(毎度のことだが)、最終的に依存関係を解消出来たのが元旦になった、ということだ。

「依存関係を解決できた」と言えば何か作業をして解決したように聞こえるが、単に依存関係で問題になっているパッケージを順番にアンインストールしていっただけである。時間を要した原因としては、アンインストールできないパッケージがあったことが挙げられる。具体的には kde-settings-kdm がどうしてもアンインストールに失敗してしまうのだった。「yum remove kde-settings-kdm-19-23.fc19.noarch」で fail するのだ。ここにズバリ書いてあるが、rpm コマンドで —noscripts オプションを指定して削除(-e)すると削除できる。原因は rpm スクリプトのタイポらしい。「%systemd_preun」とするべきところを「%system_preun」としてしまっている(”d” が抜けてる)らしい。

これ以外は依存関係で解決できないパッケージを「yum remove パッケージ」でアンインストールしていった。主には rpmfusion-nonfree から入れてきたパッケージばかりだった。kmod-nvidia-* や mplayer などだ。これらは一旦抜いてアップグレードした後に再導入するのが常だ。

そんなこんなでようやくここに書いてある以下を完了し、アップグレード完了した。

# rpm –import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-21-$(uname -i)
# yum update yum
# yum clean yum
# yum –releasever=21 distro-sync

アップグレード後は問題なく()起動している。

後にすぐ分かったことだが、肝心の samba が起動はしているものの、ファイル共有ができていないことが判明。調査中で同様のエラーログ出力の記事も幾つかヒットするが、解決には至っていない。

追伸:
そう言えば、もう一つだけ少し余計な時間を要した出来事があった。外付け USB ハードディスクがアップグレード前のバックアップ中に故障した。赤い busy ランプが点灯したままでマウントがいきなり外れた。かまっている(調べている)暇はないし、LinkStation にもバックアップがとれるので LinkStation にバックアップを取得してアップグレード作業に入った。LinkStation を導入した時に、もうこの外付け HDD は不要だったのだが、それまでのバックアップはこの HDD に取得していたから、習慣的に?外付け HDD にバックアップを取得し、さらに LinkStation にもバックアップを取得していた(つまり2つのバックアップを取得していた)のだが、今回の故障によりバックアップ先が LinkStation のみになっただけ。

広告

Written by arito

2015-01-03 at 00:59

カテゴリー: Linux

Tagged with

Fedora 19 → 20

leave a comment »

恒例になった正月アップデート。今回は出たばかりでちょっとどうしようかと思ったのだが、前回の 18 → 19 があまりにもアッサリとアップデートできたので、今回もそれを期待しておもむろにアップデートを始めた。もちろん、外付け HDD にバックアップを取るところからだ。最近は毎度「玉砕覚悟」で始めているから。

※実はこの記事は、そのアップデートした後の Fedora 20 で書いている。快適だ!

前回の記事を見ると、簡単お手軽「fedora-upgrade コマンド」を実行したみたいだが、今回は fedoraproject.org のここを参考に実行した。

デスクトプで使っているので、kdm のログイン画面が起動しているので、Alt+N でコンソールログインに切り替えてから以下を実行。ちなみにコンソールログインに切り替えると、コンソールログイン画面が出るだけでなく、init 3 状態になる。

# rpm –import https://fedoraproject.org/static/246110C1.txt
# yum update yum
# yum –releasever=20 distro-sync

たったこれだけ。ただし、リポジトリに nvidia のドライバ関連の rpmfusion リポジトリがあるので、途中でそのキーをインストールする?というプロンプトが出る。入れないわけにはいかないので迷わず「Y」。

今回は依存関係の問題も全く問題なく完了した。

あまりにも普通に快適なので、IME を Mozc に変更してこの記事を書きつつ、できたてほやほやの Fodera 20 を楽しんでいる。(Mozc って Mac でも動くみたいだから試してみようかしら?)というか、IME に関しては、「Ibus Anthy」が「Ibus かな漢字」に変わって、キー設定に ATOK 設定できなくて、なんとも不可思議な設定で日本語を打ちつつ、英数文字の入力をしつつ、みたいなことが全然できない(できるのだろうけどやり方が分からないし、ATOK に慣れた手には全く使えないのだ…)

毎度アップデート直後問題になる vim も全く問題なく日本語入力ができ、毎度問題になる日本語自動折り返しも全く問題ない。こちらに関しても快適だ!

ということで、Fedora 20 アップデート直後からいきなり使いやすくて問題なくて快適でいいぞ!完成度高いんじゃないかい?

2014-01-07 訂正追記:

取り消し線で消した部分 ”「Ibus Anthy」が「Ibus かな漢字」に変わって” という部分は、完全に誤った情報でしたので訂正します。「Ibus Anthy」と「Ibus かな漢字」は異なる IME でそれぞれ別々に存在し、「Ibus Anthy」には以前と同様、キーマップに「ATOK」がありました。お詫びして訂正します。

※が、Mozc の方が日本語の変換精度が高かったので、そのまま Mozc をつかっている。

Written by arito

2014-01-03 at 00:03

カテゴリー: Linux

Tagged with , ,

Fedora 18 → 19

with one comment

FedUp でアップグレードすることを strongry に推奨されているのだけれど、/ パーティションが Software RAID になっているせいか、前回同様今回も FedUp は Upgrade kernel が起動に失敗してアップグレードできなかった。

dracut-initqueue [235]: Warning: Could not boot.
dracut-initqueue [235]: Warning: /dev/md1 does not exist
Starting Dracut Emergency Shell …
Warning: /dev/md1 does not exist

というエラー。Software RAID ファイルシステムを認識できないため、起動に失敗している。strongry に推奨するくらいなら、Software RAID くらい普通に認識できる Upgrade kernel 用意してほしいものだ。

で、今回も前回同様 yum でアップグレードすることにした。Fedora 19 のインストールディスクを作ってアップグレードも案としてはあるが、どうせアップグレードするための kernel はまた Software RAID を認識できないだろうから徒労に終わるだろうことが容易に想像できるし、前回 yum でダメ元でアップグレードしたら一応できた実績もあるから、今回も yum でアップグレードすることにした。(バックアップは外付けディスクに rsync で取得したから別に「壊れたらクリーン再インストールする」つもりで)

しつこいようだが、そもそも Software RAID を認識できないのだから、認識できている環境から直接アップグレードする以外に方法はないのだ。つまり、yum を使って Software RAID ディスクを認識できている状態(普通に Fedora 18 が起動している状態)からそのままアップグレードするしか選択肢はないのだ。

今回は前回の二の舞にならないように、FedUp によって grub.conf に書かれた Upgrade kernel 用の記述は予めコメントアウトしてから、fedora-upgrade コマンドを投入した。

F2 を押してコンソールから root でログイン
# fedora-upgrade

前回同様、古い設定ファイルをどうするか?と何個か聞かれるがデフォルトで OK なので単にリターンキーを押して進めばいい。後は待つだけ。場合によってはパッケージの依存関係を解決できずにエラー終了するが、その場合は根気よく依存関係を解決すべく、依存のある余計なパッケージをアンインストールしまくる。今回私の環境の場合、gnome-pilot なるパッケージが他のアップグレードされるパッケージの依存関係と競合して依存関係の解決に失敗したので、こいつをアンインストールして先に進めた。

前回は nvidia のドライバが未だ出ていなかったからか?不完全なものだったからか?は定かではないが、X が起動しなかった。今回は、fedora-upgrade コマンド終了後に再起動したが、何の問題もなく普通に Fedora 19 が起動してきた。なんだか逆に拍子抜けした。

起動が Fedora18 よりもさらに早くなった気がするし、今のところ何の問題もなく使えている。Fedora 18 へのアップグレード時が嘘のようだ。使っていて後で色々と判明してくるのかもしれないが、今のところ普通にデスクトップとして利用しているが不具合に気づいていない。素晴らしい!

Written by arito

2013-08-07 at 00:15

カテゴリー: Linux

Tagged with , , , ,

Fedora 18 kernel-3.7.4-204 の kmod-nvidia でようやく X 起動

with one comment

最初のアップデート?kernel-3.7.202 とその kmod-nvidia では初期の kernel 同様、X は起動しなかったが、今日アップデート確認したら再び kernel アップデートが出ていたのでリトライ。

3.7.4-204 では何事もなかったかのように X 起動した。

[ 8695.468] (II) NVIDIA(0): [DRI2] Setup complete
[ 8695.468] (II) NVIDIA(0): [DRI2] VDPAU driver: nvidia

変化としては、起動時の画面が今までは画面中央に Fedora のマークが徐々に見えてくるデザインだったのが、アップデートをしたら、Fedora 17 の時と同じデザインになった。つまり、画面下にプログレスバーが出るデザイン。

一瞬「あれ?Fedora 17 の kernel であげちゃった?」と思ったが、右側には「Fedora 18」の文字が浮かび上がる。起動して uname で確認しても、確かに新しい kernel で起動している。

なんだか狐に摘まれた感じだが、あまりの不具合で? FIX 版で仕様を元に戻したのか?何にしても普通に直ってよかった、よかった。

Written by arito

2013-01-28 at 00:25

カテゴリー: Linux

Tagged with

Fedora 18 で Chrome 起動せず(解決)

with one comment

とりあえず以前(Fedora 17)の kernel で起動して使っているが、Chrome が起動しなかった。

こんなエラー。

/usr/bin/google-chrome: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory

「libudev.so.0」がないので起動できないらしい。実施にないのか?

/usr/lib% ls -l /usr/lib/libudev.so*
lrwxrwxrwx 1 root root 16 1月 20 00:29 /usr/lib/libudev.so -> libudev.so.1.1.6*
lrwxrwxrwx 1 root root 16 1月 20 00:16 /usr/lib/libudev.so.1 -> libudev.so.1.1.6*
-rwxr-xr-x 1 root root 70708 1月 4 07:52 /usr/lib/libudev.so.1.1.6*

確かにない。.1 はあるが、.0 はない。安直にシンボリックリンクを張ったら起動できるのか?

/usr/lib% sudo ln -s libudev.so.1.1.6 libudev.so.0
/usr/lib% ls -l /usr/lib/libudev.so*
lrwxrwxrwx 1 root root 16 1月 20 00:29 /usr/lib/libudev.so -> libudev.so.1.1.6*
lrwxrwxrwx 1 root root 16 1月 20 18:14 /usr/lib/libudev.so.0 -> libudev.so.1.1.6*
lrwxrwxrwx 1 root root 16 1月 20 00:16 /usr/lib/libudev.so.1 -> libudev.so.1.1.6*
-rwxr-xr-x 1 root root 70708 1月 4 07:52 /usr/lib/libudev.so.1.1.6*

で Chrome を再度起動したら普通に起動した。

デスクトップで Fedora 18 を使うなら、まだ一ヶ月くらいは待ってからの方はよさそうだ。いや、もっと強く、待つべきだ。

Written by arito

2013-01-21 at 00:15

カテゴリー: Google, Linux

Tagged with ,

Fedora 17 → 18 成功編(除く X)

leave a comment »

Fedup でのアップグレードが失敗したので、従来通りの yum でのアップデートは問題なく完了した。

yum でのアップデートは、https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_17_-.3E_Fedora_18 に書いてある通りだが、今回はかなりおうちゃくして fedora-upgrade コマンド1つでやってしまった。上記手順をまとめてやってくれるコマンドなのだ。

# yum install fedora-upgrade
# fedora-upgrade

開始すると、いくつか古い設定ファイルをどうする?と聞いてくるが、バックアップを取っていれば、基本デフォルト選択(単に Enter)すればいいだろう。

で、普通に再起動したら、全然ログイン画面出ず…。

kernel の起動オプション何か変?と思って、grub.conf を見てみるとかなり変。コメントアウトはしていたが、Fedup で grub.conf に書かれた title 部分のオプションを引用されて、妙な起動オプションになっていたから?ssh どころか ping にも反応しない。

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (3.7.2-201.fc18.i686.PAE)
root (hd0,0)
kernel /vmlinuz-3.7.2-201.fc18.i686.PAE ro root=/dev/md1 rhgb quiet LANG=ja_JP.UTF-8 KEYTABLE=us upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup selinux=0
initrd /initramfs-3.7.2-201.fc18.i686.PAE.img
#title System Upgrade (fedup)
# root (hd0,0)
# kernel /vmlinuz-fedup ro root=/dev/md1 rhgb quiet LANG=ja_JP.UTF-8 KEYTABLE=us upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup selinux=0
# initrd /initramfs-fedup.img
title Fedora (3.6.11-5.fc17.i686.PAE)
root (hd0,0)
kernel /vmlinuz-3.6.11-5.fc17.i686.PAE ro root=/dev/md1 rhgb quiet LANG=ja_JP.UTF-8 KEYTABLE=us
initrd /initramfs-3.6.11-5.fc17.i686.PAE.img
title Fedora (3.6.11-1.fc17.i686.PAE)
root (hd0,0)
kernel /vmlinuz-3.6.11-1.fc17.i686.PAE ro root=/dev/md1 rhgb quiet LANG=ja_JP.UTF-8 KEYTABLE=us
initrd /initramfs-3.6.11-1.fc17.i686.PAE.img

KEYTABLE=us 以降の「pgrade systemd.unit=system-upgrade.target plymouth.splash=fedup selinux=0」が不要。

これを消して再起動したが、多少先に進んだが、Fedora のアイコンが画面中央に表示されたままやはりログイン画面は出ない。Ctl+Alt+Del にも反応せず。X を再起動する Ctl+Alt+BS すると反応があり、こんな画面が出る。もう一回 Ctl+Alt+BS すると、元の画面(Fedora のアイコンが画面中央にある画面)に戻るだけ。

IMG_1187

ただ今回は ssh できたので、Mac からリモートログインして確認してみる。

nvidia のドライバーのロードに失敗している。確認してみると、そもそも Fedora 18 の現在起動している kernel バージョンの kmod-nvidia がインストールされていない。インストールして再度再起動すると…

やはり同じ状況。X のログを見てみると、やはり nvidia のドライバーのロードに失敗している…。X が起動しない以外は、samba とか普通に動いている。仕方がないのでとりあえず Fedora 17 の kernel で起動している。

今までアップグレードはリリースされてから少なくとも一ヶ月は経過してから行なっていたが、今回一週間と経たずに実施したのだが、これが裏目に出ている。なにせ色々な不具合情報もとても少なく、パッケージもまだ初回リリースのものばかりでたくさんの警告メッセージやエラーメッセージが問題ある/なしに関わらずたくさん出ていて、ログ調査にも時間がかかる。

とりあえず、毎日 yum update して、まずは nvidia のドライバーアップデートもしくは kernel アップデート?を待って、GUI でのログイン画面を早く見たいものだ。それまでは Fedora 17 の kernel で起動して使うことにする。

2013/01/21 追記:

kernel が 3.7.2-204 へアップデートされ、それに対応した kmod-nvidia インストールされるも症状変わらず。

Written by arito

2013-01-20 at 18:09

カテゴリー: Linux

Tagged with ,

Fedora 17 → 18 失敗編

leave a comment »

Fedora18 がようやくリリースされた。

今回バージョンアップツールとして Fedup というツールが新たに作成され、これがアップグレードの推奨となっているので、早速これを使ってアップグレードをやってみた。

手順はここ

基本以下2つのコマンドでアップグレードできるはずだった。

# yum –enablerepo=updates-testing install fedup
# fedup-cli –network 18 –debuglog fedupdebug.log

が、タイトルの通り失敗した。原因は、アップグレードする Fedora のファイルシステムに Software RAID があったからだ。このバグ(https://bugzilla.redhat.com/show_bug.cgi?id=895805)に当たって、アップグレード起動に失敗する。

だが失敗するのが実際にパッケージのアップグレードをする前なので、以前の kernel(Fedora 17)を起動時に選べば、何事もなかったかのように Fedora 17 が起動する。

なので、現在普通に yum 使ってアップグレード中…。(非推奨だけど、全然普通にアップグレード走っとる!)

以下、Fedup が失敗するまでのスクリーンショット。

「fedup-cli –network 18 –debuglog fedupdebug.log」は問題なく完了し、ログにもエラーは1つも出力されなかった。

IMG_1183

この時点で grub.conf には、アップグレードするための kernel が一番先頭に追記されて、最起動後にアップグレードが開始される予定だった。

IMG_1184

そしてアップグレード起動直後、

IMG_1185

/(ルート)ファイルシステムのある /dev/md1 が見つからない、とアップデートが中断してしまう。しかもこの画面抜けられない。journalctl でログをとりあえず見て、最後にコンソールに出力されたログと同じ物しか出ていないことを確認し、「exit」とタイプしても、また同じ画面に戻ってくるだけ。電源 OFF/ON で再起動して、以前の Fedora 17 kernel で起動したら、今までの Fedora 17 で何事も無く起動した。

しかたがないので、今までどおり yum でダイレクトにアップデートしてみている。

Written by arito

2013-01-20 at 02:06

カテゴリー: Linux

Tagged with , ,

%d人のブロガーが「いいね」をつけました。