コグノスケ

未来から過去へ表示(*) link

過去から未来へ表示

もっと前

2015年5月3日 >>> 2015年4月20日

もっと後

2015年5月3日

permalink

編集する

GRUB2が起動しなくなってしまった

目次: 自宅サーバー

サーバにインストールしていたDebian 32bit版のJessieへのアップデートは一段落したので（systemdを諦めたりしてかなり適当ですが…）、ノートPCの仮想マシンにインストールしていたDebian 64bit版をapt-get dist-upgradeしました。

無事アップデートできたように見えたので再起動したら、GRUB2が起動しなくなりました。正確に言うとCUI画面で止まるようになってしまいました。

GRUB2 CUIから起動

grub> ls
(hd0) (hd0,msdos1) (hd0,msdos2) (hd1)

grub> set root=hd0,msdos1
grub> ls /boot
grub/ config-3.16.0-4-amd64 config-3.2.0-4-amd64 
vmlinuz-3.16.0-4-amd64 vmlinuz-3.2.0-4-amd64 initrd.img-3.2.0-4-amd64
System.map-3.16.0-4-amd64 initrd.img-3.16.0-4-amd64 System.map-3.2.0-4-amd64

grub> linux /boot/vmlinuz-3.16.0-4-amd64 root=/dev/sda1
grub> initrd /boot/initrd.img-3.16.0-4-amd64
grub> boot

この時点では上記のように手打ちで起動できたのですが、その後、間違えてgrub-installを実行してGRUB1をインストールしてしまい、なぜかrootパーティションのReiserFSを認識しなくなり、手打ちでも起動できなくなりました。ああー…。

復旧

ダメ元でKnoppixからgrub-installしてみると、なぜかReiserFSが読めたので、そこからもう一度Debian Jessieを起動し（GRUB1 CUIもGRUB2 CUIとほぼ同じ手順で起動できる）て、GRUB2を入れなおしました。

GRUB2再インストール

# apt-get install grub-pc --reinstall
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/220 kB of archives.
After this operation, 0 B of additional disk space will be used.
Preconfiguring packages ...
(Reading database ... 188824 files and directories currently installed.)
Preparing to unpack .../grub-pc_2.02~beta2-22_amd64.deb ...
Unpacking grub-pc (2.02~beta2-22) over (2.02~beta2-22) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up grub-pc (2.02~beta2-22) ...
Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
done

# dpkg-reconfigure grub-pc
    - Linux command line: はそのまま空欄で [ok]
    - Linux default command line: はそのまま "quiet" で [ok]
    - GRUB install devices: は [*] /dev/sda ... を選択して [ok]
Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
done

その後、再起動して、正常に起動することを確認しておしまいです。

編集者:すずき(2024/03/05 02:59)

コメント一覧

hdkさん(2015/05/04 21:40)
あれれ、grub-install で GRUB2 のインストールできますよね? 何か残骸が残ってる?

それはともかく、最初の GRUB2 が起動しなくなったのは、他に OS を入れていない環境ですかね。手元の環境でもなぜか GRUB2 の MBR へのインストールが自動的に行われなかったケースがあって、デュアルブートの Windows と手動で追加した項目だけが一覧に出る状態となっていました。
すずきさん(2015/05/04 22:57)
＞hdk さん
アップデート前の GRUB2 が起動している状態だったのですが、grub-install したら GRUB1 のまっ黒画面に戻りましたね。何か残骸があったのかもしれないですが、今となってはわからんです。

単なる 64bit 実験用の環境なので、OS は他に何も入れていないし、rootfs も /dev/sda1 で特に変な設定じゃないんですが、インストールに失敗しました。

他の環境はうまくいってたのに何でだろうなあ…？？
hdkさん(2015/05/06 21:45)
たぶん /var/lib/dpkg/info/grub-pc.postinst がインストールをしてくれるスクリプトなのですが、古い GRUB1 からの移行の処理がごちゃごちゃ書かれていて、失敗してる環境って GRUB1 のファイルが一部 /boot/grub に残ってる環境かも...?

