Monthly Archives: 2月 2018

J計画 12月

J計画の次なるステップに進むためにジンちゃんのお泊まりセットを

床の間に飾りました(どうせ床の間なんて使ってないし他に適当な

収納場所がなかった)

目指すは、

車内を空っぽにすること。簡単そーに見えません?でも……

まずは、運転席と助手席を取り外しました。

右側が運転席、左側が助手席です。それぞれ、4本のボルトで

留まっているだけなので、甘く見てました。固定するための

8本のボルトすべてにカバーがついてます。このカバーが

固いので無理に力を加えたら8個のうち2個を破損させてしまい

ました。

正常なものは、↑↑↑ のような形状をしてますが、

青色円のところには、正常なものと同様の白いクリップが

セットされますが、ハズした状態です。

オレンジの円内の台座から、赤色の楕円内の棒状部分が

ポキンと折れてしまいました。

そんなに高い部品ではないはずなので購入してもいいのですが、

この棒状部分はガイドの役割しかしてないので修理しました。

強力なエポキシ系の接着剤を使用しました。二液タイプなので

工具箱の奥に長年しまっておいたものなのに使用できるところが

良いところ。おまけに、A液はコニシのもの、B液はセメダインの

ものなのに、ちゃんと使えたんですからスゴイ!B液なんて、

おそらく30年モノくらいだと思います。A液は15年モノ?

↑↑↑ ちゃんと直りました(ピンボケごめんなさい)。

他にも、クリップの台座部分が割れたものもありましたが、

セメダイン・コニシ接着剤のおかげで復活しました。

とはいえ、壊れないに越したことはないので、

矢印方向へトントンとやさしく叩いてやると、安全に外れます。

座席外しのあと、Bピラーのカバーの取り外しも行いましたが

上半分のカバーを外すときにクリップの台座を割ってしまいました。

もちろん、接着剤で修復できたのですが、壊さないためには、

外し方のコツがあります。

周りがゴチャゴチャしていて、ちょっと見にくいのですが ↑↑↑ が左右の

Bピラーです。手前が下側です。まずピラーの上側を室内方向に引いて

上側のクリップを外し、上向きにずらすように持ち上げてやると下側の

クリップも外れます。そのとき、クリップは ↓↓↓ 柱側に残りますが、

クリップの受け部分が割れるよりは、相当にマシです。

インパネ系で外すのに一番苦労したのは、エアコンの吹き出し口選択と

風量調整のための二つのダイヤル式のつまみでした。手前に引っ張れば

外れる構造ですが、指でつまんで外すには、たぶん、かなりの怪力が

必要だと思います。

外すコツとしては、↓↓↓ のようにつまみ部分をマスキングテープなどで

養生してプライヤーでつまんで抜くと、あっけなく外れます。

あとは、カーペットを外すためにドアまわりの押さえやスペアタイヤ、

最後部のカバー類を外していくわけですが、

↑↑↑ んな感じのリムーバーがあれば、さほど苦労しなくても外すことが

できると思います。それと、いまさらですが、ラチェットハンドルタイプの

ソケットレンチセットは必須ですね。作業効率があがるだけではなく

ボルトの頭をなめたりしないためにも揃えましょう。ソケットは、

6角タイプよりも12角タイプのほうが使い勝手がいいと思います。

↓↓↓ が取り外したカーペットです。

取り付けに必要なクリップ類はビニール袋に入れて、くくりつけておりまする。

フロアが全部露出できて冒頭2枚目の写真状態になったのが、12月の7日。

年末の残りの日々は、床に断熱材を塗って過ごしました。

またまた、ごぶさたでした。

20日ほど前に仮復旧させたサーバーですが、いくつもの謎を

含んでおり、それらの解決に四苦八苦していた 20日間でも

ありました。

最大の謎は、論理ボリュームに対して何かをしようとすると

決まって現れる

Couldn’t find device with uuid Tmw81h-BcM1-1uZO-1kKs-oxQS-9tGk-L2RZ1D.

