Ubuntu 16.04のVagrantでpublic Vagrant boxにアクセスできなくなった問題
本日、普段使っているpublic Vagrant boxに対してvagrant box add
を実行したところ、404 not foundになってしまいました。
$ vagrant --version Vagrant 1.8.1 $ vagrant box add --provider libvirt elastic/ubuntu-16.04-x86_64 The box 'elastic/ubuntu-16.04-x86_64' could not be found or could not be accessed in the remote catalog. If this is a private box on HashiCorp's Atlas, please verify you're logged in via `vagrant login`. Also, please double-check the name. The expanded URL and error message are shown below: URL: ["https://atlas.hashicorp.com/elastic/ubuntu-16.04-x86_64"] Error: The requested URL returned error: 404 Not Found $
比較的マイナーなboxだったので、作者が提供を辞めてしまったのかなと思ったものの、ちゃんとサイトはありました。
Vagrant box elastic/ubuntu-16.04-x86_64 - Vagrant Cloud
もっとメジャーなUbuntu公式イメージをaddしようとしても同じ問題が発生しました。
$ vagrant box add --provider libvirt ubuntu/trusty64 The box 'ubuntu/trusty64' could not be found or could not be accessed in the remote catalog. If this is a private box on HashiCorp's Atlas, please verify you're logged in via `vagrant login`. Also, please double-check the name. The expanded URL and error message are shown below: URL: ["https://atlas.hashicorp.com/ubuntu/trusty64"] Error: The requested URL returned error: 404 Not Found $
先月同じコマンドを実行したときには動いていたはずなので、なんかおかしいなあと思って色々調べていたら、Vagrantのgithubに、つい二日前に登録された怪しいissueを見つけました。
vagrant box update - Fails with 404 Not Found error · Issue #9442 · hashicorp/vagrant · GitHub
issueはvagrant box update
に関するものでしたが、わたしのケースとすごく似ています。斜め読みしたところ、問題はpublic Vagrant BoxのURLとしてatlas.hashicorp.com
を受け付けなくなって、vagrantcloud.com
を指定しなくてはならなくなった、ということのようです。どうやら、すくなくともUbuntu16.04は全部影響を受けるらしい。
issueの中に、次のようなworkarundを見つけたので、試してみることにしました。
vagrant box update - Fails with 404 Not Found error · Issue #9442 · hashicorp/vagrant · GitHub
とりあえず、自分の環境でこれと同じ問題が出るか、および、workaroundを使って問題が解決するかを確かめました。Vagrantfileの変更が必要なので、とりあえずは当該ファイルを使わないvagrant box add
ではなく、`vagrant initを使いました。
- workaround適用前
$ vagrant init elastic/ubuntu-16.04-x86_64 $ vagrant up --provider=libvirt Bringing machine 'default' up with 'libvirt' provider... ==> default: Box 'elastic/ubuntu-16.04-x86_64' could not be found. Attempting to find and install... default: Box Provider: libvirt default: Box Version: >= 0 The box 'elastic/ubuntu-16.04-x86_64' could not be found or could not be accessed in the remote catalog. If this is a private box on HashiCorp's Atlas, please verify you're logged in via `vagrant login`. Also, please double-check the name. The expanded URL and error message are shown below: URL: ["https://atlas.hashicorp.com/elastic/ubuntu-16.04-x86_64"] Error: The requested URL returned error: 404 Not Found $
期待通り(?)失敗しました。
- workaround適用後(initの後にVagrantfileを編集)
$ vagrant up --provider=libvirt Bringing machine 'default' up with 'libvirt' provider... ==> default: Box 'elastic/ubuntu-16.04-x86_64' could not be found. Attempting to find and install... default: Box Provider: libvirt default: Box Version: >= 0 ==> default: Loading metadata for box 'elastic/ubuntu-16.04-x86_64' default: URL: https://vagrantcloud.com/elastic/ubuntu-16.04-x86_64 ==> default: Adding box 'elastic/ubuntu-16.04-x86_64' (v20171130.0.0) for provider: libvirt default: Downloading: https://vagrantcloud.com/elastic/boxes/ubuntu-16.04-x86_64/versions/20171130.0.0/providers/libvirt.box ... $
成功しました。続いて、上記コマンドの実行結果から得たboxファイルをもとにvagrant box add
が成功するかを試しました。
$ vagrant box add elastic/ubuntu-16.04-x86_64 https://vagrantcloud.com/elastic/boxes/ubuntu-16.04-x86_64/versions/201711 30.0.0/providers/libvirt.box ==> box: Box file was not detected as metadata. Adding it directly... ==> box: Adding box 'elastic/ubuntu-16.04-x86_64' (v0) for provider: box: Downloading: https://vagrantcloud.com/elastic/boxes/ubuntu-16.04-x86_64/versions/20171130.0.0/providers/libvirt.box ... $
こちらも成功しました。私が遭遇した問題は上記issueと同根と見てよさそうです。
ここから最終的にはvagrant box add --provider libvirt elastic/ubuntu-16.04-x86_64
を正しく動くようにしたいのですが、上記の方法が今のわたしにとってはworkaroundとして十分なので、とりあえずはこれで放置。後はUbuntuで修正されるのを待ちます。
防水音楽プレイヤーを買った
スポーツクラブで使う防水音楽プレイヤーを探していたところ、友人に教えてもらったウォークマンを買いました。
欲しかった理由は運動、とくにプールにおいて飽きるのを防ぎたかったこと、および、スタジオの音や人の話し声を遮断することです。今のところ、その目的は見事に果たせています。素晴らしいです。買ったのは去年なのですが、去年で一番良い買い物だったと思います。
もともとはスポーツクラブでのみ使う予定だったのですが、今では、どこでもこれしか使わなくなってしまいました。一番大きな理由は、これまではイヤホンとプレイヤー本体を別々に用意しなくてはいけなかったのが、これだと小型軽量な一台で2つの役割を果たしてくれることです。それに加えて外出中ずっと使っていられるほどバッテリの持ちが良いこと、および、BTじゃないので音楽プレイヤーとしてのスマホのバッテリを消費しないことも評価できます。
改めて、買ってよかった。
Ryzenを積んだマシンで発生した新たな問題とその解決
Ryzenを積んだマシンでgccのビルド負荷をかけるとランダムにSIGSEGVが発生して失敗するという問題に去年ハマりました。これについては問題ない石に取り替えてもらって、解決しました。
satoru-takeuchi.hatenablog.com
ところがその後、マシンが2,3日に一度ハングするという事象が新たに発生して、悩まされておりました。不思議なことに、この事象はSEGVが発生していた石では起きていませんでした。
実はこの事象は上記の記事においては言及していなかったのですが、そこかしこで似たような報告がされていました。報告されている対策はいろいろあって、詳細は下記meihongさんの調査結果が詳しいです。
私の場合は、ここで紹介されていたスクリプトを使ってC6 stateをdisableにしたところ、問題が発生しなくなりました。カーネルのRCUの設定は変更していません。
これについてはハードウェアが悪いのかLinuxが悪いのか全然わかりませんが、あまり気にしないことにします。理由は次の通り。
- 大きな影響なしに回避できる
- SEGV現象に比べると調査しづらい。発生確率が低い上に発生するとマシンがハングする
- 去年ほど時間に余裕が無いし、もう疲れた
色々とトラブルが耐えない石ですが*1、安価でビルドが速いので、これからも数年は頑張ってもらう予定です。
*1:また、今回発生した問題においては犯人が全く不明ですが
リモートマシンのルートファイルシステムをぶっ飛ばした話
はじめに
表題の通り、新年早々やらかしました。備忘録として、あるいは、もしかして誰かの役に立つかもしれないので、事象発生から復旧までの流れをまとめたものを簡単に書いておきます。
1/4 朝: 移動
締め切りが非常に厳しい仕事をかかえる中、自宅から300kmほど離れた場所に移動。作業用マシンにはリモートアクセスできるので仕事には支障なし。の、はずだった。
1/4 夕方: 破壊
目的地に着いて、もろもろ落ち着いたので仕事を開始。テスト用のパーティションに書き込みをする簡単なプログラムを動かしていた。ここでタイプミスしてルートファイルシステムの先頭1GBくらいにランダムなデータを書いてしまうことにより、ぶっ飛ばした。即死はしなかったが、dmesgを見ると案の定カーネル(の中のファイルシステム)のバックトレースが出た上で、ルートファイルシステムが読み出し専用マウントされていた。
余談だが、ここでパーティションをopen()する際にO_EXCLを指定しておけば、マウント中のルートファイルシステムはEBUSYで開けないため、問題は発生していなかった。しかし、わずかな手間を惜しみ、ここをサボった*1。馬鹿じゃないの。
以下、man 2 openより抜粋。
In general, the behavior of O_EXCL is undefined if it is used without O_CREAT. There is one exception: on Linux 2.6 and later, O_EXCL can be used without O_CREAT if pathname refers to a block device. If the block device is in use by the system (e.g., mounted), open() fails with the error EBUSY.
1/4 夕方: リモート復旧の準備
このリモートマシンをなんとかデータを復旧した上で運用継続するにはどうすればいいか、頭をひねった。リモートマシンなのでリブートできないという制約が、なかなかに辛い。
いろいろ考えた末、次のような案を思いついた。
- 空いているパーティションに、作業用のルートファイルシステムを作る
- 1で作ったファイルシステムにchroot
- 破壊されたファイルシステムをumount
- 破壊されたファイルシステムのデータを可能な限りサルベージ*2
- 破壊されたファイルシステム上に、新たなルートファイルシステムを作る
- 5で作ったファイルシステムにchroot
- 定期バックアップデータからルートファイルシステムを復旧
- 死亡直前まで更新していたデータを、4でサルベージしたデータを用いて、出来る限り復旧
1と3のルートファイルシステム作成については次の2つの方法が考えられた。
- debootstrap
- Ubuntu Cloud Imagesからインストール済イメージを持ってきてddでフルコピー
友人たちと相談した結果、aを選択することにした。
どのデータが壊れているかわからないので、いつ死ぬかわからない運試しの作業だが、やるしかない。
1/4 夜: リモート復旧
作業開始。debootstrap起動時に
# deboo
とタイプした後にtabで補完しようとした段階で接続が切れる。即死。多分bash-completionに関するファイルを読もうとしてI/Oエラーによって死んだ。
もうやることがないので、ふて寝。
1/5 朝: 敗走
遠隔地で時間を空費するのはまずいので、自宅に敗走。1週間以上滞在するはずだったのだが、まさかの一日でとんぼ返り。人生は厳しい。
1/5 昼: ローカル復旧
バックアップのあるローカル復旧は、めんどくさいけど、言ってしまえば「やるだけ」。次のような手順で復旧。
- USBメモリにUbuntuインストーラを焼く
- 1で作ったものをlive USBメモリとして使って、起動
- 壊れたルートファイルシステムからデータをサルベージ
- Ubuntuをクリーンインストール
- バックアップデータを新ルートファイルシステムにコピー
- 死亡直前まで更新していたデータを、3でサルベージしたデータから出来る限り復旧
これは、とくに何事もなく成功した。直前まで更新していたソースコードや文書はうまくサルベージできたので、時間と金を浪費した以外に大した実害はなかった。不幸中の幸い。
おわりに
- フェイルセーフ大事
- 二度とやりたくない
- IPMI搭載マシンほしい
Windows10 Fall Creators Update適用後にちょっとした不具合に遭遇
mdadmのヤバそうなバグのCentOSにおける修正状況
はじめに
Ubuntu 16.04のmdadmには、所定の条件を満たすとユーザのデータをぶっ壊すという恐ろしいバグがあります。具体的には次の記事の"バグ1"のことです。
Ubuntuについては一応回避策もありますし、そのうち修正されるでしょうが、「そういえばこれ、CentOSではどうなってるんだろう」と気になったので、CentOS 6.9と7.4についてこのバグの有無を調べてみました。
調査結果
注意: これと同じことがCentOSのクローン元のRHELに当てはまるかどうかは知りません。気になる人はご自身で確認した上で対処してください。間違ってもRed Hat社に「このブログにCentOS 6.9のmdadmに問題があると書いてたからRHELのmdadmを直して」などと言わないようにしてください。Red Hat社にとってはCentOSにバグがあろうとなかろうと「知らんがな」なので。
調査ログ
このバグが存在するかどうかは実機確認すれば一発でわかるのですが、せっかくなのでソースからバグの有無を調査する手順を載っけときます。
CentOS 6.9
まずはソースパッケージのバージョンを次のサイトから調べました。
Index of /6.9/os/Source/SPackages
その中で次の行が見つかりました。
mdadm-3.3.4-8.el6.src.rpm
続いてこのソースrpmをダウンロード&インストールしてソース調査しました。このパッケージの元になっているのはファイル名からわかる通り、upstreamのバージョン3.3.4です。このバージョンは、この問題の修正がまだ適用されていないものです。
さて、これでアウトかと言うと違います。なぜかというと、CentOSなどのディストリビュータが提供するパッケージはupstreamのものにdistro固有のパッチがいくつか当たっていることがあり、それらパッチによって修正されている可能性があるからです。
mdadmのspecファイルを見ると、いくつか独自パッチが当たっていることがわかりました。
... Patch1: mdadm-3.3.4-imsm-don-t-call-abort_reshape-in-imsm_manage_reshape.patch Patch2: mdadm-3.3.4-Grow-close-file-descriptor-earlier-to-avoid-still-in.patch Patch3: mdadm-3.3.4-imsm-abort-reshape-if-sync_action-is-not-reshape.patch Patch4: mdadm-3.3.4-imsm-use-timeout-when-waiting-for-reshape-progress.patch Patch5: mdadm-3.3.4-imsm-don-t-update-migration-record-when-reshape-is-i.patch Patch6: mdadm-3.3.4-Grow-Add-documentation-to-abort_reshape-for-suspend_.patch Patch7: mdadm-3.3.4-super-intel-ensure-suspended-region-is-removed-when-.patch Patch8: mdadm-3.3.4-Grow-close-fd-earlier-to-avoid-cannot-get-excl-acces.patch Patch9: mdadm-3.3.4-Introduce-stat2kname-and-fd2kname.patch Patch10: mdadm-3.3.4-IMSM-retry-reading-sync_completed-during-reshape.patch Patch11: mdadm-3.3.4-The-sys_name-array-in-the-mdinfo-structure-is-20-byt.patch Patch12: mdadm-3.3.4-imsm-add-handling-of-sync_action-is-equal-to-idle.patch Patch13: mdadm-3.3.4-imsm-properly-handle-values-of-sync_completed.patch Patch14: mdadm-3.3.4-Incremental-don-t-try-to-load_container-for-a-subarr.patch Patch15: mdadm-3.3.4-Allow-level-migration-only-for-single-array-containe.patch Patch16: mdadm-3.3.4-imsm-set-generation-number-when-reading-superblock.patch Patch97: mdadm-3.3.2-disable-ddf.patch Patch98: mdadm-3.3.2-udev.patch Patch99: mdadm-3.3-makefile.patch ...
これらのパッチを全部当てた状態のソースを調査しても、バグは修正されていないことがわかりました。つまり、CentOS 6.9は結局アウト。
CentOS 7.4
6.9の場合と同様に、まずはソースパッケージのバージョンを確認しました。
Index of /7.4.1708/os/Source/SPackages
その結果、次のバージョンを使用していることがわかりました。
mdadm-4.0-5.el7.src.rpm
次はこのソースパッケージの調査です。ダウンロード&インストールすると、upstreamのmdadm 4.0がベースとなっていることがわかりました。このバージョンは、バグが修正されているものです。では、これでセーフ確定かというとそうではありません。CentOS固有パッチによってregressionを起こして、またバグが復活している可能性がわずかに残っています。このため、全パッチを適用した上でソース確認しました。確認の結果は問題なかったので、7.4はセーフ。
WSL on Windows 10 Fall Creators Updateの第一印象
Windows10をFall Creators Updateにバージョンアップしてみました。これに伴い、WSLが開発者用のツールではなく、公式アプリとしてMicrosoft Storeから手に入れられるようになりました。さらに、distributionがUbuntuだけでなくopenSUSE, SLESも選べるようになりました。
新版の変更点は次のページにまとまっています。
What’s new in WSL in Windows 10 Fall Creators Update – Windows Command Line Tools For Developers
過去のUbuntu on Windows、および今回追加された3つのディストリビューションアプリごとにデータを独立して持っているので、次のような手順で過去のものから新しいUbuntuにデータを移行しました。
What’s new in WSL in Windows 10 Fall Creators Update – Windows Command Line Tools For Developers
その他、ファイルシステムは過去のものとは異なるどこかに隠されているとMSの人は言っていますが…
What’s new in WSL in Windows 10 Fall Creators Update – Windows Command Line Tools For Developers
実際には<ユーザディレクトリ>/AppData/Local/Packages/<distro用ディレクトリ>/LocalState/rootfs/にあるとわかりました。findで検索したらすぐ見つかりました。
以前次の記事において取り扱った各種性能については、これから計測します。
Windows Subsystem for Linuxとguest/native Ubuntuの性能をざっくりと比較 - Qiita
次のイベントで結果を発表する予定です、乞うご期待。