Ubuntuのリカバリ方法

ここ最近KVMの長年放置したマシンのアップデートをしたらapt-getでぶっ壊れる事象が発生したので自己流に解決した手段をメモっておく。
まあ、Windows(※XPまでしか触ったことはない)のリカバリーコンソールよりはだいぶましでは有る。なにせ普段使っているコマンドはそのまま使えるから。youがどこにUbuntu入れていても、シリアル番号とかないので安心して使える。いい時代に成ったものだ。
ただし、Canonicalリポジトリ公開が前提なので、サポートが切れてリポジトリが閉鎖されているバージョンのUbuntuは神に祈りながらsudo do-releaseupdateをおこなってバージョンアップしよう。多分無理なのでサポート期限にはくれぐれも注意するか、自前のリポジトリに移行すること。LTSなら4年は大丈夫だが・・・

ゴール

  1. apt-getしてパッケージ管理システムがエラーなしで作動するようにすること。
  2. パッケージシステム以外の状況は関知しない。

状況

うろ覚えなので日本語で

カーネルがアップデートできない

/bootを別パーティーションにしているとカーネルイメージが溜まりすぎてハマる。
アップデート前にsudo apt-get autoremoveをやっておいたほうが良い。

  1. この場合/boot配下のカーネルバージョンが付いたファイルを最新の一個を残して消す。
  2. 再度以下のコマンドを流す。

sudo apt-get install -f

  1. それでも容量たりない(/bootは別パーティションじゃなかった)はまずapt-get cleanをやりましょう。
②sudo dpkg --configure -aしろって言われてやってもできないんですけど

多分依存関係。ssh経由のコンソール上で作業中に寝落ちしても同様のことになる。

  1. 依存関係でエラーを吐くパッケージがリストアップされるのでそいつらを次のコマンドで追い出す。

sudo apt-get purge パッケージなにがし

  1. その後再インストールする。

sudo apt-get install パッケージなにがし

  1. linux-serverとかカーネルイメージも消して再インストールはセフセフ。メモリ上にロードされてるからその間は大丈夫。
  2. もちろんこの間にマシン再起動してしまったら・・・・④に進む
③apt-get purgeで最後にリストが出てきてシステムぶっ壊れてもいい?やる場合はsay yes yah!とかなんとか言われて怖い場合

システムの根幹のパッケージまで消してしまう場合はそんなことが言われます。

  1. しょうが無いのでリストアップされた連中の依存関係を無視して削除する。

sudo dpkg -r --force-depends パッケージなにがし

  1. 全部消し終わったら

sudo apt-get install -f

  1. もういちど消した連中の存在確認もかねてインストールしておく。

sudo apt-get install パッケージなにがし

  1. もちろん設定ファイルがなくなったり、パーミッションが初期化されたりするので頑張ってください。
④うわーん起動すらしなくなっちゃったよ〇〇えも〜ん

起動に必要なパッケージが消えた状態で再起動してしまったよおっかさん状態ですね。

  1. インストールしているUbuntuと同じか非常に近いインストールisoイメージを用意する。
    1. 実機の場合はUSBメモリに起動ディスクとして用意する。
    2. カーネルバージョンさえ合えば別ディストリでも出来なくはないだろうが怖くてやってない。
  2. でライブCDとしてUbuntuを起動する。(Ubuntuを試すのほうね。)
  3. 起動したら必要なパッケージを入れる。
    1. 個人的には以後SSH経由でターミナル開いて使い慣れたキーボードとコピペ生活をしたいのでSSHを入れる。
    2. あとLVM使ってたらlvm2も入れてvgconfig -aだっけか?でボリュームを見えるようにしておく。
  4. どっか適当なところにマウントしてchrootを行う。

sudo mount /dev/vda5 /mnt
sudo mount /dev/vda1 /mnt/boot
sudo mount -o bind /proc /mnt/proc
sudo mount -o bind /dev /mnt/dev
sudo mount -o bind /dev/ptc /mnt/dev/ptc
sudo mount -o bind /sys /mnt/sys
sudo cp /etc/resolv.cof /mnt/etc/resolv.cof
sudo chroot /mnt /bin/bash

  1. このあとは普通にapt-get updateしてapt-get install -fから始めれば良い。

まあそんな感じで復旧できます。