でした。これが現れると何にもできないのです。何にも。

この UUID の先には’/dev/vg_server90/lvol0′ [1.82 TiB] という

論理ボリュームが繋がっていました。「いました」と過去形なのは

どうにかこれを繋ごうと努力してるうちに、TestDiskの使い方を

間違えて吹っ飛ばしてしまったのです(涙)

元々、この論理ボリュームをマウントさせようとした時にも

Couldn’t find device with uuid Tmw81h-BcM1-1uZO-1kKs-oxQS-9tGk-L2RZ1D.

が、邪魔したんですっ!たぶん……

ともあれ、実体がなくなったので消すしかありません。

これがあると、LVM サイズ変更なんかもできませんから。

いろいろ、検索して試してみては、失敗してバックアップの

戻しをして、また、いろいろやって、失敗して……の繰り返し

でした。この20日間。

ところが、ついに検索し当てたのです。

Linux: LVM 論理ボリュームマネージャの情報が消えないとき

「これらのLVMに関する情報はどこに保存されているのか?
(中略)
どうやら,ディスクドライブの先頭からベタに書いてあるようです.」

このページに書いてある通りに

# dd if=/dev/random of=/dev/sda count=1024
0+1024 records in
17+1 records out
8750 bytes (8.8 kB) copied, 7800.73 seconds, 0.0 kB/s

先頭から 8750 bytes(?)を乱数で埋めました。

このあと、乱数で埋めた HDD1 に Centos6 を新規インストールして

仮復旧できてる HDD2 の sda2 を丸ごとコピーしれば、LVMに

関する情報を消去した HDD ができるはず……なのに、

間違えて HDD2 に Centos6 を新規インストールしてしまいました(涙)

泣いてても仕方がないので、元の sda2 のデータが残ってる HDD1から

HDD2 にバックアップの戻しをすることにしました。

HDD2 と HDD1のホスト名が同じだとそれぞれを

マウントさせることができないので、 HDD2 を別のホスト名で

Centos6 の新規インストールし直しました……つもりが、

あろうことか 間違って HDD1にインストールしちまっただよう(号泣)

要するに、せっかく仮復旧した HDD と、それを丸ごとコピーした

HDD の両方に Centos6 を新規インストールしてしまったということです。

泣けますよね。まあ、こういうこともあるだろうと元々の PATA の

クローンである HDD0 はとっておいたので、こうして復旧できて

いるわけですが、最初っからやり直しになりましたから堪えました。

話が横に思いっきりそれてしまいましたが、先頭を乱数で埋めた

HDD1 を仮復旧させたものと、それをコピーした HDD2 ができました。

以前なら、HDD2を繋げば、そのまま起動できていたのに read-only

なってしまいました。でも、こうなるほうが自然っていうか、

謎が少ないんですね。HDD1もHDD2も、まったく同じ fstab で

起動できるということは、

UUID=21d2512b-b978-45f3-92e6-0cc1bfe1e324 /boot ext4 defaults 1 2

の行が同じ。すなわち、HDD1の sda1 と HDD2の sda1 が

同じ UUID ってことになりますよね。それにも関わらず起動したのは

理屈はわからないんですけど HDD の先頭からベタに書き込まれた

情報が関係してたと考えるほうが……ねっ!自然でしょ?

他にも、先頭に情報が残ったままの HDD では、オンボードの NIC に

どうしてもネットワーク接続できなかったことも、おそらく

同じ理由だと思います。

# lvscan

Couldn’t find device with uuid Tmw81h-BcM1-1uZO-1kKs-oxQS-9tGk-L2RZ1D.
ACTIVE ‘/dev/vg_server90/lv_root’ [50.00 GiB] inherit
ACTIVE ‘/dev/vg_server90/lv_home’ [411.36 GiB] inherit
ACTIVE ‘/dev/vg_server90/lv_swap’ [3.91 GiB] inherit
inactive ‘/dev/vg_server90/lvol0’ [1.82 TiB] inherit

