刹那（せつな）の瞬き

Willkömmen! Ich heiße Setsuna. Haben Sie etwas Zeit für mich?

初めて鹿肉の調理に挑戦してみた　後編

生活

また後日楽しもうと残してた鹿肉ですが、結局その翌日に使い切るハメに。
色々あってストレスが溜まってしまい、無性に洋食が食べたくなったのです。

幸い調理用の赤ワインが 3分の1 くらい残ってたのと、たまたまトマト缶も半分に分けてあったので、もう合わせて煮るしかない！って感じのお膳立てですね。

◆ 鹿肉の赤ワイントマト煮

買い物に行けなかったので、あり物で何とかしてみました。

1. 材料（2・3人前）
  • 鹿肉　6,7cm四方で幅10cmくらいのブロック肉
  • 酒　大さじ 2
  • 塩　小さじ 1
  • 胡椒　少々
  • 片栗粉　大さじ 1
  • サラダ油　大さじ 2
  • ニンニク　2 片を 半分に切って芽を取る
  • 玉ねぎ　1 個を 5mm くらいにスライス
  • しめじ　1パックを半分
  • 赤ワイン　200cc くらい
  • コンソメ　キューブ2個
  • トマト缶　半分 200ml でトマトは崩しておく
  • ウスターソース　小さじ 1
2. 手順
  1. 解凍した鹿肉を 1.0〜1.2cm くらいにカットする。
  2. 鹿肉に酒(大 2)をふって軽く揉んでから、塩(小 1)と胡椒(2ふり)をふってまた揉む。
  3. フライパンにサラダ油(大 1)を入れて熱する。
  4. 鹿肉に片栗粉(大 1)をまぶして、フライパンで肉の全面に焼き色を着けて、一旦取り置く。
  5. 鍋にサラダ油(大 1)とニンニクを入れて熱する。
  6. 香りがたったらスライスした玉ねぎを入れて、軽く炒める。
  7. 中火にして、しめじを入れて軽く混ぜて、赤ワインを入れる。
  8. 煮立ってきたらコンソメキューブを入れて溶けるまで煮る。
  9. トマト缶を入れてしばらく煮る。
  10. ウスターソース(小 1)入れてから味をみて、塩で調整。
  11. 取り置いた鹿肉を鍋に入れてさらに煮る。
  12. 煮立ってきたら弱火にしてさらに煮る。
  13. 肉の具合が程良くなったら、火を止めて盛り付ける。
  14. 完成！

写真を撮ってる余裕がなかったのでエビデンスはありません。
見た目は何というかハッシュドビーフって感じでしょうか。
というか、味もそんな感じです。肉にクセが無いのであっさりしてます。

自分で作っておいて言うのも何んですが、私的にはとても美味かったです。
久しぶりにワインを使った料理を食べたので少しは機嫌も治りました。

煮込んだ鹿肉は食感は肉だけど、牛・豚・鶏どれでもない風味なので、煮込むソースによって印象が変わる感じです。
牛肉のような乳臭さは全くないので、ハッシュドビーフ等を食べ慣れてる方だと、バターを追加した方が口に合うかもしれません。

機会があれば、牛肉のスライスで作って比較してみようかな。

初めて鹿肉の調理に挑戦してみた　前編　

生活

秋が深まってきた今日この頃、ようやく家の冷凍専用庫の片付けに着手しました。

そしたら、新聞紙に包まれた鹿肉のブロックを発見。
あー、そういや父が知人から頂いたとか言ってたけど、スルーしてたなー

今回の頂き物は鹿肉で、6,7cm四方の幅20cmくらいのブロック肉を、専門の業者が真空パックでぴっちりと梱包し、冷凍保存したものでした。

ジビエが流行ってるとか関係なく、うちはよく野生のお肉を頂いてます。
昔は母が焼肉や鍋にしてくれて、美味しく食べてました。

そんな鹿肉ですが、今はもう自分で調理するしかないのですが、どうしましょう。

ネットで色々調べたところ、鹿肉自体は牛・豚肉と同様に扱えば良さそうです。
鹿肉の味はクセがなくてあっさりした味だった記憶があるので、その記憶を頼りに調理してみます。

....

よーし調理するぞ！と決意してもすぐは無理。カッチカッチの状態ですから。

