最新的 lvm2 2.02.98-3 软件包包含了自动激活LVM卷的 lvmetad 工具。这导致了以下改变：
- initramfs 的
lvm2 钩子扩展（hook）现在需要依赖 udev 扩展。
/etc/lvm/lvm.conf 中必须配置上 use_lvmetad = 1。新软件包中这是默认的，升级时请自行检查合并 lvm.conf.pacnew 文件。- 可以通过设置
/etc/lvm/lvm.conf 中的 auto_activation_volume_list 来限制自动激活的 LVM卷。如果不清楚如何配置，请保持其被注释掉的状态。
- 如果需要监视功能（快照功能依赖于此），请执行
systemctl enable lvm-monitoring.service。
- 不再需要
lvmwait 内核命令，它现在没任何用处了。
如果使用 pacman -Syu 同时升级 device-mapper、linux 和 lvm2，会出现一条 /sbin/dmsetup 文件丢失的错误。请在更新后再执行一遍 mkinitcpio -p linux，以避免可能出现的错误。
Tom Gundersen 写道：
正如先前所宣布的，initscripts 将不再接受任何测试，且很多包已不再支持它。仍然在使用他们的用户请立即切换到 systemd。
initscripts、sysvinit 和各种 rc 脚本将逐渐从仓库中删除，以避免混淆。
由于 /lib 链接从 glibc 软件包移动到了 filesystem 软件包，请务必同时更新 glibc-2.12-2 和 filesystem-2013.01-1。使用“pacman -Syu”更新时，这一切都会自动完成。切记，不要单独更新其中之一，更不要使用“–force”强行更新……
x86_64 平台下，升级可能时出现 /usr/lib64 下的文件冲突。所有在该目录下拥有文件的官方软件包都已经更新过了，单独更新发生冲突的软件包即可。至于 AUR 中的软件包，应当把该目录下的文件全部安装到 /usr/lib。
felixonmars 写道：
首先解释一下, 对于[testing] 和 [community-testing], 一般软件包在里面的理由有:
1. [core]或者[extra]有重要库rebuild, 相关[community]包完成后被放到[community-staging], 然后统一移到[community-testing] (相关[core]或者[extra]的包被移到[testing]). 这个时候每个包能不能工作是没有人试过的!
2. 一些TU维护自己并不使用的[community]包, 当包上游版本更新, 或者自己修了个bug并且自己认为”应该没问题吧”, 然后因为没测试, 所以放进 [community-testing] 等到一定测试量没问题后再放进 [community]; 或者是一些DEV维护自己并不使用的[core]或者[extra], 然后…然后放进[testing]. 这个时候每个包能不能工作也是没有人试过的!
所以作为一只TU, 我表示[testing]和[community-testing]真心只是给比较懂系统急救+英语+报bug的人用的… Arch的[testing]并不像其他发行版那样会领先”稳定”仓库多少, 因为unstable版本的软件照样在”稳定”仓库里, 通常软件在[testing]和[community-testing]不会待很久(除非有巨大的问题, 那样你也就惨了).
所以对于新手和身边救急用具准备不足的老手, 强烈建议不要开启[testing]和[community-testing].
版本号为 2012.12.01 的安装介质已经可以在 下载页面 获得。最新的快照包含：
arch-install-scripts 9 和改善了的fstab生成器linux 3.6.8systemd 196core仓库的日常更新
下一次快照将在2013年1月发布。
今日更新了 fcitx, 许多用户反馈在部分应用程序中无法激活/使用, 虽然这类问题已经并不新鲜, 但是我觉得还是有必要说明一下.
首先, 这个问题从根本上是 pacman 的错(升级顺序混乱).
升级的时候你应该看到 fcitx-gtk2/fcitx-gtk3 的 installing 后面跟着个 error, 那就是因为, 存在下面的依赖链(以 fcitx-gtk2 为例):
fcitx-gtk2 -> gtk2 -> pango -> harfbuzz -> icu
最后的两个都在升级列表里, 而按照逻辑, fcitx-gtk2 需要在他们之后升级才是正常的, 但是 pacman 没有考虑这个问题(依赖链中间有两个未参与此次升级的包).
我今天中午收到反馈就 bump 了版本(在基友 yuyichao 的建议下更新了 fcitx-gtk2.install, 简单的 hack 了一下使得以后类似情况时不出现此问题), 现在你看到(或者装了)的应该是 -3 结尾的版本号. 但是即使升级后, 所有使用 gtk2 相关库的应用程序仍需重启才能生效.
因为类似情况并不是第一次出现了(以前有数次大规模 rebuild 后某些包不正常的情况), 基本上如果你在升级过程中看到有库链接错误/segfault/参数错误之类的提示, 在此次升级指令完成后把这些出错的包重新安装, 如果还有错, 继续安装有错的包直到没有错为止. 这样基本上可以解决大部分的此类问题.
另附此次我机子上 fcitx-gtk* 升级出错的 log 以便大家参考前文的分析 (无关包已去掉)
[2012-11-17 10:58] upgraded icu (49.1.2-2 -> 50.1-2)
[2012-11-17 10:58] upgraded fcitx (4.2.6.1-1 -> 4.2.6.1-2)
[2012-11-17 10:58] usr/bin/gtk-query-immodules-2.0: error while loading shared libraries: libicule.so.49: cannot open shared object file: No such file or directory
[2012-11-17 10:58] upgraded fcitx-gtk2 (4.2.6.1-1 -> 4.2.6.1-2)
[2012-11-17 10:58] usr/bin/gtk-query-immodules-3.0: error while loading shared libraries: libicule.so.49: cannot open shared object file: No such file or directory
[2012-11-17 10:58] upgraded fcitx-gtk3 (4.2.6.1-1 -> 4.2.6.1-2)
[2012-11-17 10:58] upgraded qt (4.8.3-5 -> 4.8.3-6)
[2012-11-17 10:58] upgraded fcitx-qt (4.2.6.1-1 -> 4.2.6.1-2)
[2012-11-17 10:58] upgraded harfbuzz (0.9.5-1 -> 0.9.5-2)
由于服务器磁盘用尽，我们的群程序在执行存储时崩溃，部分好友信息丢失，当前我们的管理员正在重建社区交流群。IRC频道不受影响。
根据当前工作进度，请丢失好友关系的用户在明天早晨9点之后重新加入本群： talk@archlinuxcn.org
ibus-1.4.99不稳定版发布，新功能包括 GNOME 3 的集成。Arch官方维护者为了实现该新功能，并没有将相关编译选项关闭，此举导致大量 GNOME 3.6 + ibus 用户的输入法框架崩溃。
社区会员经过与Arch官方的讨论(https://bugs.archlinux.org/task/32071)，官方开发者仍不愿关闭该编译选项。因此社区建议 GNOME 3 用户考虑以下2种方案。
- 对于愿意尝试新鲜环境的用户，切换到其他桌面环境/窗口管理器 KDE/XFCE/LXDE等桌面环境和Openbox/fluxbox/Enlightenment等窗口管理器都是非常好的选择，并且这些桌面环境/窗口管理器为用户提供了更友好的计算机桌面操作体验和更多可调节的空间。
- 对于希望继续使用 GNOME 3 的用户 保留 GNOME 3 并切换到其他输入法框架 由 Arch Linux TU Felixonmars 维护的 libibus (aur/libibus, archlinuxcn/libibus) 为 GNOME 3 用户提供了这个可能。添加 Arch Linux 中文社区源 (repo.archlinuxcn.org) 或直接通过 AUR 即可安装。如遇提示 ibus 冲突，选择[Y]替换ibus，安装完成重新登录即可通过原本的方法（设置环境变量等）切换到其他输入法框架（例如 Fcitx）。
最新的安装和救援盘已在我们的下载页面提供下载。2012.11.01 的 ISO 镜像和前一版相比主要包含了少数 bug 修复，清理和新的软件包：
- Linux 3.6 的第一张介质
- 在网络引导时，copytoram = n 可以用于避免将镜像复制到内存。这可能是不可靠的，但在内存很低的的系统中的也是个解决办法。
- cowfile_size 启动参数，主要用于 VFAT 的持久 COW （写时拷贝）。详细信息请参阅 README 文件。
Allan McRae 写道：
Arch Linux 的 bug 跟踪系统中的 bug 数量正在攀升，是时候将它们干掉了。
这是社区参与和帮助 Arch Linux 团队的好方法。过程很简单。首先在 bug 跟踪系统中找到你喜欢的软件的一个 bug，并检查它是否仍然会发生。如果是，请到上游项目找补丁并测试它以确认它是否被解决。如果没有补丁，请确保这个 bug 已经提交给了上游的 bug 跟踪系统。
加入我们的 IRC 频道 #archlinux-bugs。我们的人遍布各时区，所以应该随时都有人在。