最新版Wacom Intuos ProをUbuntuで使う。

以下、自己責任で。自己責任だよー、Take your own risk!

Ubuntu 13.10にて

14.04使いたいけどアップグレードがまだできないですしおすし

ここに書いてあることの斜め読み受け売り

http://forums.linuxmint.com/viewtopic.php?f=42&t=110408

最新版をGet
http://sourceforge.net/projects/linuxwacom/files/xf86-input-wacom/
xf86-input-wacom-0.24.0だった。

以下のコマンドを流す。

sudo apt-get update
sudo apt-get install build-essential libX11-dev libxi-dev x11proto-input-dev xserver-xorg-dev libxrandr-dev libncurses5-dev autoconf libtool libxinerama-dev libudev-dev
sudo apt-get upgrade
uname -r

もとに戻せるようにバックアップ

cd /lib/modules/3.11.0-19-generic/kernel/drivers/input/tablet/
sudo cp wacom.ko wacom.ko.bk

さあ、インストール

tar xjvf xf86-input-wacom-0.24.0.tar.bz2
cd xf86-input-wacom-0.24.0
./configure --prefix=/usr
make
sudo make install

最後に

sudo reboot

動かなかった・・・

ちょうどそこに、14.04に上げないか?のラブコールが!
いや、やっちゃいますよ?
というわけで、やるが...動かない。

IntuosProは動くようになった・・・肝心のモニタが動かない。
AMDのドライバがダメらしく、最終的に真っ黒の画面になる。
しかし、その前の画面で辛うじてボタンとウィンドウが出てくる画面・・・ここではIntuosProでカーソルが動く・・・

最新版ドライバ(Catalyst14.3Beta)を入れること10回、
ようやくモニタが映る用意なった・・・・

まあ結果良ければ全て良し!

一応、13.10では動かなかった報告。しかし,
14.04にできれば動く。それはもう快適に。

Dockerを使ってみて。

とにかく時間がないのは半分こいつのせいだが感想を書いておく。

Versionは7.2、CentOS6.5に乗っかているやつである。

前提

  • SSDを使っている
  • docker buildコマンドは使ってない。
    • なのでまあ初期実行スクリプトを書いてそいつを呼ぶ起動方式がいい。

docker run -i -d -t base /bin/bash /start.sh

利点

  • VMの上でVMみたいなのを営巣できる。
    • root権限さえあればなんとでもなるぜひゃっはー
  • 起動は速い
    • とは言えストレージに負荷がかかるように思う(HDDだと速度はかなり遅くなるような気がする。)
    • 起動が速いので高速量産が可能
  • メモリ使用量は格段に小さい。
    • あとサイズを基本制限する必要が無いので、決定が不要でオーバーコミットに似た気軽さがある。
  • サイズは小さい
    • 配布されているイメージはUbuntuで175MB、CentOSで300MBではある。
      • 中に本当に必要最低限の物しか入ってないので要注意。ubuntuにはviすらなかった。
      • なのでモデルのイメージをまず作るのがめんどくさい。
    • が、使っているうちにだいたい2GB前後には成る(差分保管なのでimageの数の割にはサイズは少ない)
  • バージョン管理は便利
    • こまめにcommitとrunをしていればやり直しは非常に簡単である。
  • イメージの持ち運びも比較的簡単に出来る。
    • ファイルにエクスポートしてインポートが可能