先ずは解凍しなければ始まらないので、調理前日に冷蔵庫の野菜室に一晩放置。
実際は前日 22:00 くらいに入れて、当日 16:00 くらいに触ったら、ようやく少し柔らかい感じに。

いわゆる半生状態になってたので、ここで半分にカットしました。
今回は半分だけ使って、残りは冷凍庫に戻してまた後日。

◆ 鹿肉と野菜の炒め物

初挑戦なのに凝った料理に挑戦する気力はなかったので、先ずは炒め物です。

1. 材料（2人前）
  • 鹿肉　6,7cm四方で幅10cmくらいのブロック肉
  • 酒　大さじ 2
  • 塩　小さじ 1
  • 胡椒　少々
  • 片栗粉　大さじ 1
  • オリーブ油　大さじ 2
  • ニンニク　2 片を 2mm くらいにスライス
  • 玉ねぎ　1 個を 5mm くらいにスライス
  • その他の野菜　カットしたものを適量(今回はピーマンとキャベツ)
  • 砂糖　大さじ 2
  • 醤油　大さじ 2
2. 手順
  1. 解凍した鹿肉を 4mm くらいにスライスする。
  2. 肉に酒(大 2)をふって軽く揉んでから、塩(小 1)と胡椒(2ふり?)をふってまた揉む。
  3. フライパンにオリーブ油(大 2)を入れて、スライスしたニンニクを炒める。
  4. ニンニクに色が着き始めたら、ニンニクを取り出す。
  5. 肉に片栗粉(大 1)をまぶして、フライパンで肉の両面に焼き色が着くまで焼く。
  6. 続いてフライパンにスライスした玉ねぎを入れて、軽く炒める。
  7. お好みで野菜を追加して炒める。※私はピーマンとキャベツの端材を投入
  8. 全体に火が通ったら、醤油(大 2)と砂糖(大 2)を混ぜたタレを全体にかける。
  9. タレが馴染んだら、火を止めて盛り付ける。
  10. 完成！

写真を撮り忘れたのでエビデンスはありません。
完成品を父に見せたら「これ、牛タン？」というコメントをもらいました。
まぁ、実際の見た目は確かにそんな感じです。味も食感も全然違うけど...

実食した感じでは、予想した通りクセはありませんでした。
ケモノ特有の匂いは皆無です。とても美味しい肉でした。

クセがないと思ったので甘辛くしましたが、シンプルに塩胡椒だけで良かったかも。

残り半分の調理については後編で。

Ubuntuで壊れかけのディスクを小容量のディスクにクローンして復旧を試みた

Linux PC・ハードウェア

以前に不具合が発生して復旧した HDD ですが、最近は稀にデバイスそのものを認識しなくなるので、色々と心配になってきました。

相変わらず HDD に fsck や badblocks を試してみても不良ブロックは見つからないし、smartctl で自己診断してログを調べても異常は見当たりません。
シーク音も正常っぽいし、電源供給も安定してるし、未だに原因が特定できません。

しかし、これ以上つまらない事で悩みたくないので、この HDD が壊れてしまう前に別のディスクにクローンする事にしました。

苦労はしましたが、最終的にはクローンに成功したので、以下はその備忘録です。
※操作に失敗するとデータ消失の危険があります。要注意です。

1. クローン作成

まず PC の SSD/HDD 構成は次のとおりです。

デバイス OS 用途
/dev/sda (SSD) Windows10 ※今回は未使用
/dev/sdb (SSD) Ubuntu 20.04 今回の復旧作業で使用する OS
/dev/sdc (HDD) Ubuntu 18.04 元のディスク
/dev/sdd (HDD) 未割り当て 復旧用ディスク

今回は GUID もデータも「元のディスク」の内容を丸ごと「復旧用ディスク」にクローンするので、さらに別のディスクに存在する Ubuntu 20.04 で作業します。

ここで、/dev/sdd に接続した「復旧用ディスク」は、本来は複製元より容量が大きいディスクが望ましいのですが、あいにく手元には古く容量が小さい HDD しかありませんでした。

(1) ディスクの認識状態を確認

Ubuntu 20.04 (/dev/sdb) の起動後、fdisk を実行して各ディスクの状態を確認します。

$ sudo fdisk -l

