2011年7月13日星期三

CentOS(RHEL) 6 重投 scim 輸入法引擎懷抱 及 mock build 別權環境編譯

CentOS 6 已經官方釋出了, 當然已經實測體驗過 RHEL 6(及 6.1)的企鵝人應該不會陌生(upstart 的爽快起動, ext4 文件系統格式, 全 i686 編譯及 gnome 介面優化等等), 不過激進的 Redhat 已經將 ibus 輸入法引擎取代了 scim, 並且把 scim 源碼套件排除掉, 習慣了使用 scim 及其輸入法 tables 的話會是一個急煞停的刺痛, 當然企鵝人怎會甘願被紮捆, 可以借用 Fedora 15 的 scim 源碼套件移植到 CentOS6(RHEL 6)內使用。

CentOS 6(RHEL 6)的 mock 已經放置在 epel-6 的套件庫, 只是 mock config 內容針對及指向了 beta 套件庫, 手動修改後即可以執行 mock build 別權環境編譯, 另外 RHEL6(及 CentOS 6)光碟其實已經包含了 mock build 時需要的 buildsys-build group, 利用光碟位置還可以加快 mock yum 程序。


CentOS 6 官方釋出公告
http://lists.centos.org/pipermail/centos-announce/2011-July/017645.html

CentOS 6 版本文件資料
http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.0

CentOS 6 DVD 光碟下載 torrent
i386 DVD
http://mirror.centos.org/centos/6/isos/i386/CentOS-6.0-i386-bin-DVD.torrent
x86_64 DVD
http://mirror.centos.org/centos/6/isos/x86_64/CentOS-6.0-x86_64-bin-DVD.torrent

CentOS 6 安裝 mock build 別權環境編譯
  1. 安裝 mock 軟體套件
    登入 root 管理員帳號權限
    安裝 epel-6 yum 套件庫下載 epel-release-6-5.noarch.rpm
    • x86_64 系統的話, 執行
      # rpm -ivh http://download.fedora.redhat.com/pub/epel/6/x86_64/epel-release-6-5.noarch.rpm

      如果是 i386 系統的話, 執行
      # rpm -ivh http://download.fedora.redhat.com/pub/epel/6/i386/epel-release-6-5.noarch.rpm
    • 在線安裝 epel-6 的 mock 軟體套件
      # yum install mock
  1. 帳號設定
    新增帳戶加入 mock 用戶群(例如 tester 用戶帳號)
    # useradd -g users -G users,mock tester

    舊帳戶加入 mock 用戶群的話(例如 tester 用戶帳號)
    # usermod -a -G mock tester
  1. 配置 mock config 設定文件
    編輯修改 /etc/mock/epel-6-x86_64.cfg(及 /etc/mock/epel-6-i386.cfg) 內容
    將 [beta] 區段修改為(無效 comment)
    #[beta]
    #name=beta
    #mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rhel-5.90Server-beta&arch=x86_64
    將 [beta-optional] 區段修改為(無效 comment)
    #[beta-optional]
    #name=optional
    #mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rhel-optional-5.90Server-beta&arch=x86_64
    將 [base] 內的 enabled=0 修改為
    enabled=1
    將 [updates] 內的 enabled=0 修改為
    enabled=1

    • (如果使用 DVD 光碟為套件庫加快 mock yum 速度的話)
      可以將 [base] 區段修改為
      [base]
      name=BaseOS
      enabled=1
      baseurl=file:///media/cdrom/
  1. 建立本機 repostory
    如果需要使用自行建立的本機 repostory 編譯其他軟體的話(例如 /opt/localrepo.x86_64 及 /opt/localrepo.i386)
    編輯修改 /etc/mock/epel-6-x86_64.cfg
    將 [local] 區段修改為
    [local]
    name=local
    baseurl=file:///opt/localrepo.x86_64/
    cost=500
    enabled=1
    編輯修改 /etc/mock/epel-6-i386.cfg
    將 [local] 區段修改為
    [local]
    name=local
    baseurl=file:///opt/localrepo.i386/
    cost=500
    enabled=1
    建立本機 repository
    執行
    # mkdir /opt/localrepo.x86_64
    # mkdir /opt/localrepo.i386
    建立(更新)本機 repository 資料
    # createrepo -o /opt/localrepo.x86_64 /opt/localrepo.x86_64
    # createrepo -o /opt/localrepo.i386 /opt/localrepo.i386
    配置完成

mock 別權環境編譯測試
登入 mock 群組帳戶(例如 tester 帳戶), 執行
x86_64 系統的話
$ mock -r epel-6-x86_64 --resultdir=$HOME --init
x86_64 系統執行 i386 mock 的話
$ setarch i386 mock -r epel-6-i386 --resultdir=$HOME --init
i386 系統的話
$ mock -r epel-6-i386 --resultdir=$HOME --init
mock 完成後可以查看 mock 程序生成三個 log 日誌文件結果
build.log 是 compile 編譯源碼日誌
root.log 是 mock 環境架設執行日誌
state.log 是 mock 的狀態日誌

