誤家庭のLinuxで大規模ストレージを取り扱う

ストレージ規模がどんどん大きくなる当システム。次期再編成のためのメモである。 なお、話を一般化するために特殊な箇所は変更してあり、このまま適用できるわけではない。

前提

メインとなるホスト(Host Master A)と冗長ホスト(Host Master B)から60TBに及ぶ巨大なストレージを取り扱えるようにする。

バックアップとしてサーバー(Host Slave)を用いてデータの冗長化を行う。

基本的には無停止が可能なようにするが、HAのような完全無停止を要求するわけではない。

機材

安価に拡張可能なストレージ群を構築するには、NetGear ReadyNAS RN316が良いようだ。 これにNetGear ReadyNAS EDA500を追加することで10万円以内で筐体を用意することができる。ディスクとあわせると、20台60TBで約40万円が必要だ(2017年6月現在)。

バックアップは実際には現在はサーバーによる内蔵とAoEの組み合わせ、とするが、将来的には同様の方法をとるのが望ましいだろう。

構成

NetGearで用意したディスクを、NetGearの機能でRAID5化し(つまり有効ディスク数は18となる)、これをiSCSIで提供する。

iSCSIディスクはHost Master Anyがイニシエータとなり、これをLUKSデバイスとして暗号化/復号化し、その上にbtrfsを構築して利用する。

2台ひと組と考えることで、-m1 -d1オプションを使って無停止性を確保することができる。 だが、実際は一般の利用ではディスク故障を除いたデータが損失するファイルシステム事故は割と少ないので、-m1 -d0あるいは-m1 -dsingle構成にしたほうが良いと考えられる。 -m1 -d1とした場合、ディスク30台を使用して使える容量は9台分となる。

バックアップも基本的には同様に構築する。異なるグループのiSCSIを用意し、btrfsボリュームを作成する。

構築

接続

iSCSIによる通信でほぼネットワークはあふれることになるため、ネットワークは分離することにする。

上流側は主にはクライアントユースになる、と考えれば、上流側をUSBアダプタとすることでホストの切り替えを容易にすることが考えられる。

Host Master AをHost Masterと考えた場合、Host Master A及びHost Slaveが2つのNICを持っている状態 となる。 このとき、両者が所属するネットワーク(サブネット1)はホストネットワークであり、下流側はストレージのみを接続する、という形態にすることでiSCSIの通信を混在することを避けられる。

Host Master Bを使用する場合はHost Master AからUSB NICを取り外し、Host Master Aに接続されていたUSB NICにHost Master Bにささっている(サブネット1の)ケーブルを接続し、Host Master B内蔵NICにはHost Master Aに接続されていたサブネット2のケーブルを接続すれば良い。

NASの用意

NASのディスクを各NAS上でRAID5で構成する。

2台ひと組にしておけば、btrfsは-d1であってもディスクを使い切ってくれる。 -dsingleにする場合は、NAS内のディスクは容量を揃える必要があるが、NASの合計容量を揃える必要はなくなる。

全ディスクを連結してRAID5を作ってしまうと、ディスク容量の制約が厳しくなるので、この方法のほうが良いだろう。 性能面でも、暗号化とRAIDの組み合わせはかなり重いので、速度を考えればハードウェアRAIDのほうが望ましい。

RAID5を構成したディスク上にLUNを作る。 グループはMasterとSlaveで異なるものにしたほうが良いが、Master NASはサブネット2、Slave NASはサブネット3に置かれるため、実際に混在することはない。

ホストのセットアップ

iSCSIイニシエータとして利用するため、iSCSIイニシエータutilのインストールと、iscsiサービスの起動が必要になる。

利用方法については、archwiki参照のこと。

全てのiSCSIターゲットにログインした上、これをluksFormatする。 ディスクは増えていくことになるので、キーファイルを使ったほうがスクリプトにする際に良いだろう。

# cryptsetup luksFormat /dev/sdb /path/to/keyfile

そしてオープンする

# cryptsetup luksOpen --keyfile-/path/to/keyfile /dev/sdb Crypt1
# cryptsetup luksOpen --keyfile-/path/to/keyfile /dev/sdc Crypt2

btrfsファイルシステムの作成

# mkfs.btrfs -L MasterBtrfs -m1 -dsingle /dev/mapper/Crypt[12]

追加で、サブボリュームの作成や、fstabの編集などを行っておく。

iSCSIターゲットの探索とログイン、ディスクの復号化とマウントの一連の流れはスクリプトにしておいたほうが良いだろう。

利用

まずNASを起動し、次にホストを起動する。そして、スクリプトによってマウントする。 セットアップが終われば非常にシンプルである(ただし、スクリプトにしていないと打つコマンドの量は多い。それはそれでセキュアだが)

スクリプトをsystemdユニットにしておくのは良い考えだが、コケる可能性の高いユニットなので、enableにはしないほうが良いだろう。

NFSとファイル配置

NFS v4を提供する。Manjaro Linuxでの手順である。

まず、btrfsのマウントポイントは/mnt/masterであるとする。 しかし、実際には特定ユーザーのデータが配置されるのであり、~foo/.masterfsがマウントポイントである。

そこで、これを反映できるようにするため、スクリプトの先頭で次のようにしておく

mount --bind /mnt/master /mnt/master
mount --make-rshared /mnt/master
mount --bind /mnt/master ~foo/.masterfs

これにより、ふたつのマウントポイントを意識せずに共有することができるようになる。

さらに、ここではNFSのマウントポイントも別に用意する。

mount --bind /mnt/master /srv/nfs4/masterfs
mount --make-slave /srv/nfs4/masterfs

ここまではスクリプトに含めると良いだろう。

NFSパッケージのインストール。

# pacman -S nfs-utils

/etc/exportsの設定

/srv/nfs4/masterfs 192.168.1.0/24(rw,no_subtree_check,nohide)

v2, v3の無効化(/etc/conf.d/nfs-server.conf)

NFSD_OPTS="-N 2 -N 3"

起動。マウントを手動で行っているため、enableは非推奨。

# systemctl start nfs-server

他ホスト(サブネット1のホスト)からマウントするためには、次のようにする。

# mount -t nfs -o vers=4 masterhost1:/masterfs /mnt/masterfs

-t nfs4とする必要がある場合、サーバー側パスにエクスポートルートを含める必要がある場合があるという。

CIFS

Arch系ディストリビューションにおけるSambaのセットアップ手順はArchwikiが参考になるだろう。

Linuxを中心に使っているユーザーにとっては、常時マウントするわけではないから、ファイルマネージャでのusershareシェアで十分かもしれない。

