解き放たれしソフトウェア

GNU/LinuxなどFLOSSについて書いてみるつもり

UEFI インストールの Windows には、 MBR を書き込まないほうがよい

結論

UEFI 方式でインストールした Windows のディスクにマスターブートレコード(MBR) を書き込む*1と、高速スタートアップやハイブリッドスリープ、ハイバネーション(休止状態)の動作がおかしくなる可能性が大。 例えば GRUBMBR に書き込む*2とおかしくなります。

原因

  • Windows は、UEFI インストールの場合でも、有効な MBR があればMBRから起動しようとします
  • 初回起動(クリーンブート)では、メインボード(M/B)上のファームウェアは、EFI システムパーティション(ESP)内のブートイメージを起動するので支障は起こりません
  • 他方で、高速スタートアップやハイブリッドスリープによる電源断、ハイバネーションの場合には、M/B の ACPI 電源管理機能を利用して休止・復帰を行うため、ESP からのブートと異なる挙動をとることが少なくありません(その方が復帰が早い)
  • よって、休止からの復帰の場合だけ、有効な MBR を読み込んで復帰しようとしてしまい、MBRブートローダが始動。正常な復帰がなされなくなります
  • そこで例えば GRUB をインストールしていたら、 GRUB の画面が出てきてしまいます。GRUB の設定に GNU/Linux ディストリビューションの起動項目1つのみしかないと、問答無用で GNU/Linux が起動されるかもしれません

以下、訥々と話が長いです

MBR 方式って何?

OS を起動する際に、M/B の ファームウェアBIOS)は、OS を直接起動するわけではありません(そもそも、どこに OS があるかを検知不可能です)。 そこで、接続されているディスクの先頭に実行可能バイナリ(ブートローダ)を書き込んでおき、M/B はそのバイナリを探して実行します。

MBR ではなく UEFI (旧称・ EFI) にするメリット

  • MBR はディスクの先頭と決まっていますから、マルウェアの格好の目標です。
  • MBR は1つのディスクに一箇所しかないので、同じディスクに複数の OS をインストールする場合には、 MBR の取り合いが発生しやすいです(特に Windowsプロプライエタリなのでしょっちゅう奪おうとする)。UEFI では、専用のパーティションEFI システムパーティション)にブートイメージを保存しますので、複数のブートイメージの共存が可能です。UEFI 対応 M/B では、ブートイメージを選んで起動させます。

GPT 方式

従来は原則として、一つのディスク上には基本(プライマリ)パーティションと拡張パーティションをあわせて4つしかつくれませんでした。5つ以上のパーティションをつくりたいのなら、拡張パーティション内に論理パーティションをつくります。

従来は、 2 テラバイト(TiB)を超えるディスク領域を扱えませんでした。

Intel は、64 bitアーキテクチャ(IA64)をつくった際に、こうした制約にはとても困ったので(ハイスペックなマシン能力が活用しえない)、 EFI と GPT への移行を提唱しました。

MBR と GPT との関係

原則としては、 MBR・非GPTか、UEFI・GPTかの二者択一です。 Windows でもこの二者択一でしかインストール不可能で、WindowsMBR・非GPT か UEFI・GPTかのどちらかだと決め打ちしています

GPT のディスクでは、"Protective MBR" 方式が導入されます。ディスクを GPT 非対応の M/B に接続した際には、最初の4つまでのパーティションが有効なパーティションとして見えます。MBR にはブートローダを入れず、いわば、ダミーになります。

よって、UEFI・GPT方式で Windows を正常にインストールしている状況では、Protective MBR でしかありええず、 MBR にはブートローダが入っていません

しかし、GPT ディスクに 使える MBRを書き込むことは理論的には可能です。例えば、GPT ディスクの MBR 領域に GRUB をインストールすることは可能です。 GNU/Linux では、UEFIMBR の両方にブートローダが入っていても、 UEFI からブートしますので、差し支えありません。