mock build 編譯軟體 scim
  1. 下載 Fedora 15 的 scim 源碼套件
    http://download.fedora.redhat.com/pub/fedora/linux/releases/15/Everything/source/SRPMS/
    包括:
    scim-1.4.9-8.fc15.src.rpm
    scim-bridge-0.4.16-6.fc15.src.rpm
    scim-tables-0.5.9-3.fc15.src.rpm
    scim-pinyin-0.5.91-28.fc15.src.rpm

    執行下載:
    $ wget http://download.fedora.redhat.com/pub/fedora/linux/releases/15/Everything/source/SRPMS/scim-1.4.9-8.fc15.src.rpm
    $ wget http://download.fedora.redhat.com/pub/fedora/linux/releases/15/Everything/source/SRPMS/scim-bridge-0.4.16-6.fc15.src.rpm
    $ wget http://download.fedora.redhat.com/pub/fedora/linux/releases/15/Everything/source/SRPMS/scim-tables-0.5.9-3.fc15.src.rpm
    $ wget http://download.fedora.redhat.com/pub/fedora/linux/releases/15/Everything/source/SRPMS/scim-pinyin-0.5.91-28.fc15.src.rpm
    其他的輸入法 tables 語言可個別下載
  1. 開始 mock build 編譯 scim (x86_64)
    首先編譯 x86_64 的 scim-1.4.9-8.fc15.src.rpm
    登入 mock 群組帳戶(例如 tester 帳戶), 執行
    $ mock -r epel-6-x86_64 --arch=x86_64 --resultdir=$HOME --rebuild scim-1.4.9-8.fc15.src.rpm
    完成 mock build 編譯(檢查 3 個 log 日誌確認)後把 scim-lib scim-devel 的 x86_64 rpm 套件放置到本機 repository 位置
    # cp -v /home/tester/scim-lib*x86_64.rpm /opt/localrepo.x86_64
    # cp -v /home/tester/scim-devel*x86_64.rpm /opt/localrepo.x86_64
    更新本機 repository 資料
    # createrepo -o /opt/localrepo.x86_64 /opt/localrepo.x86_64
    準備 scim-lib scim-devel 後 mock build 編譯 x86_64 的 scim 其他依靠源碼套件
    包括:
    scim-bridge-0.4.16-6.fc15.src.rpm
    scim-tables-0.5.9-3.fc15.src.rpm
    scim-pinyin-0.5.91-28.fc15.src.rpm
    登入 mock 群組帳戶(例如 tester 帳戶), 執行
    $ mock -r epel-6-x86_64 --arch=x86_64 --resultdir=$HOME --rebuild scim-bridge-0.4.16-6.fc15.src.rpm
    $ mock -r epel-6-x86_64 --arch=x86_64 --resultdir=$HOME --rebuild scim-tables-0.5.9-3.fc15.src.rpm
    $ mock -r epel-6-x86_64 --arch=x86_64 --resultdir=$HOME --rebuild scim-pinyin-0.5.91-28.fc15.src.rpm


完成後就可以將編譯結果生成的 scim rpm 安裝實機使用
包括:
scim-1.4.9-8.el6.x86_64.rpm
scim-libs-1.4.9-8.el6.x86_64.rpm
scim-gtk-1.4.9-8.el6.x86_64.rpm
scim-bridge-0.4.16-6.el6.x86_64.rpm
scim-bridge-gtk-0.4.16-6.el6.x86_64.rpm
scim-tables-0.5.9-3.el6.x86_64.rpm
scim-tables-chinese-0.5.9-3.el6.x86_64.rpm
scim-pinyin-0.5.91-28.el6.x86_64.rpm

安裝 scim 執行
# rpm -ivh rpm_file_name

設定使用 scim 輸入法引擎
登入 xorg 桌面
執行 im-chooser
選擇 scim
完成

備註:
  • mock-1.1.11-1.el6 在 CentOS 6(RHEL 6) 下執行時有一個小臭蟲, 在編譯前安裝要求套件時, 如果要求的套件在 [base] 及其他 repository 中有相同名稱相同版本的話, 會預設安裝 [base] 內的套件, 就算加入 cost=xxx 優先次序(或順序排列)亦無效, 唯一辦法是在 [base] 內加入 exclude= 項目來排除誤裝相同名稱套件(已實測)。
  • 如果執行 mock 時使用了錯誤 [base] repository(例如 i386 使用了 x86_64)的話, 因為已經 cache 緩存而失敗無法再 yum 成功, 解決辦法是刪除清空 mock cache 緩存目錄 /var/cache/mock/ 。
  • RHEL 5(CentOS 5)系統內無法使用 mock build 編譯 CentOS 6(RHEL 6)的源碼套件, 主要原因是 RHEL5 的 rpm-lib 軟體版本不向上兼容 RHEL6 的 rpm 軟體套件包(已實測), 反之 RHEL6 系統內卻可以 mock build 編譯 RHEL5 的源碼套件。

2011年6月12日星期日

拔除 ORZ 迷信: SSD 用了一整年後效能下降很大嗎?

一年容易過龍舟(已過端午節了), Computex 2011展品戰場也完結, 今年 SSD 滿大片海潮般的遍地開花, 25nm NAND Flash 顆粒製程的散貨潮也展開了數個月多, 成本下降除了手機及平板熱也造就一片 SSD 繁榮景象, 阿貓阿狗廠商也要推出 SSD 或其相關軟硬體進入大餅市場, 當然不免出現大量行銷洗地河蟹槍手, 還有一群人云亦云的忠心門徒(利益所在財可通神嘛); 經常有朋友及同事在採購SSD 時會懷疑及擔心 SSD 使用後的效能下降很大, 甚至某某品牌降速快, 某某品牌技不如人, 某某品牌包山包海軟體一流服務等等, 這個也拜謝行銷槍手們啼笑皆非的吹捧秀, 也難怪會繼25nm 混雜 34nm 販售神仙過海後. 被踢爆封裝用白牌顆粒、ES 控、鎖文刪文狀告無下文的, 甚至近日的 2.06藍屏失蹤事件也見 ORZ 河蟹洗地。

