apt-get/aptitude update 時 GPG error 問題的發生與尋找解決之道

剛剛在 Ubuntu 8.10 上執行

sudo aptitude update

時遇到一個錯誤訊息

W: GPG error: http://download.virtualbox.org intrepid Release: 下列的簽名皆不合法： BADSIG DCF9F87B6DFBCBAE Sun Microsystems, Inc. (xVM VirtualBox archive signing key) <info@virtualbox.org>

於是就到 http://www.virtualbox.org 上面去尋找 GPG 這個關鍵字
果然找到了一篇相關的 bug report 裡面提到一篇郵件清單上面的文章 apt-get update problem: GPG error ... The following signatures
were invalid
文章當中提到了

rm /var/lib/apt/lists/*

就可以解決問題了
可是我不想要把 /var/lib/apt/lists/ 底下的東西都刪光光
於是看了一下 /var/lib/apt/lists/ 底下

[前面省略]
archive.ubuntu.com_ubuntu_dists_intrepid_main_source_Sources
archive.ubuntu.com_ubuntu_dists_intrepid_Release
archive.ubuntu.com_ubuntu_dists_intrepid_Release.gpg
archive.ubuntu.com_ubuntu_dists_intrepid_restricted_source_Sources
download.virtualbox.org_virtualbox_debian_dists_intrepid_non-free_binary-i386_Packages
download.virtualbox.org_virtualbox_debian_dists_intrepid_Release
[後面也省略]

跟之前的錯誤訊息比較看起來只是 VirtualBox 的 Release 這個檔案缺少了相對應的 Release.gpg 檔案
於是就把 download.virtualbox.org_virtualbox_debian_dists_intrepid_non-free_binary-i386_Packages download.virtualbox.org_virtualbox_debian_dists_intrepid_Release 這兩個檔案刪除掉
重新執行

sudo aptitude update

結果問題就... 還是沒有解決... 冏rz

好吧... 重新找線索看看發現 /var/lib/apt/lists/ 底下有個唯一的目錄 partial 底下也有 VirtualBox 相關的檔案

partial/
|-- download.virtualbox.org_virtualbox_debian_dists_intrepid_Release
`-- download.virtualbox.org_virtualbox_debian_dists_intrepid_Release.gpg

那麼試試看把這兩個檔案也刪除掉再執行一次

sudo aptitude update

結果就... 成功地解決掉這個問題啦~ ^o^

再看看 partial 目錄底下還是空空的
不過 partial 上層的目錄底下就看到了

download.virtualbox.org_virtualbox_debian_dists_intrepid_non-free_binary-i386_Packages
download.virtualbox.org_virtualbox_debian_dists_intrepid_Release
download.virtualbox.org_virtualbox_debian_dists_intrepid_Release.gpg

看起來就是 Release 檔案有了相對應的 Release.gpg 檔案
所以才能夠正常地執行~ :-D

FreedomHEC Taipei 2009 - Day 2

第一個議程由 CIH 介紹 Linux Kernel Module 的逆向工程
背景故事是說老闆要他 porting 一個 WLAN driver 可是沒有 datasheet 可以參考
剛好那個 WLAN driver 少了四個整數值的 header file
問題是他也不熟 ARM 的組合語言 於是他就憑藉著 GCC 的 Cross Compiler 還有中斷向量表的基本觀念
在程式碼裡面填入 asm("nop"); 指令識別透過 arm-linux-gcc -S 的指令轉譯成 ARM 的組合語言
利用這樣的技巧找出無限迴圈跟函式執行進入點 ARM 的組合語言
然後將記憶體整個 dump 出來分析 (通常網通裝置的 Linux 系統所使用的記憶體不會太大, 一般在 64M 以下)
還有透過將無限迴圈放到中斷向量表裡面一步一步抽絲剝繭地將四個重要的整數值找出來

第二個議程由 Peter Stuge 來介紹 CoreBoot (前身為 LinuxBIOS)
CoreBoot 最早叫做 LinuxBIOS 就名稱上看來就是用來啟動 Linux 的 BIOS
後來因為它也可以載入 Linux 以外的 Payload (Payload 不負責任譯為"某種會花費硬體資源的載體")
就連 GRUB 也算是一種 Payload 更多的 Payloads 在 http://www.coreboot.org/Payloads 可以看到
這東西的概念簡單說就是 GPL 授權的 BIOS 讓從事 BIOS 開發不用再從頭寫起
目前已經支援某些特定主機板的清單可以在 http://www.coreboot.org/Supported_Motherboards 上面看到
另外有趣的小東西是 BSD 授權的 Libpayload 讓你寫出自己的載體讓 CoreBoot 來載入

第三個議程由 Jon Corbet 來介紹 Kernel Community
介紹整個 Linux Kernel 開發的合作模式
就是 Linus Torvalds 本人並不會直接收別人給他的 Patch
所以別天真的以為可以把自己的 Patch 直接送給 Linus Torvalds
Linus Torvalds 只會從幾位重要的 Developer 那邊接收 Changesets
Linux Kernel 是個相當活耀開發的計畫有上千個活躍的開發者
Linus Torvalds 不可能一個人去處理所有的程式碼合併跟衝突解決
當然這所有的工作都是靠優秀的 Git 分散式版本控制系統還有優秀的同伴們協力達成的 (他們演講時沒怎麼提到 Git)
簡單說就是 Linus Torvalds 會收一小群人給的 Changesets 然後那一小群人又會從其他人那邊收 Changesets 或是 Patch
最後在 Merge Window 的時候全部再匯集在一起然後釋出 rc1
然後就是 Stabilization 所以不會再接受任何新功能
經過好幾次的 rcN release 覺得差不多了就正式 release 然後再繼續下一個 cycle
一個 cycle 大約 8~12 個星期
一個 stable 的 release 只會維護半年的安全性跟嚴重錯誤修正
另外就是有兩個特別的開發樹
一個是 linux-next 提前為下一個 mainline cycle 的 patches 整合做測試
一個是 -mm 以 linux-next 為基底收集更多雜七雜八的 patches 來做測試
最後子系統的維護者們其實才是把關者也就是所有的 patches 應該要直接送給這些維護者們去做 merge 才對
但是這些子系統的維護者們也並不是擁有絕對的權利
也就是說凡是都還是有商量的餘地

第四個議程 Greg KH 介紹 Linux Driver Project
總之 Greg KH 說把你的 Linux Driver 送交到這個計畫吧
這邊會收任何 Kernel Module 的 patches
也歡迎硬體廠商提供測試機器協助他們測試驅動程式是否正常
就算硬體都還沒有生出來也沒關係

反正早點送 patches 早點 Code Review

不用等到都做完再去送 patches
或者是你的硬體需要有人寫 Linux Driver 嗎
這邊有太多閒著沒事想要寫 Linux Driver 的人
要簽署 NDA 文件也是可以接受的
Linux Driver Project 的網址在 http://www.linuxdriverproject.org/
台灣的硬體廠商們還不快點行動嗎~ :P

第五個議題 Harald Welte 介紹 GPL Compliance
簡單講就是你有用 Linux System 做硬體嗎？
那麼你最好依照相關的規定把該放出來的 Source Code 放出來
人在做 天在看 還有我們一群擅長逆向工程的高手在看 前面 CIH 就介紹過一些方法了
不然我們找到證據就會跑去告你喔~ :O
你看我們有很多合作的模範廠商
咦~ 有些被我們告過囉~ 不過沒關係~ 後來大家都和好了~ :P
另外就是提醒程式開發者們
如果程式碼裡面有一些錯字沒關係就留在那邊
那些錯字可以方便以後我們逆向工程找證據出來

最後就是所有的講者上台接受大家問問題~
照片可以在 http://www.flickr.com/photos/acelan/3617233294/
然後就聽到大長輩田欣先生在用英文一些問題
還有這個活動籌辦人之一的 Scott Tsai 提供即時的中英雙向翻譯
Scott 自己本身也問了一些問題
在聽眾們沒有什麼問題的情況下
講者反問了聽眾們一些問題
然後又聽見田欣先生在用英文回答
還有幾位強者 Matt Hsu, Thinker, ... 也是用英文在問問題回答講者的問題

這兩天的活動於是就圓滿的結束了~
中午提供的便當還蠻好吃的~ :P
第一天中午的便當主菜有雞腿副菜有豬肉
第二天中午的便當主菜有魚副菜也有豬肉
中午吃飯的時候旁邊的窗簾被整個拉開
可以從 14 樓的窗戶看到一排山還有內湖的摩天輪
景色相當好看~ :D

以上是筆者參加過後得心得分享
因為過了一星期才憑回憶攥寫
內容不一定與當天實際情狀相符

FreedomHEC Taipei 2009 - Day 1

FreedomHEC 的全名是 Freedom Hardware Engineer Conference
中文應該是翻成『自由硬體工程師研討會』
如果沒弄錯今年是第二次舉辦 (因為第一次我沒跟到... >_<)
這次的活動總共兩天的議程
網址 http://freedomhectaipei.pbworks.com/

FreedomHEC Taipei 2009 - Day 1

第一個議程由 Jon Corbet 介紹 2.6.X 每個正式 Release 版本改進了哪些功能

只是單純地介紹歷史帶過... 不過內容好像在跟 Jon Corbet 在 LWN 上面寫的都一樣
也就是說他的投影片就是那些每次 Linux Kernel Release 時都會在 LWN 上面寫的東西是一樣的

第二個議程由 Jim Huang (jserv) & Matt Hsu 講 Qi (气) 這個簡單化的 bootloader

內容主要是在講 Qi 將 bootloader 的功能盡量地簡化把複雜的功能交給一個客製化的 Linux Kernel 來處理
也就是說 Qi 只專注在載入一個客製化的 Linux Kernel 然後再讓客製化的 Linux Kernel 透過 kexec() 來載入另一個 Linux Kernel
好處是那個客製化的 Linux Kernel 可以透過許多原本就已經支援的網路裝置
將另一個放在 TFTP 或是 NFS 上面的 Linux Kernel 載入記憶體中並且執行起來
或是載入執行在 SD / USB 等裝置上面的 Linux Kernel
在一些 Flash 儲存裝置的 Linux Driver 還沒有 Ready 前就可以做先期的開發工作

第三個議程是由 Fred Chien 介紹 Linux 快速開機的方法

像是分析啟動時的開機時間統計然後調整 /etc/init.d 裡面 script 執行的順序
或是利用一些 readahead 之類的工具事先將需要載入系統的函式庫提先載入
還有把不需要的 Linux Kernel Module 拿掉 把需要的 Linux Kernel Module build-in
改 XWindow 的滑鼠驅動程式 ... (這個筆者兩三年前在前公司也弄過, 還有改 VGA Driver)
另外就是利用休眠的功能將記憶體的資料寫到儲存裝置上
下次開機再將那些資料讀回記憶體之中
還有關閉掉一些在 BIOS 裡面不需要啟動的硬體功能減少 BIOS 啟動時間
或是將一些系統服務的啟動放在 XWindow 起來之後再去做

第四個議題是由在 VIA 服務的 Joseph Chan 介紹 VIA 是怎麼將他們公司的硬體驅動程式提交進 Linux Kernel mainline 裡面

有兩點需要注意的

第一點 Coding Style
Linux Kernel 有著慣用的 Coding Style 沒理由 Linux Kernel 的 Source Code 要去 follow 某間公司的 Coding Style
所以想要提交程式碼進去 Linux Kernel 的廠商首先就是要調整 Coding Style 去適應 Linux Kernel
而不是自己關上門來硬幹等到最後提交的時候才發現 Coding Style 要大修改

第二點 Mailing List 上面的 Review Feedback
並不是將程式碼提交出去就算是交差了事了，更重要的是要聆聽開發者的意見還有耐心等待
並不是開發者都閒閒沒事做在那邊等著別人送 Patch 給他 Review，所以要等到開發者有時間才會去看你的程式碼去給 Review Feedback
還有要注意的是收到回應後應該要馬上給對方回應儘快去修改程式碼再去做提交

而 Joseph Chan 正是將 VIA 所遭遇到的慘痛經驗分享給與會者

第五個議題是由 Greg KH 帶著大家一步一步去寫出 Linux Kernel 上面的  USB 溫度計的 Kernel Module

Greg KH 與前面的講者 Jon Corbet 剛好都是  Linux 驅動程式這本書籍的作者
所以其實 Greg KH 介紹的東西在看過這本書之後，其實很快就可以上手了
主要的重點在於 Greg KH 介紹了 USB Subsystem 的基本架構
介紹 Interface/Config 跟  IN/OUT/Endpoint{Interrupt,Bulk,Isolate} 這些觀念
然後就是一個範例一個範例地帶大家一步一步地寫出 USB 溫度計的驅動程式

SCons 簡單介紹一下

apt-cache show scons 裡面的描述是

 SCons is a make replacement providing a range of enhanced features such
 as automated dependency generation and built in compilation cache
 support.  SCons rule sets are Python scripts so as well as the features
 it provides itself SCons allows you to use the full power of Python
 to control compilation.

一個 C/C++ 的軟體專案一定需要一個自動化編譯的工具作為輔助來管理，這樣可以簡化許多繁複的步驟，所以也有人將 SCons 拿來跟 GNU Build System (Autotools) 還有 CMake 做比較。

例如要編譯一個簡單的 Hello World 執行程式

/* hello.c */
#include <stdio.h>
int main(int argc, char* argv[])
{
    printf("Hello World!\n");
    return 0;
}

最初的方法一定是直接下指令

$ gcc -o hello hello.c

如果是學過 GNU Make 的話就會知道要寫一個 Makefile 來用，內容像是

# Makefile
hello: hello.c
    $(CC) -o $@ $<
clean:
    $(RM) hello
.PHONY: hello clean

不過如果是 SCons 的話，就是寫一個 SConstruct 的文字檔，內容像是

# SConstruct
Program('hello.c')

接下來就可以下指令 scons 來編譯，如果要清除的話就可以下指令 scons -c 來做
這樣是不是感覺輕鬆許多了呢~ ;-)
當然如果熟悉原本 GNU Make 的人也可以寫一個 Makefile 來用，內容像是

# Makefile
all:
    @scons -Q
clean:
    @scons -Q -c
.PHONY: all clean

這樣就可以利用 SCons 簡潔的語法而且又維持原本 GNU Make 的使用習慣了~ ;-)

SCons 更詳細的使用方法請見官方的說明文件 http://www.scons.org/documentation.php