Windows は、MBR に有効なブートローダが入っていると、そこからブートしようとします

さて、初回起動時(クリーンブート時)には、マシンの制御権は M/B のファームウェアに一身専属ですから、 ESP から正常にブートします。 しかし、休止状態からの復帰は、通常の電源オンではなくて、ACPI による電源管理により中断しています。まるでサスペンドの電源切れた版のような挙動をする(した方がよい)ため、クリーンブートと異なるスタートアップが起こります。 このとき、 Windows は、MBR を読み出すようです。(ただし、M/B によってはもしかすると、そうならないこともあるかもしれません。)

UEFI ではない 旧来の MBR オンリーで Windows でマルチブートだったら?

  • どの OS も MBRブートローダから起動させるしかありません。つまり、どの OS も MBR 方式でインストールするはずです。だから、ブートローダの設定でマルチブートにしますよね?
  • そこで例えば GRUB をインストールしていたら、もしも復帰時に GRUB の画面が出てきたら、 Windows を選んでブートすればよいでしょう

この旧来の MBR 方式のマルチブート環境の場合は、ことあるごとに WindowsMBR を書き換えようとするので、また別の支障があります。Windows Update などで MBR を書き換えるようなパッチの適用がされると、MBR が上書きされて GRUB 消えます

だから従前は、そもそも Windows をインストールしたディスクに他の OS をインストールしないのが最善策でした。

しかし、このブートレコード取り合い問題は、 UEFIに移行すれば解消します。

結局、どうすればいいの?

すべての OS を UEFI・GPT 方式でインストールしてください。 ESP にそれぞれのブートローダをインストールして、M/B のファームウェアの設定で起動対象を選びましょう。

ハイブリッド MBR は、ディスクを UEFI 非対応マシンにつなぎ替える可能性があるときには便利ですが、 GNU/Linux しかインストールしていないようなディスクの場合のみにとどめるべきです。 Windows にハイブリッド MBR を使うには、かなりの戦略が必要です。

http://www.rodsbooks.com/gdisk/hybrid.html の “OSes' Reactions to Hybrid MBRs” の Windows の項目にも、Windows のデフォルトの起動が MBR であることが書いてあります。ハイブリッド MBR ではかなり厄介なのがわかります。

もしも Windows のディスクの MBRGRUB を書き込んでしまったら?

Protective MBR を再度書き込み直します。 おそらく、 GPT fdisk を用いれば可能です。

“x extra functionality (experts only)” → “n create a new protective MBR

参考: http://www.rodsbooks.com/gdisk/walkthrough.html

*1:ハイブリッド MBR

*2:例えば grub-install –target=i386-pc する

GNU/Linux で使えるバックアップ用ソフトウェア

昨日から今日の昼頃まで季節外れの気温で、「もう春本番?!」と思うくらいだった不気味な天気でした。 近年は気候が異常なのが顕著で、対応と抑制が喫緊の死活問題だなと思います。

精密機器は温度と湿度が重要で、HDDは温度が高すぎても低すぎても壊れやすいようですし、SSDは湿度に弱いそうです。

私もHDDの故障には何度も遭遇しています。 異音で事前に察知したこともありますし、S.M.A.R.T. で気がついたこともあります。ちなみに、 S.M.A.R.T. の調査には smartmontoolsが便利です。 しかし、制御回路上の半導体の急死で事前に察知し得なかったこともあります(昔の、富士通の 5400 rpm のやつとか……)。

HDDは扱い方次第で5年も10年も保つ可能性がありますが、SSDは使い続けていると書換耐性が落ちて確実に使えなくなります。

いずれにせよ、バックアップは重要です。消えたら原状回復不可能なものはバックアップすることです。 GNU/Linuxでは /etc/homeのバックアップが挙げられますが、Gentoo だと /var/lib/portage/world のほかに /var/db/pkg のバックアップも挙げられます。