〜(ざっくり省略)〜
ディスク /dev/sdc: 465.78 GiB, 500107862016 バイト, 976773168 セクタ
Disk model: WDC WD5000LPVX-0
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O サイズ (最小 / 推奨): 4096 バイト / 4096 バイト
ディスクラベルのタイプ: gpt
ディスク識別子: 2D86DB2C-8285-4483-88D1-EDAF06E991C5

デバイス   開始位置  最後から    セクタ サイズ タイプ
/dev/sdc1      2048   1050623   1048576   512M EFI システム
/dev/sdc2   1050624 976773119 975722496 465.3G Linux ファイルシステム


ディスク /dev/sdd: 465.78 GiB, 500106780160 バイト, 976771055 セクタ
Disk model: WDC WD5000AAKS-0
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: gpt
ディスク識別子: C40395DA-2155-AB44-9638-EA20F1BE4C04

実行結果から「復旧用ディスク」のセクタ数が 2,113 セクタ少ない事が確認できます。

この時点で「元のディスク」の /dev/sdc2 を縮小しておくと、後述の作業が楽になるのですが、デバイスの認識具合が微妙なので、この HDD に対する余計な負荷は避けたいところ。
今回はそのまま現状維持で、敢えて茨の道を行きます。

(2) ディスクのクローン

末尾の 2,113 個のセクタが欠落しますが、強引にクローンしてみます。

いつもは dd で済ませてますが、今回は GNU ddrescue を使ってみました。

$ sudo apt install gddrescue 
$ sudo ddrescue -f -n -v /dev/sdc /dev/sdd dd.log

dd.log の内容によると、処理に 3 時間を要してますが、特にエラーはありません。
dd.log には欠落したセクタの位置とサイズも記録されていますが、今回はスルーします。

ちなみに、sudo dd if=/dev/sdc of=/dev/sdd bs=4M conv=sync,noerrorを実行すると、最後に書き込みエラーで「デバイスに空き領域がありません」と出ますがクローンは作成されます。※1.5時間くらいで終了しました。バッファ大事...

(3) 複製元ディスクを撤去

ここで、一旦 PC をシャットダウンして、電源 OFF にします。

同じ GUID を持つディスクが 2 つ存在すると色々面倒なので、混乱しないように複製元のディスクを PC から外します。

2. パーティション復旧作業

「元のディスク」を外したので、PC の SSD/HDD 構成は次のとおりです。

デバイス OS 用途
/dev/sda (SSD) Windows10 ※今回は未使用
/dev/sdb (SSD) Ubuntu 20.04 今回の復旧作業で使用する OS
/dev/sdc (HDD) クローンした Ubuntu 18.04 復旧用ディスク

「元のディスク」の内容で丸々上書きした「復旧用ディスク」ですが、この時点では PC にデバイスとして認識されているものの、まだ OS 起動はできません。

再び作業用の OS を起動して「復旧用ディスク」をデバイス本来の情報に合わせて修復します。

(1) クローンした HDD の確認

Ubuntu 20.04 (/dev/sdb) を起動したら「復旧用ディスク」の状態を確認します。

sfdisk で調べると、セクタ数不整合のエラーが表示されます。

$ sudo sfdisk -l /dev/sdc
GPT PMBR size mismatch (976773167 != 976771054) will be corrected by write.
ディスク /dev/sdc: 465.78 GiB, 500106780160 バイト, 976771055 セクタ
Disk model: WDC WD5000AAKS-0
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x7bf55bc8

デバイス   起動 開始位置  最後から    セクタ サイズ Id タイプ
/dev/sdc1              1 976771054 976771054 465.8G ee GPT

パーティション情報がなくなってるようにも見えますが、gdisk で調べると、得られる情報が異なります。