在去年六月時採購了 SSD 使用, 到現在(今天)已經差不多一年了, 那麼到底近代(34nm)的 SSD 在長時間使用後效能下降很大嗎? 這個人云亦云迷信是時候考證, 剛剛在休閒星期天執行了一次 AS SSD 效能測驗, 以驗證一顆SSD 固態硬碟在一般個人應用環境使用一年後(每天八小時以上)的真實效能, 實機是一台 DIY 組裝電腦, 南橋晶片組是 Intel ICH10R, SSD 固態硬碟是 ADATA SSD S599 100GB, firmware 由 3.0.5 更新為 3.4.6, 運行 AHCI 模式, SSD 為系統 C 碟, HDD 為資料碟, 作業系統 Windows 7(包括 SSD 效能優化進階)。

ADATA SSD S599 100GB(3.4.6) 系統 C 碟一年使用後 AS SSD 效能

參考比較
ADATA SSD S599 100GB(3.0.2A) 資料碟空盤 AS SSD 效能


比較效能數值明顯的 Sequential write 下降大約 ~9%, 這個是 SSD 當了系統 C 盤, 也佔用了 ~68% 容量空間, 而且整整一年沒有執行磁碟重組(這個足夠證明 SSD 是不需要磁碟重組的), 其他有的無的效能上升應該是 firmware 升級 (3.0.2A 是 RC 初版)和使用了 Intel RST 驅動程式的情況; 個人在日常使用的情況中仍然是一個爽快度, 不過…用過 SSD 的腦惱人是不願意重回 HDD 系統碟的懷抱了吧, 至於舊 SSD 消費者是否有需要採購升級到 SATA 6Gbps,要視乎個人實際因素, 25nm 顆粒的壽命週期短已是事實(去年採購了 34nm 顆粒 SSD 的已經賺很大啊), SSD 新主控晶片(支援 SATA 6Gbps)始終要經過消費市場考驗, 除錯是不能或缺, 晶片由 ES 工程到 A1 過渡 A3 版本才見成熟, 當 SSD 傳輸速度到達一個高速的臨界點時, 新技術也難免有臭蟲缺陷, 更高速的 SSD 在受限電腦執行程式的速度, 個人感受的爽度已不會有大驚喜, 擔心 SSD 效能下降不如擔心穩定度, 電腦主機板硬體兼容性(尤其是 ACPI power management)也不是所有廠商一模一樣, 起碼消費者買下 SSD 就是要使用, 不是買來當廠商老鼠磚塊藍屏鏡, 未來 SSD 普及的障礙是 NAND Flash 顆粒的壽命週期了(當然還包括水果公司的採購大單啊), Intel 新晶片組 Z68 的電腦主機板包含了 ISRT(Intel Smart Response Technology) 技術, 利用 SSD 和 HDD 組建混合硬碟系統平台, 對於細容量 SSD 入門級的用戶也是個不錯的整體升級選擇方案。

補圖:
Adata SSD S599 100GB 實機使用一年後 SSD 的真實 Smart(Everest) 部分可參考屬性資料
  • (09)Power-On Time Count 通電使用時間 「5209 小時」
  • (0C)Power Cycle Count 通電次數 「801」
  • (F1)lifetime write froms host 已寫入數據量總數 「320 GiB」
  • (F2)lifetime write froms host 已讀取數據量總數 「3776 GiB」
以使用了一年後 380 天計筭, 每天平均通電使用了 5209/380 = 13.7 小時
每小時平均寫入了 320*1024/5209 = 62.9MB
每一分鐘平均寫入了 320*1024/5209/60 = 1.05MB (進階優化後的不錯啊 ^^!)
每小時平均讀取了 3776*1024/5209 = 742.3MB
每一分鐘平均讀取了 3776*1024/5209/60 = 12.37MB (快速讀取好處啊)

溫馨提示:
  • 今年近月來市場上的 SSD 銷量有大幅爬升的趨勢, 明顯 25nm NAND flash 顆粒成本下降造成產品多樣化及 SATA 6Gbps 效能提升, 企業及私人公司考慮採用 SSD 方案提升員工效率及其系統升級, 而且大量單位採購數字也十分驚人, 腦場或多或小的會突然出現供應缺貨的情況, 而且筆電 Notebook 也有了配置 SSD 的型號及其支援優化軟體(例如 Lenovo 聯想 的 Thinkpad Edge E420s/E220s 系列)。
  • Toshiba(東芝) 及 SanDisk 去年共同投資在日市三重縣興建的 NAND Flash 晶圓廠「Fab 5」已經落成, 開始正式投入量產, 投產的是 24nm NAND flash 將預計在 2011年第三季中出貨, 未來還會提升至 19nm 進程技術; 到今年第四季初時將會有 NAND flash 顆粒的成本較勁, 年底時市場上的 SSD 成本將受壓下降。

2011年6月1日星期三

CentOS 6 猜測六月內釋出