バックアップの方法

さて、バックアップの方法の問題です。

ディスクイメージごと

例えば、パーティションのイメージごとバックアップをするという方法もあります。 しかし、不必要なものまで入るのでサイズが巨大になります。 参考: ArchWiki

rsync

rsync を使うとディレクトリをまるごとコピー可能なので構造的に簡単で、変更されたファイルだけを同期させられます。 しかし、 rsync 自体には、一つのファイルにまとめたり圧縮したりする機能がありません。 参考: ArchWiki

自力

手作業で、 tar でアーカイブし(一つのファイルにまとめ)たり、gzip などで圧縮したりすることがあります。 圧縮形式は、gzipGNU のスタンダードですが、 lzip がバックアップに向いていると思われ、plzipを使えば並列処理が可能なのでマルチコアCPUなどでは速くなります。

ここで「バックアップ用に向いている」と言ったのは、万が一にもバックアップファイルが壊れた場合にも復原可能性があるということです。 圧縮率だけをみれば xz が高く、圧縮速度では lz4 が速いです。xz は圧縮率が高いので、 Linux カーネルソースコードの配布にも用いられています。

しかしともあれ、手作業だと大変です。しかも、変更された部分を検知して追加バックアップをする(インクリメンタルバックアップ)というのが困難です。

バックアップ専用ソフトウェア

そこで、アーカイブや圧縮に対応したバックアップ用ソフトウェアを使うと容易になります。

また、バックアップ先をどこに保存するかということが問題です。

手元のHDDやBD-Rにでもバックアップするのなら物理セキュリティの話ですが、災害に非常に脆弱だという欠点があります。紛失しても大変ですが、火災などで破損したら全滅です。

インターネット上の、Dropbox とか MEGA とか Amazon Web Service S3 とか Google Cloud Storage とか、さくらのレンタルサーバ スタンダードプランで scp とか、もしかすると マイクロソフト OneDrive とか Azureという人も居るかもしれず頭の痛いところです。 転送は TLS で暗号化されても、バックアップ先のサービスに全幅の信頼を置くのか、そもそもパスワードとか秘密鍵とかそのまま保存してはいけません。

いずれにせよ、暗号化は重要です。

つまり、インクリメンタルバックアップ対応で、圧縮と暗号化が可能なバックアップソフトウェアが良いということがいえます。 それを見つけるのに ArchWikiには、便利な表があります。

また、バックアップしたけど必要なときになって戻せるのか、想像してみますと、ちゃんとメンテナンスが活発に続いているソフトウェアでないといけません。

そこで私がここで採り上げるのは、duplicityBorgBackup です。 いずれも、圧縮対応、暗号化対応、メンテナンスが現在も活発です。

duplicity

duplicity は、圧縮は gzip 、暗号化は GnuPG です。つまり、tar/gz/gpg の3つを通したファイルが出力されます。 この特徴は利点でもあり欠点でもあります。 gzipGNU の標準的な圧縮ソフトウェアです。しかし圧縮率はそう高くありません。取り立てて速いわけでもありません。 GnuPG は、公開鍵暗号方式で、強力だと一般的にはいえます。しかし、利用可能にするまでの設定作業が別途に必要です。また、秘密鍵の保管が必要で、盗まれないように取扱注意でもあります。

Dupulicity の強みは、多くのオンラインストレージに対応していることDUPLICITY(1) manual page

それと、GUI フロントエンドもつくられています。(あまりおすすめはしませんが)

BorgBackup

BorgBackup、簡単には「Borg」ですが、

Borg の特徴は、リポジトリを作成してそこに追加していくところです。そのため、複雑で習得するまで苦労すると思います。 また、ローカルに保存するか、SSH で転送するかの2つにしか対応していません。他のオンラインストレージには対応していません(自力でアップロードすればいいのですが、手間省けてませんし)。