制限事項

  • x64のみサポート
    • 一応ARMで動くらしいが・・・
  • サービスの呼び出しがとにかく普通にできない。起動スクリプトを書く前提で以下の制約がかかる。
    • service コマンド startとか駄目、/etc/init.d/なんか startとかならOK。
    • でもsshは/usr/sbin/sshd -Dとか最後に書かないといけない。&をつけるとコケる。
  • CRONがうまく動かない。
    • CRONDを起動しても動いてくれないみたいな。
    • そこはshellで何とかするしかないんだけどそれも不完全・・・方法は何があるか考える必要が
  • IPアドレスがRUNの度インクリメントしていく
  • FUSEというかmount周りが現状使えない
    • Ubuntuのupdateやバージョンアップでハマる
    • この場合、該当のパッケージ(initscript,ifdown等)をapt-get installで先にアップデートすればOK
    • なのでsshfsとかnfsとかcifsとかいろいろ使えない。
      • データの安全な共有はDBかKVS経由出やるしか無いのではと思われる。
  • ライブマイグレーションができない。
    • KVMとかXENは普通にできるので、出来るようになると嬉しいが原理的に難しい?
  • 環境変数がめんどくさい
    • まあ/etc/profile.d/env.shとかでexportしたら大丈夫ではある。
    • Ubuntuはちょっと微妙。多分書くとこ間違ってるので反映されない。
  • ポートをホストにバインドできるが、外からアクセスさせるにはiptablesのフォワード設定が必要
    • もちろん、ipv4のパケットフォワードの設定もホストに必要。
  • コンテナ間通信がめんどくさい
    • コンテナに名前は起動時に設定できるが、コンテナ内部からはわからない。
    • linkオプションがあるが互いに名前が判明している限りに於いてのみ有効
      • 要するにアドホックに立ち上がってコンテナが自分の名前は何か知るすべはない。
      • この辺に於いてSerfとかが好まれるのではと思う。
    • DDNSでも立てて内部スクリプトを書いて起動引数に独自に名前を与えるしかないような気もする。
    • ホスト名がコンテナID
      • なので、起動したらそこからDockerホストに問い合わせて名前を確定→DDNSに登録と言うのが順当ではと思われる。
    • コンテナから見てDockerホストのIPアドレスは一定だが、そのIPを指定してバインドされたポート経由で他のコンテナとの通信はできない。
      • 多分ルーティングテーブルと絡みがありそう。
    • とは言え、相手のコンテナIPアドレスがわかっていれば通信は可能。

用途

  • 最新のブラウザを使ったヘッドレステスト環境
    • あっさりできて嬉しい。Ubuntuコンテナに最新アップデートをあててXvfbとx11vncとfluxboxとFirefox,chrome入れたらできた。
  • DB,AP鯖
    • 普通。難しくはない。
    • ただしマウントができないのはかなりきつい制約でもある。IOの分散がホスト依存に成るのがめんどくさい。
  • 大量同一環境の養殖
    • VM上に営巣できるので、Dockerのイメージ保管場所を共有ディスクにぶち込んでVM自体バンバン増やすことでできる。
      • ただし、マシン間通信と誰が何が出来るかの管理はネック。ブリッジ経由で外とつながるようだが・・・DHCPでIPを与えられるらしいが不明。

目指す地平線

問題はここ。アプリの作動する基盤がお手軽に用意が可能で、しかもその性質はイメージが同じであればほぼ同等、均質。なのでなんとかいろんなマシンを一瞬で利用可能にする可能性を秘めている。
もちろんOpenStackとかでもいいんだけど、コンテナの専有リソースが劇的に少なく、かつ分離も出来るのもいい。なのでその用途に強いアプリならいいのではと思う。問題はその力が発揮される適当なマシンが無いのが辛い。
理想を言えば、小さくて省電力でIOの太いスティック状のウェアラブルなメイニーコアマシンを二桁ほど身につけてウェアラブルグリッドを構成してその上で上記のDockerリモートAPIを使ってイメージをとっ替えひっ変えしながら面白いことが出来ればと思う。それはARの踊る第二現実をHMD越しに見るいわゆるネットスフィアの走りであり、クラウドも重要なんだけどコストと回線がネックに成るその時に。ただ、結局いつもネックに成るのは排熱と電熱効率で、現在の省電力技術の流れではなく、フルロードで24時間以上稼働が衣服の下で可能であるというのが条件なのだが・・・・難しい。

出来ると嬉しいこと

上記を踏まえて欲しいのはDockerOnDockerとかLXConLXCができればなと。何が言いたいかというと、この世にPCを駆逐しながら広がるデバイススマホのことである。自由のないiOSは於いておくとして、AndroidにはDebianKitという神がかったアプリがあってここでUbuntuユーザランドが使える。Kernelの3.10あたりでDockerは作動するので、次の次ぐらいのAndroidのLinuxKernelで動くのではないかと推測される。
このDebianKitはまあChrootなのでLXC相当になるので、そこで動けばー、スマホでDockerグリッドが作動可能に成る。夢が広がるのである。

