问题表面: sudo apt-get update; sudo apt-get dist-upgrade
问题实质:
udev 升级未完成 postinst 步骤 (难不成是因为在 terminal 里面升级然后不小心关了 ??!!), /sbin/udevadm 变成了一个单纯的脚本, 用于调用 /sbin/udevadm.upgrade. initramfs-tools 不知道这个问题, 无法找到 udevadm.upgrade 并导致启动失败. 重新安装 udev 并 update-initramfs 解决.

并发的其它问题:
xserver-xorg-core 跟随上游升级至 1.7.6-1ubuntu1, gdm 启动数秒后 deadlock. 原因未知, 但以上问题修复后恢复正常.
update-initramfs 时提示 plymouth 缺少部分文件. 安装 plymouth-theme-text plymouth-theme-ubuntu-logo 后正常.
安装 udisk 时提示 “udevadm trigger is not premitted while udev is unconfigured”, 并在 initrd.img 中发现了问题的实质, 这是问题修复的关键.
由于手中没有恢复盘了(大忌), 从网络装了一份 Fedora 13 用于以上调试过程. 看起来还凑合, 却一点也不顺手. 最令人奇怪的是 F13 的 Alpha 版本比 Ubuntu 稳定性好得多, 光看那软件包版本就很奇怪, 但用起来毫无问题?!

结语:
Ubuntu 的 Alpha / Beta 版对新手来说一定要慎用. 这种小白鼠很难当.
这种并发的问题应该说是比较少见, 写出来给大家参考一下.

ps:
最终的结论都写在括号里了, 你发现了没有?

ps2: (2010.4.1 增补)
gdm 启动时不显示用户名问题. 环境使用了 btrfs.
sudo apt-get install dbus --reinstall

迟到的一篇. 有些时日不太关心 Kernel 的变化了.
Git 很方便, 想要什么就 merge 什么.
Phoromatic Kernel Performance Tracker 很不错.

不过也懒了, Ubuntu Lucid 的优化做的挺彻底. 以前编译一个内核就能提高好多的速度, 现在榨不出来了. 不过 bug 也确实多.

开始说这个 compcache. 2.6.33 入 mainline (实际还早一点).
偶不喜欢开 swap, compcache 是个例外, 因为它和磁盘没有关系(后面的版本可能会有关).

有些人喊垃圾收集, swap 就是从内存中来的嘛, 需要的时候从 swap 出去, 当然也可以扔掉.
如果不考虑 compcache 和 swap 的关系, 仅仅把它看作一个 block device, 那么随便写吧, 这么一块大好的内存空间, 实际空间小于所需空间(特殊数据可能会例外).
compcache 有能力解决一些和内存分配利用不当有关的疑难杂症.

compcache swap 的大小个人不推荐超过物理内存的 1/2 (512 M 以下内存用户除外).

有些人知道 memcached 可以用上 lzo 或者 quicklz 什么的, 在客户端配置一下就行了.
甚至单纯的英文字符串也可以压缩 (SMAZ – compression for very small strings, http://github.com/antirez/smaz) – 知道有这么回事就行, 这叫”先学习再替换”.

可是当问 内存, CPU, 存储 哪一个是瓶颈的时候, 除了全换更大更好更快更强的, 就没有其它答案了?
缺 CPU? 实际是不缺的, 明明那么多机器负载不高, 装个 Gearman. 实际上是负载控制能力差. 上下文切换高很难说是坏事还是好事. 腾出一两个 CPU 核或者 irqbalance 试试看.
缺存储? 硬盘那么便宜. 有了那么大的内存, 花了那么多钱搞了 SSD, QPS (query per second) 后面还是没能加个 0.
缺内存? 这块数据放内存里最终也没用几次, 而且还有过度(在内存中)冗余的倾向. 而且那些 worker 占着那么多内存, 不心疼哪?

当然这对正规军好像不算什么大问题.
山寨嘛, 才会出这些问题. 抄完整一点, 把理论也抄来. 好有只抄技术不抄制度的感觉啊 (这语气好好奇怪)…

也许是因为缺银子缺人吧… 确实有不少人意识到啦, 这个混水里的鱼不好摸.

跑题了.

ps:
先知道你的内存长脚跑哪里去了再干活.

ps2:
偶不是内存, 跑…

官方 compat-wireless 基于 wireless-next-2.6 制作.
可以用一些工具, 使用 wireless-testing 中的代码制作自己的 compat-wireless.
compat-wireless 起到了 api 中间层的作用, 如果主线接纳了 api 的修改, compat-wireless 就必须制作 api 兼容层.

参考:
http://wireless.kernel.org/en/users/Download/hacking

cd /usr/src
git clone git://git.eu.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
git clone git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat.git
git clone git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6.git
cd compat-wireless-2.6
export GIT_TREE=/usr/src/wireless-testing/
export GIT_COMPAT_TREE=/usr/src/compat/
scripts/admin-clean.sh
scripts/admin-update.sh

(可能会有 patch 出错的情形, 删除掉那些打不上的 patch 然后再次 update. 对于正规 build 来说应该不会发生这些情况)

scripts/admin-refresh.sh 等于先 clean 再 update, 如果已经对代码进行改动, 可能需要做清理.

然后这个目录中剩下的就是自己做的的 compat-wireless 了.

不过还有一个问题. compat-wireless-2.6/config.mk 的内容和内核 .config 很像.
正因为 compat-wireless 不跟着 compat-testing 走, 所以需要补全 config.mk.

例如 (for ar9271):
CONFIG_ATH=m
CONFIG_ATH9K_HW=m
CONFIG_ATH9K_HTC=m

缺什么补什么. 或者编译完了看看缺什么模块也行.

核心头文件(Kernel Headers) 制作方法:
加注: 本方法完全不对. 正确的方法很抱歉暂时没有找到.

(参考 Documentation/make/headers_install.txt, 制作时应该更换一个路径)
make headers_install ARCH=i386 INSTALL_HDR_PATH=/usr/include

直接编译核心中模块的方法(不推荐):
(参考 Documentation/kbuild/modules.txt, 可以增加 modules_install 以完成安装)
make -C /lib/modules/`uname -r`/build M=`pwd`
其中 -C 跟着的就是核心头文件或者源代码目录. 制作方法如前.

compat-wireless 使用另外一种编译方式:
(参考 compat-wireless 包中 README, Building for external kernels 部分)
make KLIB=/lib/modules/2.6.xx-yyyy -j2
make KLIB=/lib/modules/2.6.xx-yyyy KMODPATH_ARG='INSTALL_MOD_PATH=' install
另外可以指定 KLIB_BUILD 为源代码或头文件目录