ただし、AndroidユーザーにとってはCIFSで構築したほうがメディアファイルの再生も容易になる。

DLNA

メディアファイルを広く再生する方法として有効なDLNA。

DLNA対応のプレイヤーがあり、それによって大画面で見られるといった場合には役立つだろう。

主にHost Masterを使い、Host Masterにログインすることが前提であるならばRygelで良いと思う。 そうでない場合は、ReadyMedia(minidlnaパッケージ)を利用することが推奨されているようだ。

Archのminidlnaはminidlnaユーザー, minidlnaグループで動作する。 そのため、ライブラリはこのユーザーでアクセス可能でなくてはいけない。

また、面倒を避けるためには、/etc/minidlna.confinotifynoにしておくのが良いだろう。

あるいはユーザーで実行したい場合は

$ install -Dm644 /etc/minidlna.conf ~/.config/minidlna/minidlna.conf
$ vim ~/.config/minidlna/minidlna.conf
$ minidlnad -f ~/.config/minidlna/minidlna.conf -P ~/.config/minidlna/minidlna.pid

のようにする。

DAAP

iTunesを使用しているユーザーにとっては軽快に動作する音楽ストリーミング方法。 forked-daapdが推奨されているが、AURにしか存在しない。

forked-daapdをインストールし、libraryセクションのdirectoriesを設定、当該ディレクトリをdaapd実行ユーザー(デフォルトでdaapd:daapd)がアクセス可能な状態にして

# systemctl start forked-daapd

で動作する。

LinuxではAmarokあるいはRhythemboxで再生できる。 Androidスマートフォンでは、DAAP Media Playerなどがあるようだ。

2008年頃に流行したDAAPだが、既にだいぶ廃れている印象はある。

ストレージとの分離

ユーザーデータ(dotfileなど)にも容量の大きなものがあるため、ストレージに退避したいと考えるかもしれないが、割とそれはリスキーである。

dotfileの場合、ファイルシステムをまたぐと動作しないもの、シンボリックリンクをこえられないものがあったりする。 また、ログイン時においてはストレージから切り離された状態にある可能性もあり、またストレージがダウンする可能性もあると考えなくてはいけない。

つまり、ストレージが切り離されても動作する状態を保ったほうが良い、ということである。

また、作業中のファイルなどは、ストレージとは別にシステム側にもあったほうが良い。ストレージが切り離された時に作業不能になる度合いを軽減するためである。

さらに、xdgディレクトリはシンボリックリンクが切れているとログイン時に変更されてしまう。 そのため、データが大きい~/Pictures~/Videoなどは、単純なディレクトリとして、その下にシンボリックリンクを配置したほうが良い。

運用の一例としてだが、次のようなストレージ構成だとする

sda      Internal SSD      System
sda1     Internal SSD      System, /
sda2     Internal SSD      System, Swap
sdb      iSCSI 1GbE        Data, Btrfs
sdc      iSCSI 1GbE        Data, Btrfs

次のようなマウント結果となる

/dev/mapper/luks-xxxxxxxxxxxxxxxxx on / type ext4 (rw,relatime,data=ordered)
/home/foo/.storage on type btrfs (rw,noatime,compress=lzo,space_cache,subvolid=258,subvol=/master)

ストレージへ同期されるべきものとして以下のように構成する

WorkSpace
+ Documents
+ Dotfiles

製作中のメディアファイルはDocumentsではなく~/.storage/user/art/以下に配置し、Documentsは文書ファイルのみを配置することで軽量なディレクトリにすることができる。

次のようなスクリプトを作っておく

#!/bin/zsh

WS=$HOME/WorkSpace

update() {
  rsync -avH "$@"
}

sync() {
  rsync -avH --delete "$@"
}

gitup() {
  (
      cd "$1"
        git add .
        git commit -m "Synced at $(date +%y%m%d)"
        git push
    )
}

hgup() {
  (
      cd "$1"
        hg add .
        hg commit -m "Synced at $(date +%y%m%d)"
        hg push
    )
}