渡過了一整個靜寂宅懶的五月, 這個端午節的六月除了 Computex 2011、Mac粉果中地雷一串事件、夏天來臨不要亂飲亂吃(尤其是致癌 DEHP 買不到是您的短暫福氣)等等外, 另一個企鵝人及系統支援人員要注意的是事, 都已經等待了六個多月後 CentOS 6(RHEL 6 的 clone 版)即將進入 QA 階段, 發佈日程雖然不確定(亦不準確), 但是在無 ETA 預言及小缺失修正下大約會在六月分內釋出, 消息來自 CentOS 社群開發組 blog 文章。

當然仍然使用老技術(F6)舊系統的 CentOS 5.x 用戶是不一定需要升級到版本 6 的, 在穩定的前題下, 大升級難免會有陣痛期, 可能會有或多或小的不預期影響, 如果系統是用於 Production 機器環境的話, 必須有更周詳策劃, 機器(電腦)舊的硬體會因為軟體技術改變(和沒有官方驅動程式)而發生不支援的問題, 如果考慮到整個方案升級的話(包括硬體及軟體), 選擇較新技術的版本是更適合不過的。

另外, RHEL 6 已經無法安裝在只得 256MB 記憶體的老舊電腦內, 是時候放棄它們吧。

2011年4月13日星期三

CentOS 5.6 升級更新 scim 1.4.4-44.el5 後出現 segmentation fault

自 CentOS 5.6 釋出的升級後數天內, 多台使用 xorg 桌面時都發生奇怪的狀態, 當要執行的桌面應用程式時會無法啟動而立即關閉, 查看系統 log 後(dmesg)發現出現 segfault(segmentation fault)錯誤信息, 尤其是 scim-launcher 及 xterm。
經過再三的實測後, 發現是近日在線 yum 升級了 scim 及 scim-libs 造成的問題(CentOS 5.6 光碟並沒有 scim 升級), scim 及 scim-libs 由 1.4.4-41.el5 升級到 1.4.4-44.el5 後, 當 scim 應用介面啟動後, 其他 gtk 程式(例如 firefox)觸發了 scim, xterm 就必定不能正常執行, 會出現 memory segmentation fault 及立即關閉, 而且在系統 log 中會出現 scim-launcher 及 xterm 的 segfault 錯誤信息, 原因不明。
暫時解決辦法是「回復 scim 舊版本 1.4.4-41.el5(已實測)」:
  • 登出 xorg 桌面
  • 移除 scim 及 scim-libs
    # yum remove scim scim-libs
  • 在線安裝 scim 及 scim-libs 舊版本 1.4.4-41.el5 及中文輸入法支援
    # yum --disablerepo=updates groupinstall 'Chinese Support'
  • 登入 xorg 桌面生效

Linux...還是那樣的非一般系統!

補充:
  • CentOS 社群已在五月四日把 scim 及 scim-lib 版本 1.4.4-44.el5 移回 fasttrack repository, 暫時不會再出現在 updates, 下一次主版本(或許 5.7)更新時要多注意。

2011年4月7日星期四

CentOS 5.6 嘗鮮鏡像下載 mirror download

自 RHEL 5.6 官方釋出後都已經超過兩個月的漫長等待了, CentOS 5.6 社群商業版近日已經完成 QA 質量除錯進入鏡像同步階段, 一眾苦守用戶不欲再等待官方公告的話可以嘗鮮下載 CentOS 5.6。

下載位置:
32bit i386
http://isoredirect.centos.org/centos/5.6/isos/i386/
64bit x86_64
http://isoredirect.centos.org/centos/5.6/isos/x86_64/

Torrent 下載:
32bit i386 CD
32bit i386 DVD
64bit x86_64 CD
64bit x86_64 DVD

CentOS 5.6 官方正式發佈公告 Fri Apr 8 19:16:30 EDT 2011
http://lists.centos.org/pipermail/centos-announce/2011-April/017282.html

又是時候再參考 CentOS 5.4 光碟 yum 升級快過火箭升空


備註:
  • CentOS(RHEL) 5.5/5.6 的 Anaconda 安裝程式預設不會啟動 ext4 文件系統格式, 在預設安裝系統時不能選擇格化 ext4 文件系統格式, 要在安裝時格化 ext4 分割區的話, 在 bootup 畫面中鍵入 linux ext4 語句, 則可以令 Anaconda 安裝程式啟用格化 ext4 了(如果系統中已經有已格化的 ext4 分割區的話, Anaconda 亦可以自動掛載支援安裝到 ext4 分割區)。
  • 安裝 ext4 文件系統格式的話, RHEL 5.5/5.6 不能支援 boot 分割區為 ext4。
  • 安裝根目錄 / 為 ext4 文件系統格式的話, gnome 桌面的回收筒會缺失功能, 需要自行修改編譯 gnome-vfs 的 patch 補丁。
  • RHEL 5.6 要完全停用掛載 ipv6 modules 的話, 需要額外在 /etc/modprobe.conf 系統文件加入語句 options ipv6 disable=1
  • CentOS(RHEL) 5.6 安裝及升級會自動掛載 iscsi modules, 沒有 iscsi 裝置的話可以停用 iscsi 及 iscsid 服務來移除 iscsi 支援
    chkconfig iscsi off
    chkconfig iscsid off

2011年3月9日星期三

CentOS(RHEL)5 Mock build 的別權模擬編譯環境下修改再編譯的 dependency 問題

