最近發現在安裝新的 kernel 時, Debian 在安裝之後, 會去處理 dkms 的模組, 但是當同一個模組有多個版本存在時, /usr/lib/dkms/dkms_autoinstaller 這個 script 就會回報這個錯誤:
Apr 25 17:09:33 mail dkms_autoinstaller: e1000e: Multiple versions in DKMS. Unsure what to do. Resolve manually.
Apr 25 17:09:33 mail dkms_autoinstaller: igb: Multiple versions in DKMS. Unsure what to do. Resolve manually.
由於舊的版本通常是在目前或舊的 kernel 仍在使用, 所以也無法馬上就移除. 所以每次有新的版本時, 就有這個問題. (有其他的解決方法嗎?)
使用這個 patch, 可以直接選擇最大的版本來用, 這樣就可以允許多個版本存在 (這應該是多數情況下的選擇):
--- dkms_autoinstaller.orig 2012-04-26 10:03:51.235070429 +0800
+++ dkms_autoinstaller 2012-04-26 10:03:50.691733326 +0800
@@ -79,7 +79,10 @@
version_count=0
already_installed=""
already_installed_version=""
- for versioned_path in $(find "$modulepath" -maxdepth 1 -mindepth 1 -type d -a -not -name original_module); do
+ for versioned_path in $(find "$modulepath" -maxdepth 1 -mindepth 1 -type d -a -not -name original_module | sort -r); do
+ if [ "$version_count" -gt 0 ]; then
+ continue
+ fi
version_count=$(($version_count + 1))
version_in_tree="${versioned_path##*/}"
這樣以後更換新的版本時, 就應該會自動處理了.
昨天把 kernel 裡頭關於 xz 的支援打開後, 就把 kernel 改用 xz 來壓縮, 解壓縮的速度比 bzip2 快, 壓起來又比 bzip2 小. 所以就想把 initramfs 也改用 xz 來壓縮.
由於 Debian Squeeze 的 initramfs-tools 並沒有支援 xz, 不過... 看那個 script, 並沒有要求 /etc/initramfs-tools/initramfs.conf 這個檔案內的 COMPRESS 設定只能設它所列的那一個, 而是把這個設定當成指令來執行壓縮的動作, 所以... 我原本以為就直接改成 xz, 這樣就可以了.
執行 mkinitramfs 或 update-initramfs 之後, 雖然是產生了一個 xz 壓縮的檔案, 不過.... 重開機後, 發現 kernel 沒辦法正確載入那個檔案....
後來看到這篇, 提到要用這樣的參數才可以:
find . | cpio -H newc -o | xz --check=crc32 --x86 --lzma2 > /usr/src/initram.igz
所以... 還是要去改 /usr/sbin/mkinitramfs 這個 script 的內容, 對 xz 特別去處理才可以.
後來看到 Debian 有這個 patch 可以用:
diff -uNr initramfs-tools-0.98.8/conf/initramfs.conf initramfs-tools-0.98.8.new/conf/initramfs.conf
--- initramfs-tools-0.98.8/conf/initramfs.conf 2010-08-26 03:32:27.000000000 +0800
+++ initramfs-tools-0.98.8.new/conf/initramfs.conf 2011-05-12 09:49:57.000000000 +0800
@@ -36,7 +36,7 @@
KEYMAP=n
#
-# COMPRESS: [ gzip | bzip2 | lzma | lzop ]
+# COMPRESS: [ gzip | bzip2 | lzma | lzop | xz ]
#
COMPRESS=gzip
diff -uNr initramfs-tools-0.98.8/mkinitramfs initramfs-tools-0.98.8.new/mkinitramfs
--- initramfs-tools-0.98.8/mkinitramfs 2011-01-28 22:09:09.000000000 +0800
+++ initramfs-tools-0.98.8.new/mkinitramfs 2011-05-12 09:49:27.000000000 +0800
@@ -149,6 +149,8 @@
[ "${compress}" = lzop ] && compress="lzop -9"
+[ "${compress}" = xz ] && compress="xz -9 --check=crc32"
+
if [ -d "${outfile}" ]; then
echo "${outfile} is a directory" >&2
exit 1
加上 --check=crc32 就可以了.
這樣子處理後的檔案, 果然可以正常開機了.
最近發現每天使用 LVM snapshot 備份的時候, 總會有些 snapshot 無法被移除, 找了一下, 應該是 LVM 與 udisks 搭配時發生的問題.
解決方法也很簡單, 就是一直試到可以移除為止. (上頭連結有人說用 lvchange 先改狀態再移除就可以, 不過我試的結果, 也是有無法移除的時候, 所以.... 弄個 loop 來移除, 試到可以移除為止, 這是目前比較可行的方法)
我把原本移除的動作改用 for loop 處理, 目前看起來多試在試了兩三次後就會被移除了.
btrfs 是 Oracle 為 linux 所做的一個 open source filesystem, 其主要目標應該是 ZFS (因為授權的關係, 無法直接納入 linux kernel 中) 吧. (閱讀全文)
我用 heartbeat 應該有好幾年了, 好像有 0.x 版開始就用到現在的 3.x 版. 記得剛開始的時候, 功能不多, 不過也沒什麼問題... 現在用的 3.x 版, 最近常常碰到 standby 的機器重新開機 (應該說 heartbeat 的程式停掉再跑), 讓原本正在運作的機器的 heartbeat 突然佔用所有的 CPU, 然後一堆 log 在 ha-log 或 ha-debug 裡頭, 接著... 原本應該正常運作的 heartbeat 就停了.
由於 heartbeat 的 maillist 中看到不少人有類似的情形, 不過... 看起來似乎沒有什麼解決方法. 由於次數越來越多, 所以就想把 heartbeat 換掉. (閱讀全文)
新版的 Delphi 應該不用這麼麻煩, 據說只要直接在 AnsiString, WideString, UTF8String 之間 assign 時就會自動幫你做轉換 (沒用過, 不知道是不是真的這樣就可以).
不過... 還在用 Delphi 3/5, 所以... 只好自己來轉:
unit util_utf8;
interface
uses Windows;
type
UTF8String = AnsiString;
function AnsiToWide(const S: AnsiString): WideString;
function WideToUTF8(const WS: WideString): UTF8String;
function AnsiToUTF8(const S: AnsiString): UTF8String;
function UTF8ToWide(const US: UTF8String): WideString;
function WideToAnsi(const WS: WideString): AnsiString;
function UTF8ToAnsi(const S: UTF8String): AnsiString;
implementation
function AnsiToWide(const S: AnsiString): WideString;
var len: integer;
ws: WideString;
begin
Result:='';
if (Length(S) = 0) then
exit;
len:=MultiByteToWideChar(CP_ACP, 0, PChar(s), -1, nil, 0);
SetLength(ws, len);
MultiByteToWideChar(CP_ACP, 0, PChar(s), -1, PWideChar(ws), len);
Result:=ws;
end;
function WideToUTF8(const WS: WideString): UTF8String;
var len: integer;
us: UTF8String;
begin
Result:='';
if (Length(WS) = 0) then
exit;
len:=WideCharToMultiByte(CP_UTF8, 0, PWideChar(WS), -1, nil, 0, nil, nil);
SetLength(us, len);
WideCharToMultiByte(CP_UTF8, 0, PWideChar(WS), -1, PChar(us), len, nil, nil);
Result:=us;
end;
function AnsiToUTF8(const S: AnsiString): UTF8String;
begin
Result:=WideToUTF8(AnsiToWide(S));
end;
function UTF8ToWide(const US: UTF8String): WideString;
var len: integer;
ws: WideString;
begin
Result:='';
if (Length(US) = 0) then
exit;
len:=MultiByteToWideChar(CP_UTF8, 0, PChar(US), -1, nil, 0);
SetLength(ws, len);
MultiByteToWideChar(CP_UTF8, 0, PChar(US), -1, PWideChar(ws), len);
Result:=ws;
end;
function WideToAnsi(const WS: WideString): AnsiString;
var len: integer;
s: AnsiString;
begin
Result:='';
if (Length(WS) = 0) then
exit;
len:=WideCharToMultiByte(CP_ACP, 0, PWideChar(WS), -1, nil, 0, nil, nil);
SetLength(s, len);
WideCharToMultiByte(CP_ACP, 0, PWideChar(WS), -1, PChar(s), len, nil, nil);
Result:=s;
end;
function UTF8ToAnsi(const S: UTF8String): AnsiString;
begin
Result:=WideToAnsi(UTF8ToWide(S));
end;
end.
就是直接使用 win32 的 API 來處理.
PS. 舊的 VCL 只支援 Ansi, 所以... WideString 與 UTF8String (定義與 AnsiString 相同) 並沒有辦法正確的在 VCL 中顯示.
最近試著在 Delphi 中產生 QR-Code, 找到了 zint 這東西, 也找到有人針對 zint.dll 做的 Delphi 模組. 不過... 適用的 Delphi 版本是在 D10 之後, 我們用的 D3 與 D5 (沒錯了, 很老了) 都無法直接用. (閱讀全文)
最近在還原 xfsdump 所做的備份時, 碰到幾次無法由原本的備份檔中把所有的檔案還原. 還原的過程會出現
xfsrestore: WARNING: corrupt extent header
xfsrestore: WARNING: unable to resync media file: some portion of dump
這樣的訊息. 在這訊息之後就會中斷還原 (不過最後還是回報成功). (閱讀全文)
這幾個星期發現家裡的 nginx 在隔約 2 小時左右 (間隔不一定, 有時很久沒出現, 有時連續出現, 不過多數看起來是隔兩小時出現一次), 就會出現一次 segfault, 雖然只是其中一個 worker, 也會被重新執行, 並不會影響到實際的 web server 運作, 不過.. 在 log 裡常常看到這個錯誤也很奇怪. (閱讀全文)
今年過年, 想說家裡那些機器好像去年也沒清, 所以... 就決定停機來清理一翻.... 結果, 果然機器跑的好好的時候, 沒關機都沒事, 一關機... 可能就開不起來了. (閱讀全文)
這個問題好像也不是只有 e1000e 會出現, 我好像也有在 e1000 上頭看過. 不過... 在網路上頭看到別人出現這問題之後的結果, 那網卡似乎真的無法正常運作. 不過... 在我碰的案例中, 並沒有出現過網卡無法運作的問題, 都只是單純在 log 中出現這個錯誤訊息, 而該段時間的其他 log, 看起來並沒有任何連線或傳輸中段的情形出現. (閱讀全文)
過年前弄了三張 intel E1G42ET 回來, 趁著過年假期在家就試看看 teaming 的效果. 記得以前在 kernel 2.2/2.4 的年代, intel 的網卡是用自己的 iANS 軟體來在處理 teaming, 不過... 看起來該軟體很久沒更新了, 且在目前 intel 的 e1000/e1000e/igb 等 driver 中, 也說明 teaming 的功能在 driver 已經不存在, 要使用 linux 的 kernel 的 bonding 模組來處理. (閱讀全文)
最近在備份時發現常常出現類似下面的訊息:
/usr/sbin/xfsdump: WARNING: could not get list of non-root attributes for nondir ino 234123: Cannot allocate memory (12)
然後在 syslog 裡頭可以看到 kernel 有 page allocation failure 的錯誤訊息.
看起來是與這個問題類似. 通常在剛開機沒多久的時候都很正常, 但是運作久了之後, 就容易出現這個問題. 依據該討論串的說明, 應該是 kmalloc() 在運作一陣子之後, 可能會沒有那麼大的連續可用空間可以使用, 所以 xfs code 裡頭用到這個的時候會發生錯誤. (我沒有把這個 dump 還原來比較, 所以不確定是不是備份會不完整)
看來以前沒有人用 phpmsnclass 這東西在 big-endian 的機器上頭.... 直到昨天有人問我他在登入時一直出現 911 的錯誤, 加了一些除錯訊息之後, 終於發現 pack() 的結果與在 x86/x64 上的結果不一樣. 造成 login 所需要的 BLOB 資料運算錯誤.
因為我只有 x86 的機器, 所以... 自然都用 little-endian 的方式來處理, 所以 pack() 傳入的參數是 'L' (依據 machine 來決定 unsigned long 的儲存方式)... 不過, 在 big-endian 結果就不同了.
所以我們應該在這地方使用 'V' (用 little-endian 的方式處理 unsigned long) 才處理, 這樣不管在 little-endian 或 big-endian 的機器都可以正常使用.
有需要的, 請自行到 Google code 去抓 r61 或之後的版本.
由於 Debian Stable 版本除非非換新的版本才能修正安全性的問題, 否則, 是不會把所使用到的軟體的版本升級的. 這時... 就只能選擇使用 backports, 但是如果要用的東西沒在 backports 裡頭時, 就只能自己抓 Debian pool 裡頭的 source 回來自己重編. (閱讀全文)
這問題自從很久之前 (都忘了是多久之前了) 升級到 Debian Squeeze 之後就碰到, 一直沒有處理, 當時只是直接把原本用到的東西轉成 OID 來查, 讓它可以正常使用後就一直沒去管它了. (閱讀全文)
systemrescuecd 實在是一個好東西, 對於出問題的 Linux 來說, 有了這東西, 要修起來就變的方便許多. 一般的使用, 除了燒成光碟來使用外, 也可以放到 usb 隨身碟上頭使用.... 當然, 對於已經存在的系統來說, 更可以直接把 .iso 檔案丟到 /boot 或 / 下頭 (看你的 grub 能找到那一個), 讓 grub 直接載入該光碟來開機. (閱讀全文)
上個月中就發現家裡的一台主機上的 RAID 0 不見了, 試著重開機幾次, 發現某一個硬碟有時會抓不到, 如果有抓到時, 當真的要寫資料進去時, 就會發生問題, 然後整個 RAID 的 filesystem 就看不到了.
這個月回家, 想說最近硬碟價位仍然過高, 打算只把那個有問題的硬碟 (WD 750GB) 移出來, 剩下的三個 750GB 的硬碟再撐一下... 結果, 拿出來後, RAID 重建後開始複製資料 (原本就是拿來備份主要的那台主機的資料), 結果.... 跑了幾個小時, 又出現相同的問題, 一看.... 又一個硬碟 (Hitachi 750GB) 一樣在寫入時發生錯誤.... 看來只好買個新的硬碟來換到這原本的 1.5TB 的空間 (還好最近 Seagate 出了一個感覺比較便宜的 3TB 硬碟, 跟我半年前買的 Hitachi 3TB 似乎差不多價格, 不知是規格那兒有差別... 因為以前同等級的價格還在近 9000 上下, 相差兩千左右).
換上後.... 新的硬碟用起來似乎也比較快, 做 rsync 時感覺比之前快多了.... 不過.... 突然發現在處理到某個路徑的時候, 整個系統突然變的很慢.... 找了半天, 發現主機上頭一個 Hitachi IDE 400GB 怪怪的, 可以讀, 也可以寫, 但.... 讀取速度居然只有 1MB/s.... 比我用的網路還慢.....
因為覺得買小硬碟不划算, 所以就只好再買一個 3TB 的回來, 把原本用來備份的 750GB 換來用, 拿 3TB 的來備份資料. 不過.... 那 400GB 的硬碟裡頭的資料還是得慢慢的 copy 出來 (還好花了兩天慢慢 copy, 都沒出問題, 還是把資料給弄出來了).
最後... 發現新買的 3TB 硬碟 (ST3000DM001), 裝在 ICY DOCK MB454SPF-B 會有時抓的到, 有時抓不到, 試了十幾次, 最後決定直接接到主機板上頭, 似乎就正常了. 我後來有發 email 詢問 ICY DOCK, 他們認為應該可以正確使用才對, 說也許是 SATA III 的硬碟對排線的要求比較高一些, 換個排線也許就可以用. (這我要以後有機會才能試了.... 不過.... 什麼叫做比較好的 SATA III 排線呢? 這東西好像也不是賣的比較貴就比較好吧.... 到時還真不知道要去那兒找排線來用呢....)
之前說過, 可以把 Gallery 2.x 與 3 看成是不同的軟體. G3 可以使用 g2_import 模組把原本 G2 的資料匯入到 G3 裡頭 (所有的檔案都會複製一份, 所以做好後在 G3 的任何動作都不會影響原本在 G2 裡的東西. (閱讀全文)
這是早上那個 Gallery 3 與 ZendGuardLoader 一起使用時的問題, 寫了一個小的 test case, 可以重製這個錯誤. (閱讀全文)
如果你在有使用 Zend Guard Loader 的網站中架設 Gallery 3 的話, 在跑完 install 的畫面之後, 你就會發現你的 Gallery 3 永遠都出現一個空白畫面. 這問題... 有人在 Gallery 那邊問, 想當然的.... 得到一個不是我們的問題的答案 (如果我是作者, 我也會這樣回答的), 也有人在 Zend 那邊問, 結果與我以前問 Zend 問題的經驗一樣.... 完全沒有任何作用. (閱讀全文)
在一般靜態網頁的處理上頭, nginx 可以正常的顯示一些錯誤的訊息 (如 404 File not found 之類的訊息). 不過對於 PHP (其他用 fastcgi 方式跑的程式也一樣), 預設來說, 如果有什麼錯誤, 往往就看到空白的一個網頁. 而一般的 nginx 教學上頭, 對於這個問題的處理建議就是 fastcgi_intercept_errors on 的設定. 但... 這個方式並不是完美的. (閱讀全文)
在 Gallery 3 的 Search 模組中, 是透過 MySQL 的 full-text search 方式來處理, 不過... 這個方式對於 CJK 之類的文字, 由於無法分辨詞的斷點, 是無法正常運作的. 這個修改, 是把有非英文的 search, 改成 like 來處理 (東西一多, 也許效能會很差, 所以... 如果你的系統這樣子改之後, 找東西變很慢的話, 就不要用了). (閱讀全文)