複数マシンがあること。
  • 生のマシン:OS、ソフトをHDDにインストールがめんどくさい
  • 仮想マシン:イメージをコピーするだけ、でも設定の移動、管理が面倒くさい、イメージがでかい(10000MBオーダー)
  • Dockerコンテナ:すぐに生まれるし(10秒ぐらい)、すぐに殺せる(30秒ぐらい)、小さい(1000MBオーダー)

よいよ環境の取り扱いが楽になり連携がしやすく成る未来を感じる。
問題はさせる仕事がないという現実。それにしてもShellはなんだかんだ言って便利であると痛感する。

MansikiPainterを公開

やったこと

次のリンクにいけば試せるようになった。
http://www.mansiki.com/MansikiPainter/Mansiki2014/paint.html#

状況

はい、ちまちまがんばります。

MansikiPainter思わぬ強敵

衝撃的なソフトウェアががが

こんなものが発売されているなんて・・・しかも800円とか安すぎる・・・
コミック工房│COLLAVIER

被っているコンセプト
  1. モバイルで漫画がかける=空いた時間で作業が出来る
  2. ネームもサポート

ヤバイ、何より先客には現物がある。マジやばい。

かぶっていない点(構想、妄想、未実装も含む)

きっと次の部分で勝負が出来るに違いない

  1. テキストから起こそうストーリー
  2. 印刷まで見据えたGimp連携
  3. 同期はP2Pでシームレス
  4. ストレージは青天井
  5. FirefoxChromeが動けば動くクロスプラットフォーム

うん、きっとそうだ、そうに違いない!

とは言え、ちゃんと商品に成るだけあって考えられているので参考になります。とても。

  1. やっぱりコマ単位で拡大して編集したいよね
  2. コマテンプレートは必要だよね

GitHubに公開しました。

GitHub - ryunosinfx/MansikiPainter: P2P HTML5 Paint Tool for Manga Name Making.
横着してREADME.mdもLISENCEも書いていませんが、MITとGPLV3のデュアルライセンスです。
はい、まだ何もできませんが頑張っていいきたいと思います。
目指せ、2/2のコミティアに間に合わせるがために!

すんちょぐだめでず

作っているツールの利用シーン

  • タブレットでブックマークを開けば、インストールは終わり。
  • どこでもタブレットでネームを描く!
  • オフラインHTML5アプリです
  • 通信機能はありません
  • ファイルを吐くのでそれで外部と連携
    • 将来的にはWebscoket->WebRTCで連携
  • Gimpさんのスクリプトも用意したいよね。

現状

現在はちょっとづつ進めたいところ

  • DONE 画面サイズプルダウン
  • DONE 画面サイズプルダウン デフォルト
  • DONE 枠線背景
  • TODO 複数ページ情報表示
  • DONE 色選択
  • TODO 複数ページ切り替え
  • TODO 筆圧感知
  • TODO 複数ページ一括エクスポート、インポート
  • TODO 固定メニュー
  • DONE スクロールオフセット対応
  • TODO 作品設定
  • TODO 固有設定
  • TODO テキストデータ入力
  • TODO サムネイル表示:ページ一覧

目指すべきゴール(今見えている地平線)

上に上げている他

  • Githubに上げる
  • 通信機能
  • テキスト情報入力

ターゲット

TegraNote7などペン入力が出来るタブレット端末
かつFirefoxChromeが動く端末。iOSはしらん。Iなんとかというのも知らない。
まあ、コミティアに間に合うのだろうか。

Mansiki仕切りなおし構想:テキスト編

なにゆえコレをつくろうとしたか

Twitterスタイルを使ってみたが・・・これが使いにくい

  • 文字の密度が全然足りない。
  • やはりまどろっこしい
  • 結局使うのに励起エネルギーが相当必要で挫折する。

実現したいこと

  • いつでもどこでもワンソースアクセス。
  • 軽い挙動
    • 10000行をターゲットに
  • わかりやすい表示
    • とはいえ精々アイコンと背景色+行番号が限界の予感
    • もうそこはキャンバスなんだと思う。

本当はやりたいけど高度すぎて難しいこと

  • コードハイライティングエディタ
    • DOMベースで作成するのはDOMオブジェクトが爆発的に増えて難しい
    • GitHubの実装を見ると不可能ではなさそうだが・・・
    • Canvasで描くのが現実的だが・・・

https://github.com/ajaxorg/ace
コレを改造するのが地道かな・・・
と思ったが、やはり実装が重い