CentOS(RHEL, Fedora) 的 RPM base 下 mock build 的模擬編譯環境應用技術不是特許新鮮物, 一般終端電腦用戶其實也無需認識其編譯技術理念(尤其是習慣使用 Windows 的門徒), 模擬編譯環境適合編程人員或系統管理員及高階企鵝族, 在下列所提及的實際問題情況前要瞭解 Mock 應用技術可參考 Fedora Project 內 Mock 資料。Mock build 的模擬編譯環境一般都是用於再編譯(Re-compilation)處理, 例如將 abc.src.rpm 源碼套件再編譯打包到其他的 RPM base 系統(RHEL, Fedora 等等), 此類再編譯作業並不會有太多問題發生, 多數情況都是空間容量不足、repository 連線或 mock 權限等等, 在網海上沖積的參考資料全部都是基本的再編譯作業或是跨平台再編譯, 沒有難度可言一試即成。

不過在實際情況下, 如果要 mock 編譯的是修改的源碼套件, 而需要安裝利用自家新的編譯後已修改源碼的程式開發庫(devel library)再編譯其他軟體的話, 卻是另一個腦惱問題, 因為 mock-yum 只會利用預設的 repository 來安裝 chroot 環境的軟體需求, 執行 mock 時是無法強制 mock-yum 略過或安裝自家修改的軟體套件, 也許專才會認為新的 mock 版本不是已新增 --install 功能嗎?! 可惜在實測中(EPEL5 內的 mock-1.0.7-1.el5)發現...就筭執行 --no-clean --install aa-2.i386.rpm aa-devel-2.i386.rpm 然後再執行 --no-clean --rebuild bb.src.rpm(依賴 aa-devel-2.i386.rpm)卻是無法略過 mock-yum 的強蠻檢查, 如果系統預設 repository 只得 aa-1.i386.rpm 及 aa-devel-1.i386.rpm, mock 就會傳回 ERROR 訊息的 "Cannot find build req aa-devel >= 2. Exiting" 而編譯失敗終止, 此問題是 mock python script 程式碼的瑕玼, 無論更新的版本亦無法以指令直接解決, 企鵝族及編程人員或多或小都會有自家修改的軟體需要再編譯, 最常見的是 freetype、firefox、xulrunner 等等。

mock build 編譯 firefox-3.6.14 時 mock-yum 無法找到 xulrunner-devel-1.9.2.14 而編譯失敗
唯一輕鬆可以解決的辦法是將自家更新的軟體套件在編譯的本機(或網絡)電腦內創建一個 local repository, 修改 mock 編譯預設文件檔案(例如 centos-5-i386.cfg 及 centos-5-x86_64.cfg)加入自家的 local repository 位置, 那樣在執行 mock build 時 mock-yum 就會因編譯需求自動在 chroot 環境內安裝自家的修改軟體庫了, 這是最方便的辦法, 適合多人網絡的模擬編譯環境使用而排除誤用舊軟體庫版本的問題, 只需在 mock build 前注意 local repository 的更新就可搞定, 此法亦適用於 x86_64 下跨平台編譯 i386/i686。

掛建 local repository 新增已修改軟體庫活用 mock 模擬編譯:
實機使用 CentOS 5.5 x86_64 的 mock-0.6.13-1.el5_2.3
安裝 mock 及配置:
  • yum 在線安裝 mock 軟體
    # yum install mock
  • 用戶帳號(例如 aa_user)加入 mock 群組
    # usermod -G users,mock aa_user
實例: mock 編譯 xulrunner-1.9.2.14 及 firefox-3.6.14
  • 首先自行準備好 xulrunner-1.9.2.14 及 firefox-3.6.14 的 src rpm 源碼套件
    例如: 借用舊的 xulrunner-1.9.2.13-3.el5.src.rpm 及 firefox-3.6.13-3.el5.centos.src.rpm 解壓到 ~/rpmbuild/SOURCE/ 目錄內自行修改(或針對性功能...在此省略)後 rpmbuild -bs --nodeps --define 'dist .el5' spec_filename.spec 指令打包成 xulrunner-1.9.2.14-0.el5.src.rpm 及 firefox-3.6.14-0.el5.src.rpm
  • 修改 mock 配置新增 distro 編號 '.el5'
    登入管理員權限
    編輯 /etc/mock/centos-5-x86_64.cfg 及 /etc/mock/centos-5-i386.cfg
    在 #%dist 下新增一行
    %dist .el5
    儲存文件
mock 編譯 xulrunner:
  • 先執行 mock build 編譯 xulrunner(編譯 firefox 需要 xulrunner 及 xulrunner-devel)
    $ mock -r centos-5-x86_64 --arch=x86_64 --resultdir=/home/tester --autocache rebuild xulrunner-1.9.2.14-0.el5.src.rpm
    build xulrunner 超長時間...要有耐性惡玩(無耐性的可以試 freetype 及 fontconfig)
  • 如果要額外編譯 i386/i686(32bit) 系統的話
    $ setarch i386 mock -r centos-5-i386 --arch=i386 --resultdir=/home/tester --autocache rebuild xulrunner-1.9.2.14-0.el5.src.rpm
  • 編譯後結果 log 及 rpm 會產生在用戶個人目錄內 /home/tester/
    xulrunner 及 xulrunner-devel rpm 產生後就可以準備編譯 firefox。