と思って改めて手元のダメ環境を見直すと、debconf で grub-pc/install_devices_empty が true になっていたりして、そりゃインストールされないわな、みたいな、だいぶ前のアップグレードの時に GRUB2 への移行を嫌った選択が残ってたのかもなぁ、と。
すずきさん(2015/05/07 23:18)
＞hdk さん
うーむ、どれが GRUB1 のファイルなのか良くわからない…。

debconf って /var/lib/dpkg/info/grub-pc.templates の grub-pc/install_devices_empty のこと？値は false でした。
似たような項目名を探すと grub-pc/install_devices_failed_upgrade が true になってるくらいですねえ。

この記事にコメントする

2015年5月2日

permalink

編集する

systemdを使うのをあきらめた

目次: 自宅サーバー

独自ビルドのカーネルだと/sys/fs/cgroupが無いと言われて起動しないので、sysvinitに戻しました。ぶっちゃけsystemdだろうがsysvinitだろうが、どっちでもいいわ…。

しかしudevといい、systemdといい、便利は便利なんでしょうけど、Linux固有の機能に依存しまくりで面倒です。ブート周りを司るソフトがOS依存になるのは仕方ないのかなあ？

編集者:すずき(2024/03/05 02:58)

コメント一覧

コメントはありません。

この記事にコメントする

2015年5月1日

permalink

編集する

オープンソースプロジェクトの持続性

コンパイラ, エディタなど、かつて有料が当たり前だったのに、今やオープンソースが当たり前になっていて、有料だと逆に「なぜ有料なの？」と思ってしまいます。

良い時代になったよなあ、と思う一方で、オープンソースプロジェクトの持続性には疑問があります。

従来のようにソフトウェアを売る、という形での開発費回収が出来ませんから、最初は個人の情熱で維持できても、いつか開発費が捻出できなくなって破綻すると思うんです。

でも、あまり破綻したという話を聞かないのはなぜでしょう？実は零細プロジェクトから静かに破綻していってるけれど、影響力が小さいからニュースにならないだけなのか、それとも何か別の秘密があって、巧妙に回避できているのか…？

メモ: 技術系？の話はFacebookから転記しておくことにした。

編集者:すずき(2015/05/02 14:14)

コメント一覧

コメントはありません。

この記事にコメントする

2015年4月30日

permalink

編集する

Debian 8.0 Jessieにアップデート

目次: 自宅サーバー

Debianのアップデートが来ていたので、試しに職場のPCをアップデートしたところ、大きな問題なくアップデートできました。なぜか数時間かかりましたが…。

唯一引っかかったところと言えばApache 2.2から2.4にバージョンが変わっていて、Apache 2.2から引き継いだ設定が効いていなかったくらいです。

具体的にはOrder, Allowと書いていたところをRequireで書き直す必要があります。（Apacheのドキュメント Upgrading to 2.4 from 2.2 に詳しく記載があります）


Apache 2.2系
    Order allow,deny
    Allow from all

Apache 2.4系
    Require all granted

検索すると結構出てくるので、有名なハマりどころなのだと思います。

自宅サーバ

気を良くして、自宅のファイルサーバをアップデートしたところudevのアップデートでコケました。カーネルのコンフィグがudevのお気に召さないようです。

余程この問題でハマる人が多いのか、異常なまでに丁寧なエラーメッセージが出ます。

udevのアップグレードでエラー

Preparing to unpack .../archives/udev_215-17_i386.deb ...
Since release 198, udev requires support for the following features in
the running kernel:

- inotify(2)            (CONFIG_INOTIFY_USER)
- signalfd(2)           (CONFIG_SIGNALFD)
- accept4(2)
- open_by_handle_at(2)  (CONFIG_FHANDLE)
- timerfd_create(2)     (CONFIG_TIMERFD)
- epoll_create(2)       (CONFIG_EPOLL)

Please upgrade your kernel before or while upgrading udev.

...

あまりのメッセージの量に何事かと思いましたが、要はCONFIG_INOTIFY_USER, SIGNALFD, FHANDLE, TIMERFD, EPOLLを有効にしなさいと言いたいだけのようです。言われた通りに設定しカーネルを再コンパイルしたところアップデートが無事進みます。

独自ビルドしたカーネルを使うのを止めれば、こんな苦労はないのですけど。微妙なマザーボードを買うことが多いせいか、独自ビルドの方が楽なんですよね…。

編集者:すずき(2025/08/21 01:42)