debian, 痛并快乐着

kode4u

昨晚下了一个kernel-source-2.6.8编译，是按照Debian Kernel 2.6 How To来做的，.config文件也是用它的。但在编译过程中遇到一处编译错误以及一大堆警告。错误如下：
driver/scsi/cpqfcTSconftrol.c:610:2: #error This is too much stack
driver/scsi/cpqfcTSconftrol.c:722:2: #error This is too much stack
于是我把scsi low-level driver都去掉了，编译通过，但那些警告依旧存在（请问这些警告对内核有影响吗？）。我这样做有没有什么不妥的地方？

安装完毕后我用alsaconf找到了我的声卡但在后面的配置中出现如下错误：
alsactl: load_state:1134:No soundcards found... :
cry:
这声卡该怎么弄啊？

linky_fan

呵呵，那我还得看debian kernel-howto，好啊，再痛苦一个礼拜好了

先苦后甜嘛

kode4u

老大，那我上面的问题呢？看看第二页我的问题好不好？

linky_fan

1.  声卡是什么型号
2.内核编译的时候有没有打开sound的支持
3.如果在内核里没有找到你声卡的型号,那么选用alsa还是oss
4.alsa的安装步骤: alsa-drv--------> alsa-lib ---------> alsa-util
5.模块加载-----> amixer调整音量------->finish

kode4u

我编译内核后，运行alsaconf找到了我的声卡intel i810 AC97，还有一个什么东西记不清了，我选择了我的声卡，确定后alsaconf后面又出现上面的错误，奇怪。。。

请问，那个scsi的错误是怎么回事儿？

duotaiya

总觉着自己编译出来的内核不如官方的好用，虽然起动速度加快了好多

kode4u

在irc上找到了scsi答案，是要给kernel打补丁
但针对kernel-2.6.7的patch是解决我那个问题的，对kernel-2.6.8的好像不是，下面是那个patch的链接：
http://www.linuxhq.com/kernel/v2.6/7/drivers/scsi/cpqfcTScontrol.c

另外。。。
怎么打补丁啊？按照patch自己改源码？

linky_fan

　　　　 使用补丁文件

　　核心的小幅更新是以补丁文件的方式发行．例如，如果你的版本是 1.1.45 ，而且你注意到出现了一个 `patch46.gz‘ 可以用来升级它，这代表你可以藉由使用这个补丁文件将版本升级到 1.1.46．你也许会想要先备份原始程序代码(`make clean‘ 然后 `cd /usr/src; tar zcvf old-tree.tar.gz linux‘ 将会为你造出一份 tar 压缩文件，里面就是整个原始程序代码与其文件架构)．

　　现在接著继续上面的例子，假设你已经取得了 `patch46.gz‘ 并放在 /usr/src 下． cd 到 /usr/src 然后执行 `zcat patch46.gz | patch -p0‘ (如果并不是压缩过的补丁文件，那么就执行 `patch -p0 < patch46‘)，你将会看到许多东西飞逝而过(或是慢慢跳过，如果你的计算机真的很慢的话)告诉你它正试著修补程序，以及是否成功．通常，这个过程快得无法仔细看清楚它的动作，所以你会无法确定它到底有没有成功地执行．所以你可能会想在 patch 指令中加上 -s 选项，告诉 patch 程序只报告错误讯息就好． (这样你就不会得到许多``嗨! 我的计算机正在做某些改变!‘‘的感觉，不过你可能宁愿这样…) 那么就得找找看一些可能不是那么顺利的事．cd 到 /usr/src/linux 并找寻文件名结尾为 .rej 的文件．某些版本的 patch（比较旧的版本，它们可能是在比较早期的文件系统上编译的）会把这些没有成功的操作记录在文件名有 # 的文件里．你可以用 `find‘ 来替你找；

　　 find . -name ‘*.rej‘ -print

　　会将现行目录及子目录下所有具 .rej 结尾的文件名印到标准输出．
　　如果一切正确无误的话，执行第三节跟第四节所讨论的 `make clean‘，`config‘ 以及 `dep‘．

　　关于 patch 指令另外还有一些选项．如前所述，patch -s 将会抑制除了错误以外的所有其它讯息．如果你把核心原始程序代码放在 /usr/src/linux 以外的地方，在该目录下用 patch -p1 也可以乾净俐落的执行修补任务．其它的 patch 选项在在线手册(man page)里都有很详细的描述．

　　5.2 如果有错误发生

　　(注意: 本节提到的大部份是指旧版的核心)

　　通常最常发生的问题是当 patch 修改一个叫做 `config.in‘ 的文件时，这个文件看起来不怎么对劲，因为你修改了一些选项来配合你的机器．这个问题已经小心的注意过了，但还是可能有人会在较旧的版本上遭遇这个问题．要修正这个问题的话，查看 config.in.rej 这个文件里留下些什么讯息．有修改过的部份正常来说会在每一行开始的地方标上 `+‘ 和 `-‘．查看有标记的附近几行，然后记得它们是设成 `y‘ 或是 `n‘．现在编辑 config.in 档，然后在适当的地方把 `y‘ 改成 `n‘ 以及 `n‘ 改成 `y‘．执行

