ICON of RYUUO.COM TradeMark

[FKR]ウェブマスターBLOG

会員登録(SSL)
会員専用(SSL)

キーワード検索
AND検索 OR検索
リンク
袋小路展示館
世相批評募集


カテゴリー
WebYuumo(3)
mail_server(1)
lfs(4)
tomcat6_mysql5.1(5)
yuumo-0.0.0.0(2)
Gstreamer-1(2)
aokabu-1.2.9(7)
gtk(NO.1)(1)
programing(3)
サーバ履歴(19)
フィルター機能(2)


年次
2010(07-09月)
2010(04-06月)
2010(01-03月)
2009(10-12月)
2009(07-09月)
2009(01-03月)
2008(10-12月)
2008(04-06月)
2007(10-12月)
2007(01-03月)
2006(10-12月)
2006(07-09月)
2006(04-06月)
2006(01-03月)
2005(10-12月)
2005(04-06月)
2005(01-03月)

lfs

0

runlevel3 を試みた無駄な一日
# vi /etc/inittab を変更

id:3:initdefault:
#id:5:initdefault:

# vi ~/.bash_profileに付け加える

LANG=ja_JP.UTF-8
XMODIFIERS='@im=ibus'

# reboot

login: *******
passwd ------

$ set
WINDOWPATH=7
XAUTHORITY=/home/seven/.Xauthority
XMODIFIERS=@im=ibus   <----確認
colors=/etc/DIR_COLORS


$ startx

X 上のコンソールから

$ set

XMODIFIERS='@im=ibus'
の部分が消え失せている。emacs以外のeditorはAnthyが働く。が、emacsではAnthyのアイコンが出ず。その上、deactive注意が出現。 ここで、.emacsを修正するとCtrl+spaceでanthyが働くが app毎の別々な入力方式はダサい!


$ set XMODIFIERS=@im=ibus; emacs &
$ XMODIFIERS=@im=ibus; emacs &
又は、
$ vi ~/.bashrc に以下を追加
alias emacs='XMODIFIERS="@im=ibus" emacs'

コンソールからは他のapp同様の入力方式が可能だが、パネル上のアイコンからの起動は上手くいかない。
今日はここまでにしよう。
Linux From Scratchで、im-chooser imsetting で躓き、imputmethod の働きを調べて見ただけなのだ。
あとは、ほとんど問題ないように思えた。
runlevel 3
の使用しているユーザーが少なくなってきていることも確かだが・・・・・
.xsessionなり、.xinitrcが働かない。gdm, Xdmなどの影響なのかもしれない。

(2010-04-04 16:14:04) Category:lfs




lfs-6.5 75%達成
2月初めから取りかかったLFS並びにBLFS、ようやく日本語も使用できるようになりFedoraと比較すると75点ぐらいのところまで来た。

最初はChangeRoot下でcompileを行っていたが、Xに入れるようになってからモッパラLFS上でコンパイルし続けていた。Gnomeをインストールするのに、複雑というか、どのプログラムがどのソースから成り立っているのか、また、どこに問題が存在しているのか、がはっきりと区別できないところに時間を費やしたような気もする。

(2010-03-30 16:16:16) Category:lfs




lfsのみ先ずは終了
LinuxFromScratchをInstallし終えた。ほとんど問題なく終了した。強いて言えば、Ed-0.8 のヴァージョンを Ed-1.4に上げたことだけだろう。compile出来ずに行った。RedHat 7.2だと思うがその当時一度kernelのコンパイルを行って、時間が異常な程掛かったことを経験していたので、多少の覚悟はあったが、やはり、覚悟以上の経験をした。

現在はX(sawfish)を立ち上げるところまでいたっているが、blfsについては後日、記すことにする。こちらは依存関係などの関係で所々停滞する時間を要している。

(2010-03-01 08:34:54) Category:lfs




LFS
条件: sda and sdb の2個のHDDを搭載してある。以下 df コマンドで示すようにsdbはバックアップ用に使用していたが、Linux From Scrachを来年2010年に行う予定でいるので、sdbを分割し、その一つのpartitionにLinux From Scrachの領域を確保する
のが狙いだ。
今まで、rescue modeを使用し回復させたことを思い出してみると/etc/fstabの修正間違いがほとんどのようである。今回も例に漏れずrescue modeを使用した。その時の失敗を兼ねての記述であるが、今後、またfstabのファイルの修正が必要になった時には仕様が変更されているかもしれない。これはfstab fileを普段あまり使用(注視)していないことからも理解できる。それ故、使用にせまられた時には変更されているというのが私の実感だ。


/dev/sdb1 76896316 1770600 71219516 3% /export
/dev/sda1 101086 44310 51557 47% /boot
tmpfs 1030548 596 1029952 1% /dev/shm
/dev/sda2 79356528 28632316 46628040 39% /home

# vi /etc/fstab