創建本機 local repository(例如 x86_64):
  • yum 在線安裝 createrepo 軟體
    # yum install createrepo
  • 建立 local repository 目錄(例如 /opt/localrepo.x86_64/ 或 /opt/localrepo.i386/)
    # mkdir /opt/localrepo.x86_64
  • 將 mock 編譯後的 xulrunner 及 xulrunner-devel rpm 放置到 local repository 目錄內
    # cp -v /home/tester/xulrunner-*x86_64.rpm /opt/localrepo.x86_64/
  • 在 /opt/localrepo.x86_64/ 目錄內創建 repository
    # createrepo -o /opt/localrepo.x86_64/ /opt/localrepo.x86_64/

修改 mock config 預設文件, 加入 local repository 條件:
登入管理員權限
編輯 /etc/mock/centos-5-x86_64.cfg(32bit 的是 centos-5-i386.cfg)
在 [updates] section 後及 [groups] 前新增如下
[local]
name=local
baseurl=file:///opt/localrepo.x86_64/

儲存文件

mock 編譯 firefox:
  • $ mock -r centos-5-x86_64 --arch=x86_64 --resultdir=/home/tester --autocache rebuild firefox-3.6.14-0.el5.src.rpm

  • 如果要額外編譯 i386/i686(32bit) 系統的話(需要自行準備 local repository 目錄 /opt/localrepo.i386/)
    $ setarch i386 mock -r centos-5-i386 --arch=i386 --resultdir=/home/tester --autocache rebuild firefox-3.6.14-0.el5.src.rpm
  • 編譯後結果 log 及 rpm 會產生在用戶個人目錄內 /home/tester/

完成後, 使用 mock 編譯後的 xulrunner 及 firefox rpm 打包套件就可以安裝到 CentOS 5 系統中使用。
以後需要更改軟體再編譯的話, 只需要更新 /opt/localrepo.x86_64 及 /opt/localrepo.i386 的 repository 內容後就可以立即 mock 編譯了。

備註:
  • mock build 要利用 mock-yum 在線下載系統軟體來掛建 chroot, 如要加快下載速度, 可以利用 proxy 或建立同步的系統及更新 local repository(又是另一個題外話)。
  • mock build 模擬編譯時會在 /var/lib/mock/ 目錄內掛建 chroot, 注意會耗用很大容量空間, 完成所有 mock 編譯程序後 /var/lib/mock/ 目錄內的所有文件檔案都可以刪除清空以釋放硬碟空間。
  • 利用 mock build 模擬編譯好處是不用在自己的電腦內安裝大量的編譯需求套件(例如大量的 devel library), 亦可以排除使用 root 權限編譯的安全(或錯誤路徑)問題, 還可以支援不同 arch 下 cross compilation, 唯一缺點是...mock-yum 下載實在十分耗時, 所以對於大量使用 mock 的編程人員或管理員則建議建立同步的系統及更新 local repository, 減輕耗用網絡頻寬及下載時間, 而個人用戶的話可以暫時使用 proxy 來加速下載, 其他的需求視乎個別情況修改。
  • 在 x86_64 的系統內部分軟體還需要依靠 i386 的架構, 留意是否需要同時編譯 x86_64 及 i386。

2011年3月7日星期一

RHEL6 kernel 開源碼整合齊人包, Redhat 無私顯見私

RHEL6 的推出令到不小企業注意到舊系統的生命週期造成系統升級及遷移的進程企劃, 評估測試是最必然的事, 雖然 CentOS 社群仍未釋出(未知預期)開源碼企業社群版, 而另一個基於 RHEL6 的社群版 Scientific Linux 6 已經官方釋出, 但是眾多 RHEL6 的嘗鮮用戶或許仍不知道 Redhat 公司在 RHEL6 內改變了開源策略, RHEL6 內 kernel 的源碼已經變成了齊人包, 以往 RHEL 釋出的 kernel 所有(數十個)補丁修正文件現在全部被 Redhat 烹煮到 kernel 源碼內, 例如: RHEL6 的 kernel-2.6.32-71.el6.src.rpm 源碼套件內再沒有獨立的補丁修正文件(patch), kernel 源碼已整合成 linux-2.6.32-71.el6.tar.bz2。

RHEL6 的 kernel src 源碼套件 kernel-2.6.32-71.el6.src.rpm 已整合「所有」patch
The Register:
Red Hat: 'Yes, we undercut Oracle with hidden Linux patches'

Redhat 的 CTO Brian Stevens 解說這次策略的改變明顯是衝著 Oracle 及 Novell 提供的支援服務, 將源碼整合打包並沒有違反 GPL 開源碼條款, 只針對競爭對手的商業客戶服務...云云。

Redhat 此法無私顯見私的改變對於個別終端用戶應該是不會有多大影響(可能還不知道吧), 不過對企鵝人甚至開發社群(CentOS 或 Scientific Linux)等等可能有產生源碼追蹤的問題, 尤其是對 kernel 查證源碼或特定環境改造都會更困難, 考慮升級的用戶或管理群應更詳細評估此情況的未知影響。

2011年2月26日星期六

RHEL 5.6 真的「完全」支援 ext4 文件系統格式嗎?!