もうひとつ、重大な特徴は、保存先のシステムにも Borg をインストールすること(サーバ・クライアント方式)。 それが不可能な場合には、sshfs でマウントしてローカルのファイルシステムのように扱うという代替策が提案されています。 Borg - Quick Start - Remote repositories この点を考えると、さくらのレンタルサーバSSHログインを利用してバックアップするのにも難ありかもしれません。(「さくらのVPS 1G」(HDD 100GB)にでもすればいいんですが…)

結論

オンラインストレージを活用するなら duplicity。Google Cloud Storage とか AWS S3 とか Dropbox とか等々使えます しかし圧縮が gzip しかない。暗号化が GnuPG なのは利点にも欠点にもなります

Borg は、圧縮率重視にも、圧縮速度重視にも設定可能。共通鍵方式なので扱いやすい。しかしリモート保存が SSH のみ。リポジトリ式は便利だが、習得までに苦労が要ります

理想と現実とそのあいだ

またこの件ですが

mag.osdn.jp


FSFは、トランスジェンダーを雇うには拙速だったのだと思います。

さまざまな人種、民族、信仰、ジェンダー等々を雇うには、職場や経営者や従業員が固定観念を払拭して、態勢を調えねばなりません。

2016年には outreach をキーに据えた FSF でした。 しかし、公益財団としての限られた予算のなかでは、研修など態勢を調えて、組織効率の面では不利である異質な人とやっていくには、コストが過大であり、直ぐには成し得なかったのでしょう。 直ぐには成し得ないことだったのに、安易に「成し得る」と判断して雇い始めたのだとすれば、自己洞察の足りない思い上がりがあったのだと言わざるをえません。 彼らは理想を見るのは得意ですが、自分を実際よりもより理想的な者だと思いこんでいる(現実認識や自己洞察が足りていない)フシは、FSFにせよRMSにせよ、あるのではないでしょうか。

職場の態勢が醸成されていなかったから、辞めてもらうしかなかったのでしょう。 拙速で、迷惑をかけています。

外部のプロジェクトへの支援を増やすとか、インターンを受け入れるとか、なんらかのイベントを開催するとか、やりかたはあったはずなんですよね。 また、RMS含め職員達自身が研修を受けるとか。 例えばトランスジェンダーにしてもその当事者団体ってありますから、そういうところに教えを仰げるはずなんですよね。


しかし、Libreboot の Rowe 氏の方は、感情的で、戦略性も足りず、事態をわざわざ荒らしているというほかありません。

Rowe 氏自身がトランスジェンダー女性で、この事態がトラウマに触れるものだったのでしょうし、トランスジェンダーの味方にならねばならず、社会正義に燃えるところもあるのでしょう。

しかし、拙いです。拙くなる最大の原因は、トラウマに触れたからでしょう。

世の中には、共感能力や想像力のない人々の方がむしろ多いですから、今回の Rowe 氏のような行動は、かえって誹謗中傷にすら拡大します。 最近の流行語でいえば「ノイジーマイノリティ」とか言われてしまうわけです。

例えば

cpplover.blogspot.jp

のような反応があるわけですが、今回の件は「些細な言動の揚げ足取り行動」では済まないものだと私は思います。

そもそも、特定の団体に属する一部の人間が差別主義者であったとして、その団体全体が差別主義であると主張するのは、LGBTの一部の人間の問題を取り上げてLGBT全体が問題であるとするLGBTフォビアと何ら変わりない行動である。

というのは今回の件には当たらない批判でしょう。(また、トランスジェンダーの話をしているのに十把一絡げに"LGBT"という語彙で済ますのも不適切です。)

なぜならば、FSFには雇った以上は職員に対して責務があるからで、当該職員に対して合わせていかないといけないからです。 社会的に不利な立場の人(いわゆるマイノリティ)を優遇して公平にしようとするならば、不利な立場の人に対して有利になるように合わせないと釣り合わないからです(アファーマティヴ・アクション)。