$ sudo gdisk -l /dev/sdc
GPT fdisk (gdisk) version 1.0.5

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Disk /dev/sdc: 976771055 sectors, 465.8 GiB
Model: WDC WD5000AAKS-0
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 2D86DB2C-8285-4483-88D1-EDAF06E991C5
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2029 sectors (1014.5 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System Partition
   2         1050624       976773119   465.3 GiB   8300

「元のディスク」のパーティション情報のままなので色々と辻褄が合ってません。
ですが、パーティション情報の残滓は確認できたので、これを修復していきます。

(2) パーティションテーブルの回復

先ずは testdisk を使用して、パーティションテーブルを回復します。

$ sudo apt install testdisk
$ sudo testdisk

対話形式の画面になるので、次の手順で操作します。

  1. [ Create ] を選択。　※ログファイル生成
  2. カーソルキーで Disk /dev/sdc に移動し、[Proceed ] を選択。
  3. Disk /dev/sdc の情報表示。[ Continue ] を選択。
  4. [EFI GPT] を選択。
  5. [ Analyse ] を選択。
  6. とりあえず [Quick Search]を選択。
  7. 結果が「元のディスク」と同じパーティション構成なのを確認して q を押下。
  8. [ Write ] を選択。
  9. 「Write partition table, confirm ? (Y/N)」と表示されるので y を押下。
  10. 「You will have to reboot for the change to take effect.」と表示されるので [OK] を選択。
  11. [ Quit ] を選択。
  12. [    Quit    ] を選択して、testdisk を終了。

ここで一旦、作業していた OS を再起動します。

※この時点で「復旧用ディスク」の EFI パーティションが認識され、起動可能デバイスの対象になりますが、まだ起動できません。肝心の ext4 パーティションに不整合があるためです。

Ubuntu 20.04 (/dev/sdb) が再起動したら、もう一度 sfdisk と gdisk を実行します。

パーティションテーブルが回復したので、今度はエラーがあるのものの、それなりにパーティション情報が表示されるはずです。

(3) パーティションの不整合

改めて gdisk で「復旧用ディスク」の状態を確認します。

$ sudo gdisk -l /dev/sdc 
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Warning! Secondary partition table overlaps the last partition by
2098 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/sdc: 976771055 sectors, 465.8 GiB
Model: WDC WD5000AAKS-0
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 2D86DB2C-8285-4483-88D1-EDAF06E991C5
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 976771021
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System Partition
   2         1050624       976773119   465.3 GiB   8300

利用可能セクタの末尾が「復旧用ディスク」本来の 976771021 になりました。

しかし、パーティション 2 の終了セクタは「元のディスク」のままです。
容量の小さい「復旧用ディスク」には存在しないセクタ番号を指しているため、このままでは ext4 ファイルシステムとしてマウントできません。

sfdisk でも駄目な事が分かります。

$ sudo sfdisk -V /dev/sdc
/dev/sdc:
パーティション 2 はディスクに比べて大きすぎます。
エラーが 1 個検出されました。
(4) 不整合の解消

パーティション 2 の終了セクタが 976771021 以内を指すように調整してみます。

parted を使用して、対話形式で確認(print)しながら修正します。
正確にセクタ番号を指定したいので、処理はセクタ単位(unit s)で行います。

$ sudo parted /dev/sdc
GNU Parted 3.3
/dev/sdc を使用
GNU Parted へようこそ！ コマンド一覧を見るには 'help' と入力してください。
(parted) unit s                                                           
(parted) print                                                            
エラー: ディスクの外側にパーティションは作れません。
無視(I)/Ignore/取消(C)/Cancel? i                                          
モデル: ATA WDC WD5000AAKS-0 (scsi)
ディスク /dev/sdc: 976771055s
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt
ディスクフラグ: 

番号  開始      終了        サイズ      ファイルシステム  名前                  フラグ
 1    2048s     1050623s    1048576s    fat32             EFI System Partition  boot, esp
 2    1050624s  976773119s  975722496s  ext4

(parted) resizepart                                                       
パーティション番号? 2                                                     
終了?  [976773119s]? 976771021s                                           
警告: パーティションを縮小するとデータを失うかもしれませんが、それでも実行しますか？
はい(Y)/Yes/いいえ(N)/No? y                                               
(parted) print                                                            
モデル: ATA WDC WD5000AAKS-0 (scsi)
ディスク /dev/sdc: 976771055s
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt
ディスクフラグ: 

番号  開始      終了        サイズ      ファイルシステム  名前                  フラグ
 1    2048s     1050623s    1048576s    fat32             EFI System Partition  boot, esp
 2    1050624s  976771021s  975720398s  ext4

(parted) quit                                                             
通知: 必要であれば /etc/fstab を更新するのを忘れないようにしてください。
$

これで「復旧用ディスク」に適合したパーティション情報になりました。
強引に上書きして辻褄が合わなかった部分は解消されたはずです。

(5) ファイルシステムの回復

続いて パーティション 2 のファイルシステムを回復します。

/dev/sdc のパーティション操作を反映して、/dev/sdc2 の ext4 ファイルシステムを調整します。

$ sudo partprobe /dev/sdc
$ sudo resize2fs -f /dev/sdc2
resize2fs 1.45.5 (07-Jan-2020)
Resizing the filesystem on /dev/sdc2 to 121965049 (4k) blocks.
The filesystem on /dev/sdc2 is now 121965049 (4k) blocks long.

$ sudo fsck /dev/sdc2
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
/dev/sdc2: clean, 660856/30498816 files, 93048098/121965049 blocks

ようやく整合性が取れたディスクになりました。

$ sudo gdisk -l /dev/sdc
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 976771055 sectors, 465.8 GiB
Model: WDC WD5000AAKS-0
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 2D86DB2C-8285-4483-88D1-EDAF06E991C5
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 976771021
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System Partition
   2         1050624       976771021   465.3 GiB   8300  
$ sudo sfdisk -V /dev/sdc
/dev/sdc:
エラーは検出されませんでした。
ヘッダバージョン: 1.0
128 個のパーティションのうち、 2 個を使用しています。
合計 2014 個の空きセクタが 1 セグメント(最大 1007 KiB)内に、あります。

特にエラーがなければ、復旧作業は以上です。

後は PC を再起動して /dev/sdc の Ubuntu 18.04 を起動してみます。

3. 所感

HDD の不調から復旧作業を試みましたが、なかなか大変でした。

パーティションに不整合というか矛盾があると、普段利用してるツール類が悉く使えないなんて...ちょっとだけパーティションがはみ出しただけなのに！

移行が必要な場合、容量がより大きなディスクに退避してたし、SSD とか小容量の場合は新規に OS をイントールしてたので、全く気づきませんでした。

エラーがあっても parted でパーティションを縮小できるのに気づくまで、ホント無駄に試行錯誤してましたよ。成功して良かったです。

これで不良ブロックが存在してたらどんなに大変だったんだろう。
dumpfs とか使う日が来たりして...

その後、クローンしたディスクは無事に動作してます。
移行も済んだので、このまま経過観察しようと思います。

前門の「macOS Big Sur」後門の「ビンテージ入り」

Mac

iOS14 がリリースされて、iPhone アプリ開発側の阿鼻叫喚が聞こえたのはつい先日の話。
そろそろ macOS Big Sur のリリースも近づいてきました。

現在はパブリックベータ 7 が公開されているようですが、私はまだ試していません。
以前、macOS Mojave で試した際、外付け HDD が APFS に自動変換されてしまい、復旧するのに手こずって酷い目にあったのがトラウマになってます。
そのため、macOS Catalina 以降は触ってませんでした。

APFS の件は OS のサポートが開始して 4 つ目なので、もう無駄に不安を感じる必要はないのかなー。そしたら、せっかくの APFS なので、複数の macOS を仮想ボリュームに入れてみるのも良いかなー

....

macOS Big Sur の対象機種を確認すると、Macbook Pro は Late 2013 以降になってます。機種 ID で言い換えると、Macbook11,x 以降。

私の Macbook Pro Mid 2014 の機種 ID は Macbook11,2 なので、対象機種としては最低ラインということに気づきました。

改めて公式サイトを調べたら、ビンテージ製品とオブソリート製品の説明がありました。

support.apple.com

販売中止から 5 年以上 7 年未満の製品はビンテージ製品になると。
そうすると、当然 OS のサポート対象外になると。
なるほど。

....

足切りされた Early 2013 って、Thunderbolt1, 11n, Bluetooth 4.0  だけど、Core i7/i5 クアッドコアだし、Retina Display だし、SSD 標準で USB3.0 もあるのに。勿体無いなあ。

とは言うものの、Mid 2014 も来年にはビンテージ入り待ったなしです。
macOS Big Sur のリリースどころか足切りまで迫ってきました。

しばらくは Mojave と Big Sur を併用するとして、来年はどうしよう。
ハードウェアが万全なのに OS の提供が停止するのはとても辛いです。

サポートが切れた OSX / macOS で動作させるのはセキュリティ面でよろしくないので、余程の理由が無ければ避けたいところ。

やっぱり、今のうちに Mac mini 購入して、Mid 2014 には Linux 入れるのが良いのかも。

Macbook ProでのUbuntuの爆熱は既知の問題で解決策あり

Mac Linux

Macbook Pro Mid 2014 で Ubuntu 20.04 LTS を試用してみたら、爆熱で困った件。

Ubuntu (GNOME3)でダメなら Kubuntu (KDE5) で！
と、試してみたけど症状は変わりません。まぁ、そうでしょう。

ヒントを得るため、爆熱・爆音に冷や冷やしながらシステムモニタで観察してみます。
ある程度 CPU の使用率が落ち着いたところで、キャプチャした画像がこちらです。

f:id:infinity_volts:20200919090815p:plain

ずっとスレッドを捕まえてるプロセスがいるようです。

プロセステーブルを見た感じではそんなに激しく処理してるようには感じられません。
しかし、CPUコア0 を捕まえてるプロセスが kworker と分かりました。

....

「ubuntu macbook kworker cpu」で検索したら、あっさり同じ現象が見つかりました。

Ubuntu のバージョンは異なりますが、記事に従い問題となる gpe を調べてみます。

$ grep . -r /sys/firmware/acpi/interrupts/

つらつらと割り込みの一覧が表示されます。
その中に、明らかに周りと異なる大きな数値を示す割り込みがあります。
そして、私の環境でも記事と同様に gpe06 が悪さをしてました。

....

今回は試用なので、一時的に gpe06 を無効にしてみます。

$ sudo su -
# echo disable > /sys/firmware/acpi/interrupts/gpe06

効果はテキメンで、システムモニタで観察しても負荷はほぼありません。
爆熱・爆音も徐々に落ち着き、常用しても問題ないくらいになりました。

もし常用するなら、こちらの記事を参考に gpe06 の無効化を自動設定にします。

今のところ Macbook Pro は macOS Mojave で良いので、私はその都度設定してます。

Ubuntu20.04が入ったHDDをMacに接続したら普通に起動した

Mac Linux

先日、自作 PC の構成を変更してる傍ら、余った HDD が目に入りました。
中身は Ubuntu 20.04 LTS with GeForce ドライバ。

最近のマザーボードは UEFI メニューから起動デバイスを選択できるので、USB 接続した HDD でも OS が起動するか確認してみました。

まずはインストールに使用した Gigabyte B450 AORUS PRO WIFI での USB ブートです。

電源 ON → [F12] キーで起動デバイス選択メニューから、UEFI な USB-HDD を選ぶと、すんなりと起動し、いつものように使用できました。 

インストール時は SATA 接続でしたが、USB 接続に変更してもそのまま使用できました。
GUID パーティションテーブル様様です。

....

そして、そのOS起動可能な USB-HDD ですが、これを Mac に接続するとどうなるか試してみたくなりました。

私が使用してる MacBook Pro Mid 2014 は、EFI Boot 可能な機種です。
T2チップは搭載していないので、Mac mini 2010 の Mavericks な HDD からそのまま OS 起動できたりします。便利だなー

Linux 関連で心配なのは、GeForce ドライバが導入済みな事です。 
10年くらい前だと、GeForce ドライバを抜くなら再インストールの方が早いのでは？という、地雷臭漂うものでしたが、さてさて。

とりあえず何か映ればいいや、と思いつつ、件の USB-HDD を MacBook Pro に接続。
電源 ON → [option] キーを押っぱなし → Setup Manager が表示されるので「 EFI Boot 」を選択。

すると、、、

f:id:infinity_volts:20200917122537p:plain

何故か APFS 関連のメッセージが表示されました。
あれ？これって、内蔵 SSD のブート情報じゃ...

やっぱりダメかー
と、諦めつつ眺めてたら、10数秒後には Ubuntu の起動ロゴに切り替わりました！

そして、見慣れた Ubuntu のログイン画面までたどり着きました。
別 PC の USB-HDD からそのまま起動できるなんて、ちょっと感動です。

起動後、とりあえずキーボードとパッドが使えたので、そのままログイン。
拡張ドックを繋いだままでしたが、マルチモニタと有線 LAN は問題なく認識します。

心配してた GeForce ドライバの件は、特に邪魔する事なく、内蔵の Intel Iris Pro で表示されてます。

ただ、Nautilus や Firefox が使える事を確認した時点で、経験した事のない MacBook Pro 本体の爆熱を感じました。
これは危険！と誰もが思ってしまう程の発熱に加え、冷却ファンが心配になるくらいの爆音に堪えきれず、すぐにシャットダウンしました。

....

その後、USB-HDD を元の PC に戻しても、変わりなく使用できてます。
それぞれに影響がない事を確認できて良かったです。

単なる好奇心で試した USB-HDD からの Ubuntu 起動ですが、まずは成功です。
常用するにはドライバの追加や調整が必要ですが、今回はここまで。

APFS 関連のメッセージと爆熱の件をクリアすれば、もう少し使う気になれるかなー

クラムシェルで常用したらファン音が静かで快適

Mac

MacBook Pro (Mid 2014) の内蔵 SSD を JetDrive 825 に換装してから、ずっとクラムシェルモードで利用してます。
元々は JetDrive の発熱と排熱が心配で始めたのですが、とても快適です。

....

実は SSD 換装前から排熱ファンの騒音に悩まされてました。
Firefox や Chrome でネットを彷徨ってるだけで、徐々にファンの音がうるさくなり、あっというまにフル回転になってしまいます。
画像が多く、重たく感じる Web ページを表示して、上下スクロールしまくると、その症状は顕著です。

コンパイルや動画エンコード時のように、CPU 頼みの処理なら負荷がかかるので納得できるのですが...

....

色々調査したところ、Retina での解像度の設定が影響してるみたいです。

作業スペースを確保するため、Retina の表示解像度をデフォルトから変更していますが、これが地味に本体の温度を上げてしまうようです。

本来、Retina は 4 ピクセルで 1 ピクセルを表現します。
擬似解像度を大きくして、文字を小さくすると、縮小による演算が発生します。

実際にアクティビティモニタを起動して「CPUの履歴」と「GPUの履歴」 を確認すると、Retina に表示している際はどちらもそこそこの負荷があります。

しかし、外部モニタにドットバイドットで表示すると、同様の作業をしてもCPU/GPU 負荷はほぼありません。

もっとも、第4世代のモバイル用 Core i7 での話なので、現行機の CPU/GPU でも同じ状態になるかは分かりません。

Retina は確かに美しいですが、標準のままだと画面上の作業スペースが狭く、文字が大きく表示されるため、私にとっては不便です。

....

以下は現在の使用環境です。

  • 本体: MacBook Pro Retina Mid 2014
  • macOS: Mojave 10.14.6
  • 利用形態: 常時クラムシェルモードにて使用。
  • 周辺機器: Bluetooth 接続、または Thunderbolt2 経由で拡張ドックに接続
  • キーボード: Apple Wireless Keyboard
  • マウス: Apple Magic Trackpad
  • 拡張ドック: CalDigit Thunderbolt Station 2 (TS2-JP-60)
  • 外部モニタ: 拡張ドック経由で RDT235WX または BenQ PD2700Q
  • ネットワーク: 本体 WiFi 無効化。拡張ドックから有線 LAN 接続
  • 配置: 排熱・放熱を考慮して、ファンなし縦置きスタンドに配置。

クラムシェルにしてるので、Retina ディスプレイの美しい画面は封印中です。
持ち出す機会もなくなったので、Mac mini か iMac にした方が良さそうな構成です。

Retina の美しさを取るか、作業スペースを取るか。
悩みましたが、作業スペースを優先することに決め、現在の構成に落ち着きました。

外部モニタにしてからは、ファンの回転音に悩まされる事は皆無です。
WQHD (miniDP接続) / FullHD (HDMI接続)どちらでも問題ないです。

ファンの騒音は、精神衛生上、非常によろしくないので、Retina を諦めて正解でした。

Thunderbolt2 接続がホットプラグに対応しているおかげで、Thunderbolt2 ケーブル1本と電源ケーブルを抜けば、直ぐに持ち出せます。

利便性も確保しつつ、快適な環境に落ち着いたと思ってます。