#
# /etc/fstab
# Created by anaconda on Tue Apr 14 05:59:34 2009
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or vol_id(8) for more info
#
UUID=1299e4e9-3cc4-44fa-9c02-1c2e275cd5d6 / ext3 defaults 1 1
UUID=f62bea75-f7b8-4094-adf0-368b37b915c5 /export ext3 defaults 1 2
UUID=9f79e4f7-5265-4155-9ba6-319d10547222 /boot ext3 defaults 1 2
devpts /dev/pts devpts gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs defaults 0 0
UUID=de4f1328-d130-4bcb-8706-7d61606cf306 /home ext3 defaults,usrquota 1 2
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
LABEL=SWAP-sda3 swap swap defaults 0 0

#/dev/sr0 /media/dvd udf,iso9660 user,noauto,exec,utf8 0 0
/dev/sr0 /media/dvd udf,iso9660 rw,users,noauto,exec 0 0
/dev/sdc /media/usb1 vfat,iso9660 noauto,user,iocharset=utf8 0 0
/dev/sdd1 /media/usb2 vfat,iso9660 noauto,user,iocharset=utf8 0 0



UUIDなるものが記述されているというのは分かっていたのだが、UUIDが何者かはまったく理解していないかった。記憶に残るなかで、詳しくfstabについて調べたのはLABELの表記方法の時だった。/dev/sdb1すなわち/exportをfdisk コマンドで基本領域・拡張領域とに分割、mkfs コマンドでフォーマット、そして、起動時にこれら領域がmountされるようにfstab fileを修正、・・・で失敗したのである。一言でいえば、UUIDの処理が分からなかったことが第一の理由だ。
結果は起動できず、rescue modeでの復旧だった。まずは/export領域を元に戻し、fstabの修正に取りかかる。

スワップ領域にLABELの文字が見え、それを便りにLABEL表記に変更、まずは起動に成功した。今でも、LABELは使用できる。

# e2label /dev/sda2
== 何も表記されない ==
#

# e2label /dev/sda2 /home
# e2label /dev/sdb1 / export
# e2label /dev/sda2
/home
#
# vi /etc/fstab ... 修正

LABEL=/export /export ext3 defaults 1 2
LABEL=/home /home ext3 defaults,usrquota 1 2


修正後、無事起動できた。これで何やかんやと半日潰れた。
翌日、頭をリフレッシュさせ、現在のファイルシステムラベル(UUID方式)を表示方法をWEB上で調べると何と/dev/disk/by-uuidのdirectory内にUUIDが記述されていたではないか。
このUUIDを使い、もとの状態に戻した。





# ls -l /dev/disk/by-uuid
lrwxrwxrwx 1 ** ** 10 2009-11-29 08:10
9f79e4f7-5265-4155-9ba6-319d10547222 -> ../../sda1
lrwxrwxrwx 1 ** ** 10 2009-11-29 08:10
de4f1328-d130-4bcb-8706-7d61606cf306 -> ../../sda2
lrwxrwxrwx 1 ** ** 10 2009-11-29 08:10
f62bea75-f7b8-4094-adf0-368b37b915c5 -> ../../sdb1





気を改め翌日、新しいパーティションに挑戦。
# umount /export
# fdisk /dev/sdb

このディスクのシリンダ数は 9726 に設定されています。
間違いではないのですが、1024 を超えているため、以下の場合
に問題を生じうる事を確認しましょう:
1) ブート時に実行するソフトウェア (例. バージョンが古い LILO)
2) 別の OS のブートやパーティション作成ソフト
(例. DOS FDISK, OS/2 FDISK)

======= 略 ======

コマンド (m でヘルプ): p

ディスク /dev/sdb: 80.0 GB, 80000000000 バイト
ヘッド 255, セクタ 63, シリンダ 9726
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
Disk identifier: 0x00000080

デバイス ブート 始点 終点 ブロック Id システム
/dev/sdb1 1 4800 38555968+ 83 Linux
/dev/sdb2 4801 9726 39568095 83 Linux

コマンド (m でヘルプ): w
領域テーブルは交換されました!

ioctl() を呼び出して領域テーブルを再読込みします。
ディスクを同期させます。
#
=== format ===

# mkfs -t ext3 /dev/sdb1
# mkfs -t ext3 /dev/sdb2


# ls -lF /dev/disk/by-uuid/
lrwxrwxrwx 1 root root 10 2009-11-29 11:11
1299e4e9-3cc4-44fa-9c02-1c2e275cd5d6 -> ../../sda5
lrwxrwxrwx 1 root root 10 2009-11-29 11:11
9f79e4f7-5265-4155-9ba6-319d10547222 -> ../../sda1
lrwxrwxrwx 1 root root 10 2009-11-29 12:38
b97efa4a-1d67-4515-9e20-1bb2c45f49c6 -> ../../sdb1
lrwxrwxrwx 1 root root 10 2009-11-29 12:39
bfeded6e-01d1-4c30-8696-655b57f6ec9a -> ../../sdb2
lrwxrwxrwx 1 root root 10 2009-11-29 11:11
de4f1328-d130-4bcb-8706-7d61606cf306 -> ../../sda2



/dev/sdb内の UUIDが表示されている。

/etc/fstab をUUIDを用いて書き換える。 あとは、reboot

これで漸く来年、私にとっては集大成にもなる Linux From Scrach を実行できる環境が出来上がった。

(2009-11-29 13:15:29) Category:lfs




0