Ubuntu日本語フォーラム
ログインしていません。
ページ: 1
このタイトルではわかり難いかと思いますので少し説明をします。
これまでUEFI環境へのブートローダーのインストールは、Ubuntuと公式派生であるフレーバー(XubuntuやUbuntu Studioなどのことです)隔てなく「ubuntu」という一意的な識別子で登録されていました。ですが、13.04からはフレーバーが独自の識別子を用いるようになってきた(今はまだKubuntuが13.04から、Ubuntu Studioが13.10、のみ)ため、Kubuntuの場合は「kubuntu」などのように独立して登録されるようになりました。
ですが、それは同システムをインストールした場合であって、タイトルにある状況の場合ですと、そのようには登録されません。
これは、以前の「ubuntu」でインストールされた環境には「kubuntu」などのような識別子でインストールされていませんでしたので「/boot/efi/EFI/kubuntu」などのディレクトリーは存在していないわけなのですが、そこに、ブートローダーのGRUBが含まれているgrub-efi-amd64*パッケージのメンテナースクリプトでは「ブートローダーがインストールされるべきディレクトリーが存在していなかった場合は何もせずに処理を終了する」という全く噛み合っていない仕様となっているため、同パッケージの更新があってもブートローダーが更新されず、古いのが使われ続けてしまうということです。
※ システムのインストールではなぜブートローダーがインストールされるのかですが、これはシステムのインストール時にgrub-installコマンドが実行されるからです。grub-installコマンドではディレクトリーが作成されます。
さて、ではこれは修正しておいたほうが良いのか?ですが、何とも言えません。
潜在的にはGRUBの整合性がなくなれば起動できなくなるという可能性は孕んでいます(GRUBはEFIシステムパーティション内にインストールされたブートローダーだけでは完結しておらず、Ubuntuのシステム内にあるパーツが必要になります。ただし、署名されたGRUBの場合は全部?のパーツを組み込んでいるようですので、少し事情が違います)。
ですが、現状ではこの問題に限らずEFIなGRUBとフレーバーの識別子との絡みにはいくつか問題がありますので、今後、仕様が変更されるという事も考えられます。また、このような環境は少なくないはずなので(他のフレーバーも追従したらと考えると更にですよね)、実際に問題になるようであれば、何らかの対策を講じてくることも可能性は少ないかもしれませんがなくはないと思いますので、下手に手を打たないほうが良いとも考えられます。
と言いつつ、対処方法なのですが、「システムをインストールしたのと同じになるようにフレーバー化させてしまえ」というのであればそれほど問題にはならないと思います。というか問題になったら困りますよね。
逆に、今までの「ubuntu」のままでGRUBの更新も、ということですと、あまりお薦めはできないかもです(が、一応方法は載せます…)。
まずは次の#2の投稿を参照して状況を確認してください。これは必須です。
結果、特に何もした覚えがないのにブートローダーが問題なく更新されるようであれば、この問題は既に解決されているということになります。
更新されなかった場合は以下が対策方法となります。必ず確認作業を行なって状況を把握してから行なってください。
1. システムをインストールしたのと同じになるようにフレーバー化させてしまえ
もの凄く単純なのですが、「端末」などのターミナルアプリケーションで、
sudo grub-install
を実行するだけです。
ただし、署名されたブートローダーがインストールされている場合は他の問題まで絡んできます。また、Ubuntuファミリーでマルチブートをしている場合もちょっとした問題があります。
「UEFIモードで13.10のKubuntuとUbuntu Studioをクリーンインストールすると「grub>」プロンプトに落ちて起動できません」というタイトルでトピックを立てています(予定)ので、実行する前にそちらをお読みください。
以上です。
2. 「ubuntu」識別子を維持したままGRUBの更新も行えるようにする。
「/etc/default/grub.d/」にあるフレーバーの設定ファイルを「.cfg」で終わらないようにリネームしてください。
以上です。
オフライン
この投稿はEFIなGRUBの諸々の確認方法を載せています。
結果に少しでも不振な点があったり、わかり難い点がありましたら、作業を中止してフォーラムで質問してください。
0. インストール済みのOSを起動する
「grub>」プロンプトで起動できない状況にある場合はこの方法でシステムを起動させてください。
まずはgrubプロンプトで「 search -f /boot/grub/grub.cfg 」コマンドを実行してGRUBの設定ファイルを探してください。(/bootを別パーティションにしている場合は「/grub/grub.cfg」で探してください)
grub> search -f /boot/grub/grub.cfg hd1,gpt4 hg1,gpt2
すると上記のように「hd1,gpt2」などが出力されると思います(接続されているデバイスやパーティション構成により内容は変わります。上記の場合はマルチブートにしているため、複数の情報が出力されています)。
このパーティション情報を付加したパスを「configfile」コマンドで指定し実行するとGRUBの設定ファイルが読み込まれますので、システムを起動させられます。
configfile (hd1,gpt2)/boot/grub/grub.cfg
※ 日本語キーボードのキー配列ではありませんので、「(」などは「Shift + 9」キーだったりするかもしれません。
なお、これはLive版のGRUBからも行うことができます(GRUBメニューで「ESC」キー又は「C」キーを押すことでgrubプロンプトに移行することができます)。
「grub rescue>」に陥っている場合でもLive版からこの方法で楽に起動させられる可能性があります。
この起動方法はこちらを参考にさせていただきました。
https://forums.ubuntulinux.jp/viewtopic.php?pid=97105#p97105
1. パッケージの構築状況を確認する
システムを起動させたら、まずは「/sys/firmware/efi」というディレクトリーが存在するか確認してください。存在しない場合はUEFI環境ではありませんのでここのトピックとは無関係です。以降は行わないでください。
次に「端末」などのターミナルアプリケーションで「 COLUMNS=150 dpkg -l grub-efi-amd64\* grub-pc shim\* efilinux\* 」コマンドを実行して、EFI仕様のGRUB(grub-efi-amd64パッケージ)がインストール済みになっているか確認してください。
ちなみに下記の例は署名されたGRUB(grub-efi-amd64-signed)と署名されたshim(shim-signed)もインストールされている場合のものです。
$ COLUMNS=150 dpkg -l grub-efi-amd64\* grub-pc shim\* 要望=(U)不明/(I)インストール/(R)削除/(P)完全削除/(H)保持 | 状態=(N)無/(I)インストール済/(C)設定/(U)展開/(F)設定失敗/(H)半インストール/(W)トリガ待ち/(T)トリガ保留 |/ エラー?=(空欄)無/(R)要再インストール (状態,エラーの大文字=異常) ||/ 名前 バージョン アーキテクチ�� 説明 +++-===============================-====================-====================-==================================================================== ii grub-efi-amd64 2.00-19ubuntu2 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 version) ii grub-efi-amd64-bin 2.00-19ubuntu2 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 binaries) ii grub-efi-amd64-signed 1.22+2.00-19ubuntu2 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 version, signed) un grub-pc <なし> (説明 (description) がありません) ii shim-signed 1.3+0.4-0ubuntu3 amd64 Secure Boot chain-loading bootloader (Microsoft-signed binary)
出力結果がPC BIOSバージョンのGRUB(grub-pc)のほうが「ii」となっていた場合はUEFI環境で構築されていません。状況を複雑にしている・あるいはしてしまう可能性がありますので、以降は行わずフォーラムで質問してください。
grub-efi-amd64が「ii」となっていない場合は別の問題が発生しています。こちらの場合もフォーラムで質問してください。
2. 実際の登録状況を確認する
まずは「 sudo efibootmgr -v 」を実行してUEFIのブートエントリーがどうなっているのかを確認します。
$ sudo efibootmgr -v BootCurrent: 0003 BootOrder: 0004,0003,0000,0001,0002 Boot0000* EFI DVD/CDROM ACPI(a0341d0,0)PCI(1,1)ATAPI(1,0,0) Boot0001* EFI Hard Drive ACPI(a0341d0,0)PCI(d,0)03120a00000000000000 Boot0002* EFI Internal Shell MM(b,7fc4f000,7ffbefff) Boot0003* kubuntu HD(1,800,f3800,99b3763e-2cb7-4d35-94fb-f7dc080bad1a)File(\EFI\kubuntu\shimx64.efi) Boot0004* ubuntustudio HD(1,800,f3800,99b3763e-2cb7-4d35-94fb-f7dc080bad1a)File(\EFI\ubuntustudio\shimx64.efi)
この例では「BootCurrent」が「0003」ですので「kubuntu」のブートローダーでシステムが起動されているのがわかります。また、ブートローダーとして「shimx64.efi」が使われているのがわかります。
※ 現在のUbuntuはセキュアブートへの対応として、MSにより署名されたshimからCanonicalにより署名されたGRUBへチェインロードする方法を採っています。上記の「shimx64.efi」がそのチェインローダーshimです。現在は同じディレクトリーにあるgrubx64.efiをロードするように構築されています。これら署名されたローダーがインストールされていない環境の場合は「grubx64.efi」が示されていることと思います。
次に識別子を置き換えるための設定ファイルが存在しているのかを「 grep -H GRUB_DISTRIBUTOR /etc/default/grub.d/* 」コマンドで確認します。ファイルマネージャーでファイルの存在も確認しておいてください。
$ grep -H GRUB_DISTRIBUTOR /etc/default/grub.d/* /etc/default/grub.d/50_kubuntu.cfg:if [ "${GRUB_DISTRIBUTOR}" = "Ubuntu" ] ; then /etc/default/grub.d/50_kubuntu.cfg: GRUB_DISTRIBUTOR="Kubuntu"
上記はKubuntuの場合です。「50_kubuntu.cfg」がKubuntuの用意した設定ファイルです。
Ubuntuなど専用の識別子を持たないものは「/etc/default/grub」にあるものが使われますのでファイルを用意しているという事はありません。
続いて、「 ls -R --full-time /boot/efi/EFI/ 」を実行してインストールされているブートローダーと更新日時を確認します。
$ ls -R --full-time /boot/efi/EFI/ /boot/efi/EFI/: 合計 8 drwxr-xr-x 2 root root 4096 2013-10-19 11:49:16.000000000 +0900 kubuntu drwxr-xr-x 2 root root 4096 2013-10-19 19:54:02.000000000 +0900 ubuntustudio /boot/efi/EFI/kubuntu: 合計 2212 -rwxr-xr-x 1 root root 125 2013-10-19 11:49:16.000000000 +0900 grub.cfg -rwxr-xr-x 1 root root 903544 2013-10-19 11:49:16.000000000 +0900 grubx64.efi -rwxr-xr-x 1 root root 1355656 2013-10-19 11:49:16.000000000 +0900 shimx64.efi /boot/efi/EFI/ubuntustudio: 合計 2212 -rwxr-xr-x 1 root root 125 2013-10-19 13:54:02.000000000 +0900 grub.cfg -rwxr-xr-x 1 root root 903544 2013-10-19 13:54:02.000000000 +0900 grubx64.efi -rwxr-xr-x 1 root root 1355656 2013-10-19 13:54:02.000000000 +0900 shimx64.efi
続いてブートローダーを更新させます。
必ず上記のdpkgでgrub-efi-amd64パッケージがインストールされていることを確認してください。インストールされていない状態で実行するとパッケージがインストールされてしまいます。
では、「 sudo apt-get install --reinstall grub-efi-amd64 」を実行してパッケージを再インストールしてください。これによりパッケージが更新された時と同じような状況を体現できます。
$ sudo apt-get install --reinstall grub-efi-amd64 パッケージリストを読み込んでいます... 完了 依存関係ツリーを作成しています 状態情報を読み取っています... 完了 アップグレード: 0 個、新規インストール: 0 個、再インストール: 1 個、削除: 0 個、保留: 0 個。 44.8 kB 中 0 B のアーカイブを取得する必要があります。 この操作後に追加で 0 B のディスク容量が消費されます。 パッケージを事前設定しています ... (データベースを読み込んでいます ... 現在 122251 個のファイルとディレクトリがインストールされています。) grub-efi-amd64 2.00-19ubuntu2 を (.../grub-efi-amd64_2.00-19ubuntu2_amd64.deb で) 置換するための準備をしています ... grub-efi-amd64 を展開し、置換しています... grub-efi-amd64 (2.00-19ubuntu2) を設定しています ... BootCurrent: 0003 BootOrder: 0004,0000,0001,0002 Boot0000* EFI DVD/CDROM Boot0001* EFI Hard Drive Boot0002* EFI Internal Shell Boot0004* ubuntustudio BootCurrent: 0003 BootOrder: 0003,0004,0000,0001,0002 Boot0000* EFI DVD/CDROM Boot0001* EFI Hard Drive Boot0002* EFI Internal Shell Boot0004* ubuntustudio Boot0003* kubuntu Installation finished. No error reported. Generating grub.cfg ... Found linux image: /boot/vmlinuz-3.11.0-12-generic Found initrd image: /boot/initrd.img-3.11.0-12-generic Found Ubuntu 13.10 (13.10) on /dev/sda4 done
※ GRUBの更新になぜgrub-installを使用しないのかですが、grub-installで更新させてしまうと状況が変わってしまう場合もある(確認という意味では完全に状況が変わってしまう)、またそれはユーザーの望まない形である可能性があるからです。
パッケージの再インストールが滞りなく済みましたら、再び「 ls -R --full-time /boot/efi/EFI/ 」を実行してみてください。何れかのブートローダーが更新されていますか?
オフライン
関連するバグ報告が上がりました。
識別子を持たせないなど元に戻すことも選択肢に入っているようですので、成り行きを見守ったほうが良さそうです。
参照: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1242417
オフライン
更新されたGRUBが配信されました。更新するとタイトルの件が解決されます(が、現時点ではUbuntu Studioは未対応です)。
更新後の仕様はこのようになります。
・識別子の使用は継続するためブートエントリーには「kubuntu」などのフレーバー名で登録される。
・ブートローダーのインストールについてはフレーバーは特別扱いされて「EFI/ubuntu」ディレクトリーにインストールされる。
つまり以前のバージョンからアップグレードした環境には「EFI/ubuntu」なディレクトリーが存在しているはずですのでブートローダーは再び更新されるようになり、変わるのはUEFIのブートエントリーが「ubuntu」から「kubuntu」にということだけです。
更新後のefibootmgrの出力内容を示すなら、このようになるはずです。
Boot0003* kubuntu HD(1,800,f3800,99b3763e-2cb7-4d35-94fb-f7dc080bad1a)File(\EFI\ubuntu\shimx64.efi)
(UEFIの利点が失われたことになり残念ではあるのですが、それでも自由までは奪わないでくれましたね)
なお、現時点では「GRUB更新の度にブートエントリーが増殖する」というバグがあります。
Ubuntu Studioの対応なども含め、これらは次期Ubuntuに持ち越しになるかもしれません。
オフライン
14.04で仕様が変わりましたので報告します。
一言で言うと、元に戻りました。
KubuntuもUbuntu Studioも独自の識別子の使用をやめる「後退」という選択をしました(※1)ので、以前のように「ubuntu」として処理されるようになりました。
つまり、13.10から14.04にアップグレードすると以前のように「ubuntu」としてGRUBが更新されるようになります。
※1 kubuntu-settings-desktopの履歴によるとセキュアブート絡みで問題になるとかなんとか。RCの土壇場で切り替えてきたってことはギリギリまで模索していたのでしょうか…。
なお、13.10環境でgrub-installを実行した場合に於いて登録されるフレーバー名のUEFIエントリー(kubuntuやubuntustudio)ですが、14.04にアップグレードするとそれらは自動的に消えます。
この消える挙動の実体は、「UEFIのエントリーに、大文字小文字を問わず識別子の文字列が含まれているエントリー名が存在するなら、それらを削除する」といった仕様によるものです。#1でも少し触れたのですが、その頃よりも破壊的な作りになった感じです。
(上記エントリーの削除の件もそうですがgrub-installの仕様が微妙に変わっています。kubuntuは今でも特別扱いされているのですが、以前とは微妙に違った処理結果となります。それはまあ、kubuntuのGRUB_DISTRIBUTORがドロップされたので気にする必要はないのですが…。オプションのほうでは、以前はGRUBのバージョンを表示するだけだった「-v」オプションが、ブートローダーのインストールが行われる「print verbose messages.」に置き換わっています。この点は注意したほうが良さそうです)
(何気にC言語で書きなおされていて、コードを見るのが面倒になったなぁ…)
オフライン
ページ: 1