Elitebook-Ubuntu アップグレードの不具合を解消する
HP Elitebook 2560Pのマルチブート環境に 導入 している Ubuntu 14.04LTS を 16.04LTS にアップグレードしました。下の画像はデスクトップのスクリーンショットです。
Unity環境最後のバージョンとなります。ソフトウェアの更新アプリを使ってアップグレードを実行しました。システムモニター Conkyは事前に停止しています。
1つめの不具合
アップグレードのプロセスは何の問題もなく完了しパソコンを再起動したところで ブートプロセス中に1分30秒の待ち時間が発生しました。ただ、ログインする事はできました。
2つめの不具合
ログイン後、システムモニターConkyや日本語入力、その他のアプリなど特に問題もなく継承され正常に動作していることを確認できました。
ところがここで 1つ、厄介な事が起きていました。何と Windows 7、Windows 10と Ubuntuで共有しているデータパーティションがマウント出来なくなっていたのです。
3つめの不具合
さらにさらに何故だか Windows7の何かが破損したらしく起動できなくなっていました。今回のアップグレードが原因か否かは不明です。
幸いなことに、これらを全て解消することができたのでそれぞれの対処法を紹介します。(2019/04)
ブートプロセスの不具合
アップグレード直後にパソコンを再起動した際、ブートプロセスの実行中に下の写真(矢印部)のような待ち時間が表示されました。
画面のいちばん下の表示と言っても文字が小さすぎて見えませんね。下記が問題の表示です。
Boot Process:
[ *****] A start job is ruuning for dev-disk-by\x2duuid-72f19c25\
…(中略)… 94c7.device(1min 28s/1min 30s)_
ご覧のように次のステップまでの待ち時間が 1分30秒と表示されカウントダウンがスタートします。この時間は長いです。とてもじゃないが毎回待っていられませんね。
原因
調査の結果 Red Hat Bugzilla - Bug 699210 のページ、下から2つ目のバグ報告にその答えがありました。Fedora 15でこの問題が起こっていました。
“ Solved, the problem was a wrong swap UUID in fstab.”
訳すと “ 解決された、問題は fstab の間違ったスワップ UUIDでした ” となります。
つまり不具合の原因はアップグレードの際に SWAPパーティションが再フォーマットされたことにより UUID(Universally Unique Identifier)が更新されてしまったことです。
ところが SWAPパーティションを自動マウントするために fstab に記載されている UUIDは以前の(14.04LTS)まま更新されていない。
その結果、ブートプロセスの途中で存在しない SWAPパーティションを探している間にタイムアウト(1分30秒)したので、このプロセスを無視して次のプロセスが開始され Ubuntuは正常に起動したという訳です。
対処法
原因が分かったところで対処法です。Ask Ubuntuによると次の2つの方法が紹介されていました。
いずれも fstabの記述を編集する方法です。簡単に説明すると
- SWAP の UUID の行頭に # + スペースを挿入してコメントアウトする
- 更新された SWAP の UUID を上書きする
今回は 2.を行いました。
更新されたSWAPの UUIDを確認
パーティションのUUIDを確認するコマンドは blkid と lsblk があります。端末から
$ sudo blkid > UUID.txt・・・出力結果をホームディレクトリに保存する
または
$ sudo lsblk -f
>(リダイレクト)を付けると端末に出力結果は表示されません
下の画像はコマンド実行結果のスクリーンショットです。
ご覧のように lsblk の方が分かりやすいですね。下記は blkidコマンドの結果で、SWAPパーティションのみを抜粋しています。
GNOME terminal:
⋮
(前略)
/dev/sda5: LABEL="linux-swap" UUID="2e0d5be0-cbbb-4048-bcfc-7229b16bdaa6" TYPE="swap" PARTUUID="c203ae21-05"
(後略)
⋮
これが正しい UUIDになります。
参考までに、下の画像は SSDのパーティションを GPartedでスキャンしたスクリーンショットです。
このようなマルチブート環境を構築しています。
なお画像中 /dev/sda1(Windows7)と /dev/sda5(Windows - Ubntu共有)に!が付いていますがこれはページ冒頭で述べた残り2つの不具合を表しており、詳細は後述しています。
fstabを編集する
現在の fstabに記述されている SWAP UUIDとアップグレードにより更新された UUIDを比較し編集します。
端末から
$ sudo nano /etc/fstab
を実行すると現在の SWAP UUIDは下記のように
nano editor:
⋮
(前略)
# swap was on /dev/sda5 during installation
UUID=72f19c25-4679-4278-9138-85510dc094c7 none swap sw 0 0
14.04LTSの時のままになっており実際の、すなわち 16.04LTSの UUIDと異なっているのが分かります。
下の画像は前のパートで保存した UUID.txtと比較しているスクリーンショットです。
続けて正しい UUIDをコピー&ペーストして保存したらパソコンを再起動します。これでこの不具合は解消しました。
共有パーティションがマウントできない
Windowsと Ubuntuのデータを共有するために設定していたパーティション(ラベル名:DATA)が下の画像のようにマウントできなくなっていました。
ファイルシステムは NTFSでフォーマットしています。
現象と原因
GNOME Files(旧 Nautilus)の左ペインから DATAをマウントするためアイコンをクリックしたところ下記のメッセージが表示されました。
“DATA”にアクセスできません Error mounting /dev/sda6 at/media/fuukemn/DATA: Command-line mount-t “ntfs” -o “uhelper=udisks2,nodev,nosuid,uid=1000,gid=1000”“/dev/sda6” “/media/fuukemn/DATA/“ exited with non-zero exit status 14: The disk contains an unclean file system(0,0) Metadata kept in Windows cache,refused to mount. Failed to mount ‘/dev/sda6’:許可されない操作です The NTFS partition is an unsafe state. Please resume and shutdown Windows fully(no hibernation or fast resterting),or mount the volume read-only with the ‘ro’ mount option.
下の画像がそのメッセージのスクリーンショットです。
調査の結果 NTFS-3G-Arch Wiki のトラブルシューティングのセクションに原因の一部が掲載されていました。
それによると Windows 8や 10とのマルチブート環境で共有パーティションをマウントする時に起こるエラーで、Windowsの「高速スタートアップ」が原因であるとのことです。
見事に当方の環境と現象に一致します。高速スタートアップを無効にすることで解消するようです。
しかし管理人がここで注目したのは ユーザーID と グループID の番号が 1000 になっているところです。つまり所有権が管理者になっているためユーザー権限でアクセス出来ないわけです。
ユーザーに所有権がある場合は一般的に 500 になります。
対処法
そこでまず現ユーザー(fuukemn)が管理者的アクセス権を与えられたグループに所属しているか確認します。
$ groups fuukemn fuukemn:fuukemn adm cdrom sudo dip plugdev lpadmin sambashare
マウントデバイスにアクセスするための diskグループに所属していないので追加します。
$ sudo gpasswd -a fuukemn disk
下の画像はこの結果のスクリーンショットです。
コマンド実行後パソコン再起動しましたが同じエラーメッセージが表示されマウントできません。
Linuxディストリビュージョンにおけるユーザーとグループの定義は ユーザーとグループ-ArchWiki を参照
Windows 10 でアクセス権を変更する
Ubuntu上から修復するのをあきらめて、Windows 10上から DATAディレクトリのパーミッションを変更しました。
Windows風に言うと D:ドライブのアクセス許可エントリーに Everyone を追加してフルコントロールのアクセス権を付与しました。下の画像はそのスクリーンショットです。
アクセス許可エントリー追加の方法などはネット上でたくさん出てくるのでそちらを参照してください。
この設定後パソコン再起動して Ubuntu上から以前のようにマウントできるようになり、これでこの不具合も解消しました。
なお Windows 10の 高速スタートアップ は有効のままです。
Windows 7が起動しない
Ubuntuをアップグレードした後、Windows 7を起動しようとしたら黒い画面の拡張オプションメニューが表示され、どれを選択してもこのメニュー繰り返されるようになりました。
どうやらシステムが壊れたようです。そこで Ubuntuを起動して GPartedで Windows 7のパーティションをスキャンすると下表の状態でした。
パーティション | /dev/sda1 |
---|---|
ファイルシステム | ntfs |
マウントポイント | |
ラベル | win7x86 |
容量 | 70.00GiB |
使用済み | --- |
空き | --- |
フラグ | hidden |
下の画像はその時のスクリーンショットです。
/dev/sda1(Windows 7)パーティションの 使用済み と 空き の容量が表示されていませんね。通常ここには容量が表示されるはずです。
対処法
通常このような場合 DVDなどのインストールメディアから修復コマンドを実行してリカバリーを試みるのが一般的です。
しかしその成功率は経験上あまり高くないので、管理人は XP時代からバックアップイメージからパーティションまるごとレストア(復元)する方法を採っています。
今のところその成功率は 100%です。
今回もこの方法を用い、1ヶ月前に作成していたバックアップイメージで同パーティションをレストアして解決しました。
使用したツールは Acronis® True Image Home 2012 Plus のブータブルメディア(CD-R)です。マルチブート環境を運用する上で、必須のツールです。
雑感
下の画像は今回の不具合が全て解消したパーティションの状態を GPartedでスキャンしたスクリーンショットです。
Windows 7パーティションの 使用済み と 空き の容量が表示され正常にアクセスできています。
また DATAパーティションのマウントポイントも表示され正常にマウントされていますね。
実は Ubuntuをアップグレードする直前に Windows 7のアップデートと Windows 10 Insider Previewのビルドアップデートを実行していました。
なので今回の不具合が何に由るものなのか特定できませんでした。