2008 年 12月 發佈正式的 ext4 文件系統格式及後其支援的 kernel 2.6.28, 到今天都差不多兩年多了, 除了主流的 Linux 系統 distro 個別開發嘗鮮版本外, 企業版的 Linux 系統(RHEL, SUSE 等等)基於穩定安全下一直都是以 technical preview 的方式讓用戶體驗, 並沒有完全地提供原整支援, Redhat 公司釋出的 RHEL 6 及 RHEL 5.6 終於都支援了正式 ext4, 雖然 Redhat 官方在 RHEL 5.6 版本發行說明文件中表示了 「The fourth extended filesystem (ext4) is now a fully supported feature in Red Hat Enterprise Linux 5.6」, 不過在 RHEL 5.6 的其他軟體套件卻仍然存在相容性問題, 其中 RHEL 5.6 提供的軟體 gnome-vfs 並沒有更新支援 ext4, 一但 / 根目錄或 home 目錄架建在 ext4 格式下的話, 在 gnome 桌面應用時會有功能缺失的問題, 最常見的狀態是 gnome 桌面的 Trash「回收筒」不會顯示任何已刪除的文件, 而且 nautilus 也不能正常偵測到 ext4 應用分割區。

RHEL6 的 ext4 分割區在 gnome 桌面刪除文件後 Trash 的內容存在已刪除文件
RHEL5.6 的 ext4 分割區在 gnome 桌面刪除文件後 Trash 的內容空白
RHEL 5.6 發行說明文件
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html-single/5.6_Release_Notes/index.html

Fourth Extended Filesystem (ext4) Support
The fourth extended filesystem (ext4) is now a fully supported feature in Red Hat Enterprise Linux 5.6. ext4 is based on the third extended filesystem (ext3) and features a number of improvements, including: support for larger file size and offset, faster and more efficient allocation of disk space, no limit on the number of subdirectories within a directory, faster file system checking, and more robust journaling.
To complement the addition of ext4 as a fully supported filesystem in Red Hat Enterprise Linux 5.6, the e4fsprogs package has been updated to the latest upstream version. e4fsprogs contains utilities to create, modify, verify, and correct the ext4 filesystem.

RHEL 5.6 kernel 是 2.6.18-238
RHEL 5.6 內的 gnome-vfs2 版本仍然是 5.5 時的 2.16.2-6.el5_5.1 而 RHEL 6 內的版本已更新是 2.24.2-3.el6, 舊的版本仍然沒有支援 ext4 及 ext4dev, Debian bug#539322 2009/7 收納了此問題, 而 Redhat bug#594836 2010/5 亦收納了此問題, 不過 Redhat 官方並沒有對此支援修正感到趣味性, 這造成 RHEL 5.6 的 ext4 其實只是 kernel 的改造支援而已, 其他的軟體在相容性下變成的像殘障病患一樣, 其實 RHEL 5.6 連自身的 anaconda 系統安裝程式也沒有更新到支援格化 ext4 文件系統格式, 在腦惱的失望下唯有自己解決 gnome-vfs 的缺陷(加 patch)【適用於 CentOS 5】。

參考了 Bug#594836 內的附件 "Minimal patch to add ext4 support", 可以自行新增 ext4 patch 到 gnome-vfs2-2.16.2-6.el5_5.1 的源碼內手動編譯及安裝。

將下列修正源碼補丁 "Minimal patch to add ext4 support" 儲存為 gnome-vfs-2.16.2-ext4.patch 文件
--- gnomevfs-2.16.2/libgnomevfs/gnome-vfs-filesystem-type.c 2010-11-10 20:35:39.000000000 +0000
+++ gnomevfs-2.16.2/libgnomevfs/gnome-vfs-filesystem-type.c 2010-11-10 20:39:22.000000000 +0000
@@ -47,6 +47,8 @@
{ "ext2" , N_("Ext2 Linux Volume"), 1 },
{ "ext2fs" , N_("Ext2 Linux Volume"), 1 },
{ "ext3" , N_("Ext3 Linux Volume"), 1 },
+ { "ext4" , N_("Ext4 Linux Volume"), 1 },
+ { "ext4dev" , N_("Ext4 Linux Volume"), 1 },
{ "fat" , N_("MSDOS Volume"), 1 },
{ "ffs" , N_("BSD Volume"), 1 },
{ "hfs" , N_("MacOS Volume"), 1 },

下載源碼套件 gnome-vfs2-2.16.2-6.el5_5.1.src.rpm

安裝源碼套件
# rpm -ivh gnome-vfs2-2.16.2-6.el5_5.1.src.rpm

將 gnome-vfs-2.16.2-ext4.patch 文件新增到源碼目錄 /usr/src/redhat/SOURCE

修改 rpm build spec 編譯程序文件加入 ext4 patch 程序
將下列 patch 源碼儲存為 spec.patch 到 /usr/src/redhat/SPEC 目錄
--- gnome-vfs2.spec 2011-02-25 18:26:49.550202195 +0800
+++ gnome-vfs2.spec 2011-02-25 18:28:10.237202195 +0800
@@ -12,7 +12,7 @@
Summary: The GNOME virtual file-system libraries
Name: gnome-vfs2
Version: 2.16.2
-Release: 6%{?dist}.1
+Release: 6%{?dist}.1.1
License: LGPL
Group: System Environment/Libraries
Source0: gnome-vfs-%{version}.tar.bz2
@@ -94,6 +94,8 @@
# CVE-2009-2473 neon, gnome-vfs2 embedded neon: billion laughs DoS attack
# Patch25: CVE-2009-2473-neon-billion-laughs.patch

+# ext4 support as of RHEL6
+Patch99: gnome-vfs-2.16.2-ext4.patch

%description
GNOME VFS is the GNOME virtual file system. It is the foundation of
@@ -158,6 +160,8 @@
%patch23 -p1 -b .copy-follow-symlink
%patch24 -p1 -b .dav-escape