# lvremove /dev/vg_server90/lvol0

Couldn’t find device with uuid Tmw81h-BcM1-1uZO-1kKs-oxQS-9tGk-L2RZ1D.
Logical volume “lvol0” successfully removed

先頭の情報を消しても、Couldn’t find device with uuid Tmw81h-……は

出ますが、論理ボリュームを消すことはできたようです。しかし、

このエラーが出ると、どうしてもできなかったのが、物理ボリュームの

亡霊を消すことでした。しかし、

# vgreduce –removemissing vg_server90

Couldn’t find device with uuid Tmw81h-BcM1-1uZO-1kKs-oxQS-9tGk-L2RZ1D.
Wrote out consistent volume group vg_server90

と、エラーは出ても、

# pvdisplay

Couldn’t find device with uuid Tmw81h-BcM1-1uZO-1kKs-oxQS-9tGk-L2RZ1D.
— Physical volume —
PV Name /dev/sda2
VG Name vg_server90
PV Size 465.27 GiB / not usable 3.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 119109
Free PE 0
Allocated PE 119109
PV UUID 0wag5X-JPia-ydq6-130G-hoAU-FA8J-F79wGt

— Physical volume —
PV Name unknown device
VG Name vg_server90
PV Size 1.82 TiB / not usable 2.56 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 476931
Free PE 476931
Allocated PE 0
PV UUID Tmw81h-BcM1-1uZO-1kKs-oxQS-9tGk-L2RZ1D

↓↓↓

# pvdisplay

— Physical volume —
PV Name /dev/sda2
VG Name vg_server90
PV Size 465.27 GiB / not usable 3.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 119109
Free PE 0
Allocated PE 119109
PV UUID 0wag5X-JPia-ydq6-130G-hoAU-FA8J-F79wGt

あれほど悩ましかった /dev/vg_server90/lvol0 がついに消滅しました。

続いて、先頭情報があったときには、どうやってもできなかったのが

LVM サイズの変更でしたが、

# fsck.ext4 -f /dev/vg_server90/lv_home

e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vg_server90/lv_home: 39/26959872 files (0.0% non-contiguous), 1742834/107836416 blocks

# resize2fs /dev/vg_server90/lv_home 27.16G

resize2fs 1.41.12 (17-May-2010)
resize2fs: Invalid new size: 27.16G

どうやら、整数指定しないとダメみたいです。

# resize2fs /dev/vg_server90/lv_home 27G

resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/vg_server90/lv_home to 7077888 (4k) blocks.
The filesystem on /dev/vg_server90/lv_home is now 7077888 blocks long.

# lvreduce -L 27G /dev/mapper/vg_server90-lv_home

WARNING: Reducing active logical volume to 27.00 GiB.
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce vg_server90/lv_home? [y/n]: y
Size of logical volume vg_server90/lv_home changed from 411.36 GiB (105309 extents) to 27.00 GiB (6912 extents).
Logical volume lv_home successfully resized.

# lvextend -l +100%FREE /dev/mapper/vg_server90-lv_root

Size of logical volume vg_server90/lv_root changed from 50.00 GiB (12800 extents) to 434.36 GiB (111197 extents).
Logical volume lv_root successfully resized.

# resize2fs /dev/mapper/vg_server90-lv_root

resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/mapper/vg_server90-lv_root is mounted on /; on-line resizing required
old desc_blocks = 4, new_desc_blocks = 28
Performing an on-line resize of /dev/mapper/vg_server90-lv_root to 113865728 (4k) blocks.
The filesystem on /dev/mapper/vg_server90-lv_root is now 113865728 blocks long.

最後の vg_server90-lv_root のファイルシステムのサイズ変更は

40分くらいの時間がかかりました。でも、おかげで

と、このブログを格納している root の使用率が 47% だったものが

LMV のサイズを 50 GB から 434.36 GB 拡大できたために、6% に

下がりました。これで、当面は容量不足に悩まされずに済むでしょう。