横断歩道での一時停止は善意ではなく義務 (Powered by WordPress)
当サイトや，そのほかの筆者のメンテしているWSやserverのKernelを4.0.0にしました．
事前に言われているように，3.19からの続きで，番号だけ付け替えたような感じで，特に関連する管理ソフト類を更新する必要はありませんでした．
2.6.xから3.0になったときもそんな感じでしたが．
$ cat /proc/version Linux version 4.0.0-01 (root@je1sgh) (gcc version 4.8.3 (GCC) ) #26 SMP Mon Apr 20 18:22:13 JST 2015
なんとか，Slackware 64の自分ナイズについて，全体が見えたので，いったんまとめておきます．
Kernelについては，当初，自分でbuildしたkernel (3.19.0, 3.19.1)がモジュールを自動的にロードしないので困っていましたが，Slackware 64付属の.configを使うことで，解消しました．たぶん，force loadingとかいうオプションがONになることで解消したと思いますが，動けば良いので深くは追求してません．
Slackware 64付属の.configを使うことによる副作用は，ほとんどのモジュールをbuildしてしまうことですが，これも，たいした問題ではないので，放置します^^;
また，kernel のmakeで，build済みのオブジェクトも毎回コンパイルし直すようです．これも，大きな問題ではありません．
まだ，initrdを使う起動はうまくいっていません．が，それも使わなきゃ良いんです^^;;
ほとんど，Slackware (32bit)と変わりません．Slackwareに付いているソフトについては，SlackBuildでbuildできますし，含まれていないものも，通常のconfigureオプションでたいていbuildできます．
これが，最大の壁でした．いくつかの関連パッケージは，32bitよりもサクッとbuild & installできましたが，最後のvirt-managerがうまくいかず，あきらめました．
手動で，qemu-system_x86_64は起動するのに，virt-managerでは，使用できるエミュレーターがないというメッセージを出してお手上げです．
関連ソフトは，何巡かbuild & installしています．
多少の制約は残っても後々の問題として抱えたまま，できれば64bitに移行したかったのですが，今日では必須となってしまったKVM/QEMU環境が構築できなかったので，Slackware 64への切り替えは見送ることにしました．
もちろん，最初からKVM/QEMUが含まれている64bit distroを使えば良いだけのことなんですが，それじゃぁおもしろくないです．これまで蓄積してきたSlackwareによるserver/routerの運営ノウハウが活かせません．
というか，Slackwareが好きなんでしょうがない^^;
何を今さら感がありますが^^;
私がLinuxの64bit版をいじり始めたのはかなり昔で，某所に入ったAMDの64bit dual CPUのマシンにSLAMD64をインストールしていじっていました．もう10年も前になると思われます．
いろいろテストして分かったことは，
32bit版と比べて，ほとんどパフォーマンスの向上はなしで，まれに，1.5〜2倍速くなるソフトがある
という，ものでした．まだまだ出来損ないのディストリビューションの不便さに耐えて，たかだか2倍です^^; 特に当時は，CPUのジェネレーションが変われば，2倍以上のパフォーマンスの向上は普通にありましたから，64bit化は封印ということにしました．
ところがどっこい，最近は，CPUのジェネレーションが変わってもパフォーマンスが，格段に向上ということがなくなりました．そこで，その”2倍”が非常に魅力的になりました．
ということで，Slackware 14.1の64bit版をいじり始めました．インストールからX.orgの起動までは，微妙におかしなことがありましたが，大きな問題はなく進みました．
しかし，自分でKernelをbuildするところで，引っかかっています．もう少し苦闘して，体で覚えたいと思います^^;
案外簡単にできると言うことなので，チャレンジしてみました．
結論的には，ほぼ下記リンクのとおりやればうまくいきます．
まずは，armのエミュレーターをbuildします．QEMUのconfigureオプションを，
CFLAGS="-O2 -march=i486 -mtune=i686" \
./configure --prefix=/usr \
--target-list="x86_64-softmmu x86_64-linux-user i386-softmmu i386-linux-user \
arm-softmmu arm-linux-user" \
--enable-sdl \
--enable-usb-redir --enable-spice --enable-system
としてみました．
それから，kernel-qemuが必要です．
NOOBSから設定したRaspbianのSDから作ったイメージファイルraspbian.imgの起動コマンドは次のとおりでうまくいきました．
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio \ -append "root=/dev/sda6 panic=100 rootfstype=ext4 rw init=/bin/bash" -hda raspbian.img
しかし，コンソールからラインコマンド打ち込むのは便利ではないので，virt-managerから起動できないか，調べてみます．
前の話のまとめです．
これまで，実マシンとして動いていたLinux Work Station （以下WS1）を，実体として残しておく訳にはいかないけど，まったく捨ててしまうのももったいない．きっと，何か，二度と再現できないノウハウ的なものがあるかもしれない^^;
ディスクをイメージ化して保存し，しかも仮想マシンとして稼働できるようにしておけば，すばらしいです．
で，いろいろ試したところ，次の手順が一番よいと思います．
まず，どこのご家庭にもある，KVM内の既に稼働している仮想マシンを用意します．この仮想マシンに新たなディスクイメージを追加します．容量は，WS1のディスクサイズでもいいですし，実際に動作させるのに必要十分で最小容量でもいいです．形式は何でもいいですが，保存することを第一に考えれば，qcow2のsparse形式でしょうね．
次に，仮想マシンの第３ディスクとして，ホストマシンに接続した，WS1のHDDの実態を追加します．
そして，仮想マシンを起動して，/dev/sdbとなったディスクイメージをパーティショニングして，formatします．
さらに，formatしたイメージのメインの部分をどこかにマウントし，/dev/sdcとなった実ディスクのメインの部分もどこかにread onlyでマウントして，内容をまるまるコピーします．
コピーの方法はいろいろあるけど，最近はrsyncのみ使用してます．
コピーが終了したら，仮想マシンを停止して，その仮想マシンから，先ほど追加した，新しいディスクイメージと，実HDDを削除します．この際，間違っても，せっかく作成したディスクイメージを削除しないことです．”ディバイスリストから削除”するだけで，ディスクイメージは残します．
この新しく作成して実HDDからコピーしたディスクイメージで新たな仮想WSを作って起動させるわけですが，Kernelその他いろいろいじることもあるので，原型を止めたいということであれば，このイメージをどこか別に保存しておいたほうがいいでしょうね．
これは，いろいろやり方があると思います．私は100%，SlackwareのインストールDVDを使っています．
コピーの時点で，boot loaderを適切にインストールしていないので，多少の工夫が必要ですが，そのくらいのことは，Linuxをいじっている人には朝飯前でしょう．
これで，滅多に動かすことのなくなったWSの実体を心置きなく捨てることができます．