+%patch99 -p1 -b .ext4
+
# -- disabled, no QE capacity
# %patch25 -p1 -b .neon-CVE-2009-2473

執行 spec.patch 補丁修改 gnome-vfs2.spec
# cd /usr/src/redhat/SPEC
# patch -b gnome-vfs2.spec spec.patch


手動編譯
# cd /usr/src/redhat/SPEC
# rpmbuild -ba gnome-vfs2.spec --define 'dist .el5_5'

**所有編譯開發套件要求需要手動執行 yum 安裝, 包括 yum groupinstall 'Development Tools'

編譯完成後手動升級安裝
# cd /usr/src/redhat/RPMS/i386
# rpm -Uvh gnome-vfs2-2.16.2-6.el5_5.1.1.i386.rpm gnome-vfs2-smb-2.16.2-6.el5_5.1.1.i386.rpm


安裝了 gnome-vfs 支援 ext4 的修正補丁後, gnome 的 Trash「回收筒」功能回復【CentOS 5.5】
備註:
  • 如果系統是 x86_64 的話, 則可以使用 mock 別權環境打包源碼後編譯 i386 及 x86_64。
  • 由於 blogger 對 code 碼的左方空白字去掉, 留意源碼位置已被自動改動。

更新補充:

2011年2月20日星期日

Windows 7 SP1 知者不言

微軟已經官方釋出 Windows 7 及 Windows Server 2008 r2 的 SP1 更新, 在 2011/2/16 MSDN 及 TechNet 用戶已經可以嘗先下載 SP1 更新、語言包及其整合版本分支, 一般用戶則可以在 2011/2/22 透過 Download Center「下載中心」及 Windows Update 推送更新服務包; 此次的 SP1 更新服務包將包含 2010/11 月及以前釋出的所有更新 patch, 另外加入了兩項虛擬化的進階功能, 包括 RemoteFX 及 Dynamic Memory, 並且提供了 ThinClient 版本分支。


Windows 7 service pack 1 技術文件資料
http://technet.microsoft.com/en-us/library/ff817622%28WS.10%29.aspx

當然非 MSDN 及 TechNet 的一般用戶亦可以善用 google 仙人
DVD iso 光碟影像檔案文件包括:
Windows 7 and Windows Server 2008 R2 SP1 x86 x64 DVD 多個語言
mu_windows_7_and_windows_server_2008_r2_sp1_x86_x64_dvd_619642.iso
SHA1: F2ABA1102E18EAD08C78527AB422C09AB7D1F54C

Windows 7 Service Pack 1 Language Pack (x86) - DVD
mu_windows_7_sp1_language_pack_x86_dvd_619716.iso
SHA1: E9261433FF5CCACA818328A9BDBBED3F21A6405E

Windows 7 Service Pack 1 Language Pack (x64) - DVD
mu_windows_7_sp1_language_pack_x64_dvd_619714.iso
SHA1: 7CD1FE568D968D89792DC9FF20E9AF2B318995C2

英文版的 Windows 7 with SP1 DVD iso 整合版的資料可參考:
http://www.sevenforums.com/news/139450-windows-7-sp1-integrated-isos-leaked.html

更新前必須先執行全系統備分, 及確保電腦電源供電不會終斷。
已知的軟體相容性問題:
http://support.microsoft.com/kb/2492938/

未知(不可預料)的更新故障主要是 USB 的系統檔案 usbport.sys, usbehci.sys, 及 winusb.sys 沒有正確更新, 在裝置管理員內會看見感嘆號(!), 快捷的解決辦法是在裝置管理員刪除出現嘆號(!)的 USB 控制器, 重啟電腦讓系統自動再偵測裝置及安裝系統驅動, 此狀態多數會出現在主機版使用 NVidia NForce的晶片組 USB 控制器驅動。

而另一個已知的更新故障是已安裝多國語言包後更新 SP1 時造成藍屏, 無法完成程序及重新正常啟動, 出現
Error C000009A applying update operation {######} of {######} (\Registry...)

此情況是由於安裝多國語言包後沒有啟用, 令系統 registry 內缺失了註冊機碼, 解決此問題的唯一辦法是先強行卸載 SP1 及利用還原點回復系統, 移除舊的多國語言包後再安裝(幸運的話)。

備註:
  • 執行更新過程需要時間, 如果使用一般 HDD 硬碟(甚至 Notebook 筆記本)的話, 更新時間可能耗半小時(已實測)及以上。圖
  • SP1 更新後的硬碟容量會暴增達 985MB(已實測)
    安裝 SP1 前及安裝 SP1 後的容量
    包括 Service Pack Backup Files 及 系統還原點. 如果需要釋放空間容量的話可以手動執行 Disk Cleanup「磁碟清理」刪除, 不過將無法還原及卸載 SP1。
  • 如果是全新安裝 Windows 7 with SP1 整合版本的話, 容量較執行更新包後減小大約 750MB(已實測)。
  • 如果已使用英文版(Ultimate 及 Enterprise)及安裝語言包的話, 需要在控制台內的區域語言配置手動移除舊版本, 及手動安裝 SP1 新版本(已實測)。
  • 由於 SP1 是 2010/11/20 日製作, 沒有包含 2010/12 月及以後的 patch, 如果是全新安裝 Windows 7 with SP1 整合版的話, 在 Windows Update 內會立即發現有更新需要下載。