　　 patch -p0 < config.in.rej

　　如果成功的话(没有错误)，那么你就可以继续配置与编译的工作．这个 config.in.rej 档还是会留在那里，但是你可以砍掉它．

　　如果你仍然遭遇其它问题，那么可能是你安装了一份损坏的补丁文件．如果 patch 显示 `previously applied patch detected: Assume -R?‘，你可能使用了一些比你目前的版本编号还低的补丁文件; 如果你回答 `y‘，它会尝试将你的程序代码降级，而且几乎一定会失败; 如此，你就需要重新取得一份新的原始程序代码．

　　要还原到修补前的状态的话，在原先的补丁文件上执行 `patch -R‘．

　　当补丁文件真的失败的时候，最好的办法是从一个乾净的原始程序代码(例如从 linux-x.x.x.tar.gz 文件其中之一)开始，再重新执行．

　　5.3 砍掉 .orig 文件

　　只要做过几次修补以后，那些 .orig 的文件将会开始堆积．例如，我的一个 1.1.51 版的程序代码最后一次做清扫是在 1.1.48 版（我想是吧）．删除这些 .orig 文件会节省许多的磁盘空间．

　　 find . -name ‘*.orig‘ -exec rm -f {} ‘;‘

　　将会替你照料这件事．某些版本的 patch 会用 ~ 来代替 .orig．
　　有其它更好的的办法可砍掉这些 .orig 档，就是利用 GNU 的 xargs:

　　 find . -name ‘*.orig‘ | xargs rm

　　或是更安全但有些罗嗦的方法:
　　 find . -name ‘*.orig‘ -print0 | xargs --null rm --

　　5.4 其它的补丁文件

　　有一些并不是由 Linus 发行的其它补丁文件出现(我将称之为``非标准的‘‘)．如果你使用了它们，Linus 的补丁文件可能会而无法正确地执行，那么你不是得将它们还原就是得因此而去修改原始程序代码或是补丁文件．这个工作对初学者通常是很讨厌，所以如果你不想去修改原始程序代码(结果通常不大好)，在使用 Linus 的补丁文件之前先还原这些非标准的补丁文件，或重新安装新的程序代码．然后试试栈锴标准的补丁文件能不能用．如果不能的话，那么要不你就继续使用旧的核心，试著修改补丁文件使其能用，要不就等待(可能是乞求)新版非标准补丁文件出现．


　　非标准的补丁文件有多普遍? 你有可能曾经听过它们．我使用 Bill Paul 的不闪烁补丁文件来修改我的虚拟控制台，因为我讨厌会闪烁的游标(这个补丁文件经常为新版核心而更新)．由於大部份较新的设备驱动程序都已经被发展成可载入模组形式，因此许多非标准的补丁文件的重要性已逐渐降低

cnhnln

[quote:8321785619="linky_fan"]1.  声卡是什么型号
2.内核编译的时候有没有打开sound的支持
3.如果在内核里没有找到你声卡的型号,那么选用alsa还是oss
4.alsa的安装步骤: alsa-drv--------> alsa-lib ---------> alsa-util
5.模块加载-----> amixer调整音量------->finish[/quote]
安装alsa哪有什么顺序阿！
如果安装了alsa-util就用alsamixer吧

cnhnln

[quote:42d8305b2f="duotaiya"]
总觉着自己编译出来的内核不如官方的好用，虽然起动速度加快了好多[/quote]
启动速度倒没觉得快。但是却可以精简内核。你用用debian官方的config就会发现有一堆对个人用户没用的驱动

linky_fan

安装alsa哪有什么顺序阿！

alsa-drv--------> alsa-lib ---------> alsa-util

this is（in the system use 2。4vision）

kode4u

昨天在2.6.6kernel上加了一个splash patch，重新编译重启后，机器就花屏了，大概是咋回事儿？

linky_fan

initrd做了没有，还有就是编译内核的时候选了正确的选项没有？