あえてダイヴァーシティを実現するには、例えば女性エンジニアを雇うには母数が少ないので能力的に不利だったり、例えば障がいをもつ人を雇うと業務効率が低下したり、ムスリムを雇うと礼拝の時間と場を用意しないといけなくなったり、母語の異なる人を雇うとコミュニケーションに苦労したり、しますそうしたコストをあえて甘受せねばなりません周囲の上司や同僚の方が、合わせる努力をしていかねばなりません。 結果第一主義や、効率優先主義では、不可能です。

さらに言えば、ほとんどの企業では、アルコール禁止の人は職場のパーティに出るのは困難になり(たとえ出られたとしても苦痛と苦労が多いし)、ムスリムは豚肉食べられないので同様で、ユダヤは肉は血抜きし祈祷していないとダメだし。外食も、コンビニのパンや弁当や惣菜すらも、障壁が設けられています。実にそういう基礎的な部分からもう、社会には欠けているんです。

ちなみに、「全ての人のため」「みんなの」という言説は往々にして、社会的に有利な立場を既に得ていて、しかも恵まれていることに自覚のない、いわゆるマジョリティの、自己正当化の論理として振りかざされます。 それでは差別なんて無くなりません。

例えば、「みんなのためにトランスジェンダーは辛抱しろ」という主張が平然と出てくるでしょう。それはトランスジェンダーに限らず、例えば女性に対してであれ、ムスリムに対してであれ、母語の異なる人に対してであれ、出てきます。 そうして、女性プログラマの育たない社会が維持されますし、ムスリムが事実上就職困難な社会が日本では維持されますし、英語が流暢でない人は欧米では就職難になるでしょう。 アメリカでさえ、黒人と白人の混血の人がようやく大統領になれたくらいでしかなく、女性大統領がいません。 日本の政治家に女性が少ないのも、能力がどうたらとかなんだかんだと理屈をつけて正当化されるのでしょう。


さてしかし、他方の Rowe 氏の言動が、戦略的な冷静さが無く、過激で、公私混同が酷いのもたしかです。

雇用主である FSF と、その代表者に対して、批判を向けるべきなのに、加害者とされる上司の実名を出したのも不適当でしょう。

また、公開の場で告発をしたのも拙速です。 早すぎるし、証拠を調えるよりさきに公表してしまい、証拠は後づけみたいになっています。

そして、 Libreboot のプロジェクトを盾にして抗議したのも不適切です。 Rowe 氏は、 Libreboot のデヴェロッパから降りて、Libreboot からフォークして別のプロジェクトを始めればよかったのです。 自分一人しか居ないプロジェクトならば、そのウェブサイトででもなんででも、プロジェクトの総意としてなんとでも主張可能でしょう。 それに言うまでもなく、 GNUFSF からは外れられます。

Rowe 氏は、トラウマに触れられたからでしょうが、やっていることも言っていることも、とっちらかっています。 FSFにしてきた寄附の金額がどうとか(さらにはカネ返せとか)にしてもそうでしょう。

ダイヴァーシティを未だ確立し得ない FSF にも難はあります。しかし、 FSF の事業はフリーソフトウェア運動であって、ダイヴァーシティもその一環のひとつに過ぎません。

Rowe 氏がやっている言動それ自体は、実に、ダメダメだと思います。 ただ、Rowe 氏が暴走してしまうのは、それだけのトラウマに触れられたのでしょうし、それだけ、怖いからなんでしょう。

世の中を直すには、理想(目標)の設定だけでは足りません。的確な現状認識をしたうえで、現状から理想へどのようにアプローチするか(経路設定)ということが必要です。 その点では、RMSFSFも、Rowe 氏も、正しい理想をぶち上げてはいるのでしょうけれど、現状認識や経路設定で、どこか抜けていると思うんですよね。