gitup $WS/Documents
for i in $WS/Dotfiles/*
do
  hgup $i
done
sync ~/Pictures ~/.storage/XDG/
sync ~/Videos ~/.storage/XDG/
sync ~/Mail ~/.storage/

slave系

これでmaster系は54TB(3TB * 20 disks)ものスペースを一台に集約し、そのファイルを他のホストでアクセスするようにすることができた。 NFS/CIFS/DLNA/DAAPでアクセスできるため、ファイルの取り扱いは非常に良いはずだ。

加えてRAID5によりディスク故障やディスク破壊にも対応する。

だが、これでも壊れる可能性はある。誤消去や誤った更新・上書き、NASの故障、Btrfsの修復不能なクラッシュにどう対応するのだろうか?

ここでRAIDとバックアップは違う、という基本に立ち戻る必要がある。 つまり、このように堅牢なシステムを作っても、あるいはBtrfsクラッシュに備えてRAID5 NASにBtrfs RAID1を組み合わせたとしても、バックアップは別途必要なのである。

基本的にバックアップはメインストレージと同等の設備が必要になる。 もしメインストレージをBtrfs RAID1としているのであれば、バックアップにおける無停止性はそれほど重要ではないため、その場合はメインストレージの半分で済むということになる。

つまりおおよそシンメトリカルな2つのストレージ群とホストが編成されることになる。 ただし、slave系のコントローラホストはサーバーであり、処理性能よりも省電力性や静音性が重要となるだろう。 とはいえ、あまりにも処理性能をおざなりにすると、SSHの処理でもたついて時間がかかることになる。

現状で当環境においてはProLiant MicroServerを使用しているが、どちらかといえばラップトップのほうが適性があるとされている。 標準でコンソールを備え、無停電電源装置を内蔵した状態になるからだ。しかも省電力で静音性も高い。 メインホストからみた速度向上のためにはメモリは多目であったほうがいいだろう。

構築、ストレージへの接続、Btrfsの作成は同様である。

バックアップはBtrfsのsend/receive機能を使うことができる。 差分バックアップも用意で、本当に変更されたものだけを転送するため、非常に効率が良い。

次のようなスクリプトを用意する。

#!/bin/zsh

notify-send "BtrSnapSync: Woke"

if ! btrfs subvolume snapshot -r /mnt/master /mnt/master/snapshots/snapshot-new
then
  print "BtrSnapSync: **CRITICAL** Failed to create new snapshot"
  exit 2
fi

sync

notify-send "BtrSnapSync: Snapshot."

if [[ -e /mnt/master/snapshots/snapshot-old ]]
then
  if btrfs send -v -p /mnt/master/snapshots/snapshot-old /mnt/master/snapshots/snapshot-new/
  then
    notify-send "Send Snapshot."
    btrfs subvolume delete /mnt/master/snapshots/snapshot-old
    mv /mnt/master/snapshots/snapshot-new /mnt/master/snapshots/snapshot-old
    notify-send "Deleted old Snapshot."
  else
    notify-send "Failed to send Snapshot"
    btrfs subvolume delete /mnt/master/snapshots/snapshot-new
  fi
else
  if btrfs send -v /mnt/master/snapshot-new
  then
    notify-send "Send Snapshot."
    mv /mnt/master/snapshots/snapshot-new /mnt/master/snapshots/snapshot-old
    notify-send "Deleted old Snapshot."
  else
    notify-send "Failed to send Snapshot"
    btrfs subvolume delete /mnt/master/snapshots/snapshot-new
  fi
fi

また、slave側は次のようなスクリプトを用意する。

#!/bin/sh
btrfs receive /MirrorRoot && mv /MirrorRoot/snapshot-new /MirrorRooot/snapshot`date +%y%m%d%H%M`

あとは次のようにすることで転送する。

$ btrfssend.zsh | ssh -i /root/.ssh/btrfssnapsync root@slave.local /usr/local/sbin/btrfsreceiver.sh

暗号化を行わず処理を軽減するには、まずslave側で次のように実行する(OpenBSD Netcatを使用している)

# nc -l 12358 | btrfsreceiver.sh

続いてmaster側。ここではbashを使っている。

$ btrfssend.zsh > /dev/tcp/slave.local/12358

暗号化の必要がないとしても、危険だと考えられるため、SSHの利用が推奨される。

ThinkPad e440 * Manjaro Linux KDE, Fcitx Mozc Neologd UT, Padre

ThinkPad e440にManjaro Linux KDE 15.12 (x86_64)をインストール

これまでPCLinuxOSで運用してきたThinkPad e440だが、どうしても不安定(KWinがフリーズして再起動することが多い、バッテリーモニターが機能しない、など)なのが気になってManjaro Linuxにしてみた。

私のThinkPad e440はCeleron 2950Mに4GB RAMの貧弱仕様、ピクセル数もWXGAにすぎない。RAMに関しては8GBに拡張してある。これによってようやくまともに動くようになった(その前は遅くて仕方がなかった)。ハードディスクも拡張済みだ。

このRAM拡張のおかげで、以前はまともに動かなかったKDE Plasma Workspaceが動くのだが、それでもかなり重い。それでもKDEが好きなのと、特にシステムを細かく設定し、好みのアプリケーションを使い分けてデータを扱いやすいように保存する…という意図がなければ、ひと揃い便利なものがあるKDEは非常に重宝するのだ。

最新のLXQtもあったが、今回もKDE。これでうちは4台がManjaroに。とうとう残るManjaroじゃないやつはIPFire, linuxbeanだけになってしまった。

e440はWindows 7が入っており(Windows 10にしたものの、結局Sonarがちゃんと動かないので戻してある)、デュアルブートなのがここまでのハードルになっている。

Manjaro Linux KDE 15.12時点ではインストーラは、Thusについては手動パーティショニングについてLUKSは使えるが、LVMは扱えない。また、GrubはMBRのみ。CalamareはLVM及びPBRをサポートするが、LUKSをサポートしない。

今回はLUKS優先でThusでインストールした。レガシーブートなので(Windows 7モデルを選択するとレガシーブートで、Windows 8モデルを選択するとUEFIで来る)問題が起きにくいというのはある。

Wi-Fiの問題

e440に入っているWi-FiモジュールはLinuxでうまく駆動しない。ある程度通信すると止まるのだ。

Manjaroだとほぼ直ちに止まる。PCLinuxOSだと通信量が少なければなかなか見立たない。openSUSEではストールしたのを見たことがない。

これがPCLinuxOSを選択する大きな理由だったのだが、結局止まるのであれば、あまり意味がなかった。

これを受けて、Wi-Fiはドングルを使うと割り切ってManjaroを導入することにした。

とはいえもしかしたらなんらかの改善方法があるのかもしれない。

以前にはブログでもその問題をみかけることができるが、バージョンが限定されている。
Ubuntuでfixが入っただけかもしれないので、特定のカーネルの問題ではないのかもしれない。

また、Dedoimedoでもこの問題について言及されている。こちらでは/etc/modprobe.d/rtl8723be.confとして

options rtl8723be fwlps=N ips=N

を記載することを勧めている。

これを受けて試してみたのが、まずkernel headerをインストールした上で、AURからrtl8723bs-dkms-gitをインストール。

そしてdkmsを有効にする

# systemctl enable dkms

そしてインストール

# dkms install rtl8723bs/2

これで再起動したところ、3.7GBのファイルのダウンロードに成功した。

ただし、時々不安定になるので、切断・再接続をする必要がある時もあるかもしれない。それでも十分実用になる。yaourt

Plasma5

sniproxy不要になったPlasma5だが、いくつかのアプリケーション(Mono関連, Cloud.ru, Skype, Wineなど)が結局systrayに入らない。
必要であればtrayerを併用するべき。

非常にアピアランスは良いし(Plasma 4のリッチUIも良いと思うのだけれども、フラットUIになったのに見やすく、美しくなった。元々タブレットやネットブックに向けて作られたフラットUIは、あまり画面解像度もないラップトップには適しているということだろう。非常に見やすい。

全体に優れている。完璧ではないけれども優れている。
ManjaroをXFceからインストールするとKMailが動かなかったり、Akonadiでエラーが出たりするが、そうした問題はさすがに改善されている。

Kate, Kwriteは、通常のXFceから入れるものとはちょっと違う。違うのだが、PCLinuxOSではRubyの特異クラスをちゃんと理解したように思うのだが、こちらはダメだ。残念。

Manjaro Setting Managerが含まれないため困惑するが、こちらはkcmに統合されている。

バッテリーモニターは適切に動作する。パワーマネジメントもPlasma 5.3で無事追加されている。

パワーマネジメントでバッテリー駆動時の設定を行うためにはバッテリーを取り付けておかなくてはならない。

e440においてのみ発生する現象だが、Super+Shift+→が動作しない。
quicktileにその設定が使えないのが少々痛い。この問題はThinkPad e440上のKDEで常に発生する。

動作速度は良いが起動・終了は非常に遅い。安定性はPCLinuxOSのKDE4よりも安定している。
アイコンの通知表示が優れている。ただし、systrayに関しては自然に階層化されるCinnamonのほうが優れている。

クイックランチ的に置かれているアイコンはパネル上のウィジットである。Firefoxが邪魔なのだが、これを削除するにはパネル編集モードから削除する。

ウィジットはまだ少なめだ。リサイズ方法は、余白部分を左ボタンダウンを続けてメニューを表示する、というあまり直感的ではない方式。タッチインターフェイスを意識したのか。しかしそれは右クリック相当じゃないのか。

Kde Applications

KDEには膨大な、様々な、そして有用なアプリケーションがあることがおおきなアドバンテージだが、Manjaro KDEはその収録量が少ない。Konquerorすら入っていない。

(とはいえ、近年はKonquerorは入れない傾向があるため、それほどめずらしくはないのだけれど)

kde-applicationsグループにまとめられているので、

$ yaourt -S kde-applications

でしっかりと入る。

テーマ

ManjaroにはMaiaテーマが採用されている。

緑を用いたなかなかに美しいテーマで、Manjaro色が良いと思うかどうかという問題はあるが、ひと揃いあって統一感は良い。breezeよりも良いので、統一感をもたせにくい他のテーマを採用するのが難しい。

Maiaアイコンテーマの再起動、シャットダウンなどのアイコンは非常に好きで、アイコン自体は個人的にはcompassのほうが好きなのだが、結局Maiaのまま。壁紙もMaiaなのでフルMaia。

ちょっとこれはなんとかしたい。ウィンドウデコ
レーションはMaiaではなくbreezeなのだが、これは変更した。また、壁紙も変更した。

Plymouthはなぜか他と同じmanjaro-extra-elegantではなく、manjaro-elegantが採用されている。私はmanjaro-redefined-bsplashを採用した。

アクティビティ

使い方に困る人の多いアクティビティで、私もご多分に漏れずではあるが、e440においては追加したアクティビティがひとつある。

これはプレゼンテーション用で、パワーマネジメントをACと同じにしてある。
なお、ACではDim screenやスクリーンのオフなどは切ってあり、ブライトネス設定がない。

Fcitx Mozc Neologd UT

つい先日libkkcの話をしたばかりではあるが、やはり入力効率はMozcのほうが良い。しかし、MozcではATOKに及ばないのは当然としても、WindowsのGoogle日本語入力との差が激しい。

PCLinuxOSにおいてTomcatさんの仕事で非常に大きなアドバンテージとなっていたNeologd UTがAURにも来ていたる

これは、UTUMIさんがUTに代えた新たな仕事として作ったもののようだ。UTの35万語から85万語に大幅増となっている(半数は地名とのことだが)ので入力効率が大幅に向上しているのだ。
確かに出てくる文字が違う。UTだとAndroidのGoogle日本語入力と非常に似た変換候補という印象なのだが、こちらは違う。

ニコニコ大百科が使えなくなるので一部変換できなくなる言葉も出てくるだろう。もしかしたらニコ厨諸兄にあってはMozc UTでnicodicを有効にしたほうがいいのかもしない。

あとは、mecab-ipadic-NEologdがどれだけのものに今後なっていくか次第か。

とりあえず使ってみた感触では従来のMozc-UTよりも良いと思う。
ただし、サイズ自体もかなり大きいので、ディスク消費量が問題になる場合には不適。また非常にメモリ消費に対して厳しい場合も同様。

その意味ではuim-anthyが使えるPCLinuxOSは有利。Whizもいいのかもしれない。
とにかくパワフルで効率的な変換をしたい人にとっては、Linuxでは現状の最有力。Wimeを使うという手段もあるのかもしれないが。

Padre

AURのPadreがPerl::Devel::DumpvcarとPerl::POD::Abstractがビルドにこけるためインストールできない。prove -lrprove -rにビルドを通すため変更したとあるが、prove -lrに戻さないと通らないので注意。

さらに、perl-wx-scintillaに関しては、OUT OF DATEが立っていてビルドできない。
そのため、perl-padreのPKGBUILDを編集してperl-wx-scintilla-devに変更することはできるが、いずれにせよこれが原因でビルドできない。

なお、cpanでインストールしようとするとシステムがフリーズする。要注意。

ThinkPad e440 * Linuxの長い戦い

何を導入する?

e440の構成は以前はWindows 7とPCLinuxOSのデュアルブートだった。
その前はSabayon Linuxで、結構安定していたのだが、使いにくい部分があり、PCLinuxOSとなった。

これが潰されたのは、Windows 7の書き戻しのためだ。

その後、時間がなかったため放置され、今回再編成に伴ってWindows 7はそのまま修正することが決まったため、Linuxを導入することになった。

ところが、これが辛い道のりだった。

望ましい構成は

  • sda1 Windows booy
  • sda2 Windows System
  • sda3 /boot
  • sda4 Extended
  • sda5 truecrypt
  • sda6 LUKS LVM PV

というものなのだが、このためには

  1. /bootにPBRとしてGrubを導入できる
  2. 手動パーティショニングができる
  3. LUKS上にLVM PVが作成できる

という条件を満たす必要がある。
ところが、個々には一般的なことであるにもかかわらず、要件を満たすインストーラがない

  • Manjaro Thus : PBRインストール、LVMに対応しない。crypt swapでエラーとなる
  • Manjaro Calamares : LUKSに対応しない
  • Manjaro CLI Installer : UUIDで設定するが見つけられずエラーになる
  • Linux Mint : LVMに対応しない。複数のcryptデバイスを設定できない
  • openSUSE : PBRへのGrubインストールを無視する、エラー多数でうまく動作しない

困り果ててしまった。
途中、諦めてPCLinuxに戻ったりもしたのだが、AddLocaleが正常に動作せず、ほかを試し、結局3日ほどかかった。

この要件、自動インストールであればちゃんと動作するのだが、手動だとなかなか動かない。
インストーラの品質は難しいところなのか。

ちなみに、Manjaro 0.8.13においては、WiFiが接続はできるが、通信しているとストールしてしまうという問題も発生した。

セットアップ

結局うまくいったのはPCLinuxOSだった。(Reiser4が使えなかったりはした)
AddLocale周りの設定は、手順としては(@PCLOS 2014.12 KDE)

  1. インストール
  2. 初期設定
  3. アップデートとアップグレード
  4. 再起動
  5. Localization ManagerからのAddLocale
  6. リポジトリをJAISTに変更し、Tomcatさんのリポジトリを追加する。パッケージリストはリロードしておく。
  7. アップグレードしておく
  8. gsetime(入力メソッドの選択)でIMEにuimを選択する。uimは私の好みなのでscimやfcitxにしても構わない。i-busを使用する場合はTomcatさんのリポジトリの追加を忘れない

なお、解像度がどうしてもXGAになってしまうため、PCLinuxOS Control Centerで設定しておく。KDEの設定で設定しても再起動時には戻ってしまう。

uim

uimを選択したのは、元より日本人が日本語入力のために制作したもの(SCIMやfcitxは日本語のために作られたわけではない)であり、非常に軽量でセキュアだ。シンプルだが、「日本語を入力する」という観点から言えば最高だと思っている。

残念ながら開発が停滞し、国際的にも支持されていないことから消えそうになっている。
日本でもMozcがuimが使えない(そもそも、人気の高いUbuntuやFedoraが国際的なものでSCIM, i-bus, fcitxなどを採用する)といったことで使われなくなってしまっている。

SCIMやi-busと比べ、安定していて高機能なfcitxにさほど不満はないが、やはり私はuimが好きだ。

PCLinuxOSのIMEは、MozcにせよAnthyにせよ、入力効率は非常に悪い。
しかし、Tomcatさんのリポジトリを追加することで、入力効率に優れたかな漢字変換を使用することができるようになる。

野良版のuim関連のパッケージを一通り入れても、UIM appletは起動しない。
だが、uim-toolbar-gtk及びuim-toolbar-gtk3は存在するため、これを自動起動に追加すれば動作するようになる。

uimはWeb変換サービスに対応している。
Ubuntuにもuim-google-cgiapi-jp, uim-baidu-olime-jp, uim-social-ime, uim-ajax-ime, uim-yahoo-jpのパッケージが用意されている。
野良版uimはこれらも既にセットアップされた状態で提供される。

なお、uimだとkkcは利用できない。
kkc愛好家(いるのか?)の方はfcitxを使用すること。

野良版uimだと、公式のfcitx-mozcで生じるかな入力において「ー」が「ろ」になる問題、fcitx-anthyで逆に「ろ」が「ー」になる問題は解決されている。

sudoは

sudoはi586版だとspecialにあるが、x86_64版は普通にある。

サスペンド/ハイバネーション

e440だとサスペンド(スリープ)/ハイバネーションできない。ずっとファンが回っていてハードディスクの音がしているので、復帰できないのではなく、サスペンドに入れないのか。

Window decorationsをいじるとまずい

KDEのBTSにも記載があるけれど、ウィンドウの装飾を変更するとKDEが起動しなくなる。

~/.kde4/share/config/auroraercをトバすだけでは解決しないため、かなり厄介な問題になる。要注意。

Manjaro 0.8.13.1 LXQt を LVM + LUKS + GPT + UEFIインストール

3回失敗したので、メモを兼ねて。

情報は

の2箇所にあるため、これを組み合わせる必要がある。 また、情報の欠如もあるので補足する。

まずはターミナルを起動

$ su -
  manjaro #Password
# gdisk /dev/sda

/dev/sdaがインストール対象ディスクであるとする。 以下オペレーションは

  • o #新しいGPTレベルを作成
  • Y #確認
  • n #新規パーティション (BIOS GRUBのためのもの。なくてもいい?)
  • (enter) #次のパーティション
  • (enter) #フリー部分の先頭
  • +1M # 1MiBのパーティション
  • n #新規パーティション (ESP)
  • (enter) #次のパーティション
  • (enter) #フリー部分の先頭
  • +256M # 256MiBのパーティション
  • n #新規パーティション (/boot)
  • (enter) #次のパーティション
  • (enter) #フリー部分の先頭
  • +512M # 512MiBのパーティション
  • n #新規パーティション (LVM)
  • (enter) #次のパーティション
  • (enter) #フリー部分の先頭
  • (enter) # entire disk
  • w #書き込み
  • Y #確認

LVM on LUKSの構築

# cryptsetup luksFormat -y --cipher aes-xts-plain --key-size 512 /dev/sda4
# cryptsetup luksOpen /dev/sda4 sda4_crypt
# pvcreate --dataalignment 1024k /dev/mapper/sda4_crypt
# vgcreate cryptVG /dev/mapper/sda4_crypt
# lvcreate -n root -L 20G cryptVG
# lvcreate -n swap -L 16G cryptVG
# lvcreate -n home -l 100%FREE cryptVG

インストーラはSwapを求めるし、Swap用のボリュームも確保した。

で、

# setup
    1. Set date and time
    1. Partition Hard Drives
    • swap – /dev/mapper/cryptVG-swap
    • / – /dev/mapper/cryptVG-root
    • /home – /dev/mapper/cryptVG-home
    • /boot – /dev/sda3 (EXT3)
    • /boot/efi – /dev/sda2 (VFAT)
    1. Install System
    1. Configure System – mkinitcpio.confについてHOOK行にencrypt lbm2sata filesystemよりも先に記述する。そのままこの画面に留まる
  • タブを開く
  • /install/etc/default/grubGRUB_CMDLINE_LINUX_DEFAULT="cryptdevice=/dev/sda4:cryptVG"と記述する
  • installerの4から離れる
    1. Install bootloader
    • UEFI_x86_64
    • GRUB_UEFI_x86_64
    • フォーマット
    • efivarsが読まれてないよと言われる場合も無視して良い
    • コピーするかと聞かれた場合はYES
    1. Quit
  • 再起動

この作業を繰り返したことで、だいたいLUKSパーティションの起動やUEFIについて仕組みが理解できてよかった。

ただし、実際に動くかどうかを確認できていない。 なぜならば、ハードウェア結局UEFIをサポートしていなかったからだ。どうりで失敗するわけだ。

「update-grubがコケる」問題、ついに解決か

ブログでは4月14日のアーティクルでレポートし、 先日のアーティクルで再インストールという解決方法に至ったことを紹介した。

実際には2月には問題は発生しており、実に4ヶ月以上に渡って、Grubのトラブルということでいえば7ヶ月に渡って悩まされてきた。

この問題はManjaro Forumに、LinuxQuestionに、そしてGoogle+でと訊いていくことになったが、誰ひとりとして解決策を提示することはできなかった。 状況変化に合わせてManjaro Forumで再質問し、再インストールという解決策をとったものの、 結局アップデート時に問題は再発、絶望的な気分を味わった。

だが、そこで気づいたことがあったので、試してみることにした。

  • 再インストール
  • update-grub -> 成功
  • LVM snapshot作成
  • update system -> 失敗
  • LVM snapshotのマージ
  • update-grub -> 成功
  • LVM snapshot作成
  • update-grub -> 失敗
  • LVM snapshot削除
  • update-grub -> 成功
  • update system -> 成功

system upgradeでの失敗によるシステム損傷に備え、巻き戻しを可能にしてきたLVMスナップショット。 実際にこの巻き戻しによってとても救われてきた。 それによってここまで環境を崩壊させず「ダメでした」で済んでいた。

だが、それが原因だったというのか。 LVM snapshotが原因でupdate grubが失敗するなんていうことがありうるのか。 全く関係ないように見えるのに。

とりあえず、完全に解決したのか分からないが、解決したように見える。

これは難題だった…

壊れたシステムの修復のためのManjaro 0.8.13インストール

update-grubできない問題は根が深く、様々なところで訊いてはみたものの、結局答えが出ない。

Manjaro 0.8.13について

Manjaro Linuxは0.9.0リリースを控えていたが、新インストーラのCalamaresのバグがなかなか解消できず、結局0.8.12でCalamaresを採用したものの、インストーラをThusに戻した0.8.13をリリースするに至った。

Manjaro Linuxの日本語を一手に引き受け、Manjaro JPも開発するrago1975さんによれば、0.9.0のThusインストーラバージョン的なものだとという。

実際にそのように感じる。というのは、XFceはGTK3を採用する4.12、KDEはPlasma5なので、デスクトップが別物になっている。 XFce版だとDMも完全に別物となっており(もしかしたらMDMから差し替えられたのかもしれないが)、雰囲気はがらっと変わった。

XFceは0.8.12でも4.12の開発版である4.11を採用しており、現行のManjaroテーマも既に採用されていたため、0.8.12からの目新しさは特にない。 とはいえ、それまでの0.8.11からすれば劇的に変わり、垢抜けないデザインが特徴だったXFceもぐっとスタイリッシュになった。0.8.12と比べてもやはり部分的に見た目も変更されている。

アップデートでは見た目に関する部分は変わらないため、「見た目が変わった」というのは、入れ替える動機にもなるかとは思うが(Plasma4がPlasma5に置き換えられるのは当面先だろうから、入れ替えはかなり大変だと思う)、今回はThusの改良に非常に力が入れられていた。

まず、Thusインストーラの起動はすごく速くなった。これまでは、忘れた頃に起動する勢いだったが、すぐに起動するようになった。

Thusは手動パーティショニングをしてもLUKSの利用ができるようになったはずだが、それについては今回試していない。

LUKSパスフレーズについては、「特殊な文字を使うな」という注意書きが増えた。「LUKSパスフレーズに記号を含めると復号化できなくなる」という問題に対応したのか。

またブートローダーはGRUB2とGummibootを選択できるようになった。しかし、Gummibootを選択するとブートローダーはインストールされない。 また、Gummibootを選択した場合、ブートできない可能性があるのでウェブサイトを見るかと聞かれる。

Thusはかなり改善されたことを感じられる。

また、0.8.11まではUEFIでインストールしても第1パーティションにGRUB_BOOTを切っていたが、これをやめて3パーティション構成になった(ESP, BOOT, LVM)。Gummibootにすると、2パーティションになる。

Gummibootにきちんと対応してくれると嬉しかったのだが…

なお、Manjaro 0.8.11をそのままにしてインストールすると、GRUB2でも起動しなかった。 事前にGPTを作成しておくことで無事に起動できた。

ただし、UEFIブートメニューに謎の無効な空欄エントリがあるということは変わらない。

導入しようにも…

しかし、Alternative HDD (500GB)に入れても、そこで構築してSSDに移す、というのはかなり大変な作業になる。SSDのほうが小さいからだ。

かといって、環境をイチから作るのに、現行の環境を潰してしまうと、だいぶ長く仕事ができなくなってしまう可能性がある。

散々悩んだ挙句、結局はSSDをもう1台追加することにした。 ケーブルも併せてだいたい12000円の出費。なかなか痛い。 だが、仕事を見通しが立たないまま止めるわけにもいかないし、かといって更新できない状態でも放置できないので、やむなしか。

ケーブルはAmazonで、SSDはNTT-Xで購入。NTT-Xは仕事でも使えるようなので、これからかなりお世話になることになるだろう。

ケーブルは当日、SSDは翌日に到着した。

インストール作業

インストール

まずは単純に、SSDを組み込んで元のSSDとAlternative HDDを外し、予めGPTを作成した上でThusインストーラでインストールする。

UEFIでLVM, LUKS, /home分割はon, GRUB2を選択、なお起動時にはnomodesetnokmsbootオプションが必要。

ただし、インストール後はnomodeset及びnokmsbootは必要なかった。

基本セッティング

まずはworldencmountの必要なファイルをtarで展開する。これでbtrfsボリュームのマウントが可能になる。

そしてzshのインストール。 なお、zsh-configについてはかなり癖がある設定の上に、手元の.zshrcで設定できなくなるので私は好まない。

これでマウントできるようになったら、btrfsをroでマウントし、最低限のファイルをコピーする。主要な設定ファイルは

cp ~/share/manjaro-home-transition/*(#q@) .

で以降できる。データ本体は~/shareにあるため、データの以降は必要ない。

日本語フォントはあるが、日本語入力ができない状態でスタートするため、とりあえず

yaourt -S fcitx-mozc-ut

インストール前にPKGBUILDをいじってニコと英語dicを有効にしてインストール。 ただし、googlecode.comのIPv6問題があるため、その前に

yaourt -S dnsutils

してdigを使えるようにし、

dig japanese-usage-dictionary.googlecode.com

して/etc/hostsにIPv4で決め打ちする。

私のプログラムは多くがRubyを使うため、Rubyも設定しておく必要がある。 これは次の方法で行う。元々

pacman -Q > pacman-q

としてあり、ここから

grep -F ruby pacman-q | cut -d " " -f 1 > rubypkg

として抽出。このうちインストール済みのものは必要ないので、

pacman -Q | cut -d " " -f 1 > pacman-qq

と現状のものを取得し

cat pacman-qq pacman-qq rubypkg | sort | uniq -u > target-ruby

とする。あとは

yaourt -S $(cat target-ruby)

でOKだ。

同様の方法でTTFファイルもインストール。

また、EncFSをコアに入れているので、EncFSをインストール。

yaourt -S encfs

また、nemoはテンプレートディレクトリにシンボリックリンクを許容するが、Thunarはしないので、シンボリックリンクをやめて、コピーに

rm template
cp -R share/template .

さらに、エスケープしたfstabをベースにfstabを修正する。 その前にVIもVimもなくて混乱するため(例えばvipwはあるのに、vipwはできない)、インストールしておく。

yaourt -S gvim vi

とりあえずエディタはmousepadが使える。とりあえずはmousepadで修正しリブート。

日本語周り

fcitx-mozc-utだけ入れたが、それさえ入っていなかった。 そして、日本語周りはManjaro JPベースではないため、それなりに複雑だ。

まず、fcitx-mozc-utがベースになるので、それをインストール。

yaourt -S fcitx-mozc-ut

各ツールキットに対して入力するためのパッケージと、設定のためのパッケージも導入

yaourt -S fcitx-gtk2 fcitx-gtk3 fcitx-qt4 fcitx-qt5 fcitxconftool

これだけでは入力できないため、~/.xprofileに追記

export GTK_IM_MODULE=fcitx
export GTK2_IM_MODULE=fcitx
export GTK3_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS="@im=fcitx"
export DefaultIMModule=fcitx
export PATH=/home/aki/bin:$PATH

$PATHは別件だが、ついでに書いておいた。XMODIFIERSXMODIFERSと書いており、LINEやSkypeに対して日本語入力できないという問題が発生して若干ハマった。

なお、さらに後ほど突如としてGTKアプリケーションに対してfcitxが有効にならず、

gtk-query-immodules-2.0 --update-cache 
gtk-query-immodules-3.0 --update-cache 

しても直らず、結局両パッケージをアンインストールした上で再インストールしたら直った、などということもあった。

そして再起動。

パッケージインストール part1

先にいくつか使われるのがわかっている~/.config以下のファイルをコピーしておく。 .config以下はそのままシンボリックリンクに変換できないからだ。

cp ~/share/manjaro-home-transition/.config/usr-dir* .config/
cp -R ~/share/manjaro-home-transition/.config/opera-developer .config/
cp -R ~/share/manjaro-home-transition/.config/tasque .config/
cp -R ~/share/manjaro-home-transition/.config/fontconfig .config/

そして次のパッケージをインストールしていく。

  • ctags
  • leafpad
  • medit
  • geany, geany-plugins
  • smplayer, smplayer-themes, smplayer-skins
  • opera-developer
  • linux405
  • infinality*
  • wine
  • plasma
  • kde-applications
  • kopete

Wine * LINEで文字が非常に汚い、という問題があったが、いつの間にか直った。

KDE5関連はplasmaパッケージで、kde-applicationと合わせるとかなりの部分がインストールされる。

kopeteのファイルは~/.kde4以下にあるので、これをコピーする。

cp -R ~/share/manjaro-home-transition/.kde4/share/apps/koepte ~/.kde4/share/apps/
cp  ~/share/manjaro-home-transition/.kde4/share/config/kopeterc ~/.kde4/share/config

KDE5

KDE5は、KDE4よりもさらにスタイリッシュにはなったが、スマホっぽいふらっとUIになり、洗練されたがいかにも重量級な「すごい演出」は損なわれた。

また、非常に多くの機能が未実装だ。

マルチディスプレイの対応についてはkscreenパッケージで対応できるが、細かく設定ができない。 Catalystで設定することはできるが、永続しない。

また、systrayが未実装(!)。libappindicatorとsni-qtを使えばいけるような話なのだが、実際はいくつかのアプリケーションがこれでもsystrayに入らない。

相変わらずKDEで設定が効かない部分があるので、

  • kde-gtk-config
  • kcm-gtk

を導入、さらにqtconfig-qt4を使って設定する。

悪くはないけれど、KDE4から乗り換えるには早いか。 アニメーションはKDE5のほうがパワーアップしているが、KDE4よりも良いかと言われると悩むところ。 少なくとも、設定の問題でKDE4のほうが現状は良いと思う。

KDEとXFce

そして、KDEで設定するとXFceのUIが壊れたりするのでたちが悪い。 この設定はかなり難しいが、基本的には「設定マネージャー→外観」でテーマ設定してからgtk-theme-configで調整すれば良い。

ちょっとややこしいが、gtk-theme-configはextraに"gtk-theme-preferences"という名前でパッケージがあり、さらにAURに"gtk-theme-config"というパッケージもある。 恐らくは公式入りしたが、AURのパッケージ作者がメンテナになっているわけではないのだろう。

より細かく設定するならばxfce-theme-managerがあれば良いが、場合によってはより迷宮入りする。KDEといったり来たりすることになるだろう。

なお、一度XFceが起動不能になり、~/.config/xfce4を吹き飛ばして作りなおすはめになった。この場合、skelからコピーするのが近道。

パッケージインストールpart2

  • cinnamon
  • xsane
  • xfce4-theme-manager
  • fetchmail
  • spamassassin
  • razor
  • virtualbox*
  • tasque
  • skype, skype-call-recorder
  • openssh, sshfs
  • lv
  • w3m
  • nss-mdns
  • amarok
  • audacious, audacious-plugins
  • libcue
  • audacity
  • inkscape-gtk3-bzr

Inkscapeは猛烈に長い。

Zeroconfの設定は、これに加え/etc/nsswitch.confにmdns-minimalを書くこと。avahi-daemonは標準で起動。

Pandoc

相変わらずhaskell-pandocパッケージが入らないので

yaourt -S ghc cabal happy alex

してから

export PATH=$HOME/.cabal/bin
cabal update
cabal install pandoc

PDF出力用に…

yaourt -S texlive-core texlive-langcjk

うまくいった。

TODO

今わかっているのは、Spamassassinのsa_learnで学習したデータを持ち込んでいないこと。

あと、SOXもまだインストールしていない。 それ以外は恐らくは必要になったら足す形で、ゴミパッケージをなるべく増やさないようにするだろう。結局使えなかったものをためこんでしまったからだ。

また、英数キーを押すと問答無用でCapsLockになる、というトラブルも出ている。

Manjaroのアップグレード時のX起動問題と、マウスカーソルの問題

昨年末にきていたAURのアップデートだが、これを適用するとXが起動しなくなる。LVMスナップショットを使ってロールバックしていたが、3回適用しても全て同様の症状となる。

しかし、3回目にyaorutの実行メッセージにヒントをみつけて次のように実行した

sudo mhwd-gpu --setgl catalyst

これで正常に起動した。スナップショットを削除して完了。

そして先日からセカンドモニターのマウスカーソルがバグる、という話をしていて、なんとかしたいので調べてみた。すると、Radeonの問題であり、Windowsでも生じるらしい。Windowsの解決策が並ぶ。

“linux pointer cursor distored”で検索すると情報が出てきた。

のように、

Option “SwCursor” “true”

xorg.confに追記することで解決する、らしい。解決したのかは分からないが、とりあえず今のところなっていない。

アップデート&ロールバック

Manjaroのアップデートを実行したところ、またクラッシュした。X Window Systemが起動しない。

しかし、今回は対策をとっていた。

sudo lvcreate -s -L 10G -n preug ManjaroVG/ManjaroRootとすることでLVMスナップショットを取得、lvconvert --merge ManjaroVG/preugとすることでロールバックできる。

ただし、システム起動中は即座にはできないので注意が必要だ。

Manjaro LinuxのXが起動しなくなった

12-20のシステムアップグレードリリースでManjaroを再起動した際、Xが起動しなくなった。

[ 32.722] (II) fglrx(0): Desc: AMD FireGL DRM kernel module
[ 32.722] (II) fglrx(0): Kernel Module version matches driver.
[ 32.722] (II) fglrx(0): Kernel Module Build Time Information:
[ 32.722] (II) fglrx(0): Build-Kernel UTS_RELEASE: 3.18.0-0-MANJARO
[ 32.722] (II) fglrx(0): Build-Kernel MODVERSIONS: no
[ 32.722] (II) fglrx(0): Build-Kernel __SMP__: no
[ 32.722] (II) fglrx(0): Build-Kernel PAGE_SIZE: 0x1000
[ 32.722] (II) fglrx(0): [uki] register handle = 0x00016000
[ 32.722] (II) fglrx(0): DRI initialization successfull
[ 32.722] (II) fglrx(0): FBADPhys: 0xf400000000 FBMappedSize: 0x010e0000
(==) Log file: “/var/log/Xorg.0.log”, Time: Sat Dec 20 23:57:18 2014
(==) Using config file: “/etc/X11/xorg.conf”
(==) Using config directory: “/etc/X11/xorg.conf.d”
(==) Using system config directory “/usr/share/X11/xorg.conf.d”
(WW) fglrx: No matching Device section for instance (BusID PCI:0@0:1:1) found
/usr/bin/Xorg.bin: symbol lookup error: /usr/lib/xorg/modules/drivers/fglrx_drv.so: undefined symbol: GlxInitVisuals2D

検索すると事例はかなり多く見つかるが、そのほとんどはaticonfig –initialしろというものだ。

だが、これでうまくはいかなかった。nomodesetしろという声もあったが、それはすでにしてあるし、確認もした。

そのほかにはflgrxを無効にする方法について記述されたものがある程度で、それ以外はインストールしろか、もしくは解決しないままか、だ。

かなり深く調べた。エラーでは0:1:1となっているが、本当にBusIDの不一致を疑って調べると0:1:0だったので、それが原因かと思って調べたりもした。だが、結局解決にはつながらなかった。

バックアップしたイメージでロールバック、ということも考えたのだが、まずは総再ビルド&インストール。もし、パッケージが壊れたためならこれで解決する。もともと壊れていたのなら、ロールバックしてアップグレードしても同じことになる。

やり方は次のようなもの。

for i in $(pacman -Q | cut -f 1 -d " ")
do
yaourt -S --noconfirm "$i"
done

sudo時間は長くしておくほうが良い。

だが、うちの場合、頻繁に、長時間に渡ってネットワークダウンが生じる。上流で起きていること(おそらく、回線、集合回線部分のせいだろう)なので私には手出しできない。フルビルドで回っている間ネットワークがダウンすると失敗する。これはなかなか恐ろしい。

幸いにもネットワークダウンには遭遇せず2回完走したのだが、改善しなかった。そこでロールバックを試みたのだが、dumpしたイメージをrestore(8)しようとしたが、0 inode fileと言われ、14GBもあるファイルにもかかわらずできなかった。

システム再インストールしかなくなってしまったが、せめてもということで、pacman -Qの結果を外部に保存しておく。

再インストールだが、Manjaro 0.8.11 Xfce JPのイメージのインストーラではkeymap選択画面でフリーズしてしまい、進まない。0.8.10 XFce JPイメージでインストールする。

2014-11-05のarticleにある手順でセットアップ。

  • pacman-keyの再構築、無効なキーの削除
  • aticonfig
  • vigrでusersのGIDを500

そしてパッケージを復帰させる。いくつか試したが、sudoのtimeoutを無効にした上で

for i in $(ruby -e 'list1 = `pacman -Q | cut -f 1 -d " "`.split("\n")' -e 'list2 = `cut -f 1 -d " " paclist`.split("\n")' -e 'list2.each {|i| next if list1.include?(i); puts i}' )
do
yes Y | yaourt -S "$i"
done

--noconfirmではconfrict時に中止を選択されてしまう。基本的にはこれで通るが、MATE関連でgstreamerかpulseaudioか選べと言われてYを返しても通らないため、チェックしてこの時に一旦INTしてmate関連を手動インストールの上、やり直す。ちなみに、依存関係で入るパッケージもこの方法だと再インストールするため、mozc-utなどはfcitx-mozc-utで入るのだから途中で中断してやり直したほうが早い。

これを避ける方法としては

while p=$(ruby -e 'list1 = `pacman -Q | cut -f 1 -d " "`.split("\n")' -e 'list2 = `cut -f 1 -d " " paclist`.split("\n")' -e 'list2.each {|i| next if list1.include?(i); puts i}' | head -n 1)
[[ -n "$p" ]]
do
yes Y | yaourt -S "$i"
done

で、その他の選択肢を要求する場合を除いていけると思う。だだし、そもそもビルドできないパッケージがあると、それはインストールできないため詰んで(ループして)しまう。監視なしにするにはexpectを使うしかない。なお、xpdf関連は無理だった。

この後は次のようにしてセットアップを進める

  • バックアップしたhomeのイメージをrsync。この時、rsync -av /mnt/1/ –exclude share/ /home/としてマウントされるユーザーデータは回避する。
  • このままではユーザーデータがマウントできないので、sudo -u aki mkdir ~aki/share ~aki/.share.encfsとする。
  • /etc/fstabを編集。tmpfsと~/.share.encfs(btrfsサブボリューム)のマウントを設定。 encfsをマウントするためのスクリプトを~/root/binに書く。
  • これでほぼ通常通り。リブートしてakiでログインし、Catalyst Control Centerを起動、設定すればOKだ。復旧に6日もかかってしまった。
  • 今回のようなことがか内容にと、今回はインストール時にLVMを使用する設定とした。ちなみに、ディスクのパスフレーズの強度を大幅に高めた。
  • だが、標準でLVにVG全域を使用してしまうため、「管理やバックアップを容易にするため」と言いながら、実際は全く柔軟性がない。仕方ないので、SystemRescueCDで起動し、luksOpenしてvgscanし、ルートボリュームをe2fsck+resizefs+e2fsckで縮小した後、lvreduce --size 80G ManjaroVG/ManjaroRootでOK。アップデート前にスナップショットを取るようにすればロールバックは容易になる。Manjaroでは運用中にこのような事態に陥ることが既に3回めなので必要だろう。また、rsyncでバックアップしておくことも必要かもしれない。