vmware，ubuntu环境中linux内核编译

zcl_ccc

　　这个周末搞了一下linux内核的编译，有一些经验在这里记录一下，以便以后查找方便。

        软件环境：主操作系统Windows 7，虚拟机软件vmware 7.0.0 build-203739，客操作系统Ubuntu 10.04 内核版本2.6.32-23-generic。

 1、 首先去www.kernel.org下载一个新内核包，本次使用的是最新稳定版2.6.34.1。

 2、 用命令

        tar jxf linux-2.6.34.1.tar.bz2

        解压缩到任何目录下，我是解压缩在~/tmp下。

 3、 然后cd linux-2.6.34.1/进入解压后的目录，利用命令

        cp /boot/config-2.6.32-23-generic ./.config

        将当前内核2.6.32-23-generic的编译配置文件从/boot分区中拷贝到当前目录下，并且重新命名为.config，这样就可以在当前正常运行的         内核编译配置下配置新的内核编译过程。

 4、 在当前目录下运行命令

        make xconfig

        启动基于qt3的编译配置程序。在此之前，需要首先安装build-essential和qt3-dev-tools用以下两个命令从ubuntu的源得到

        sudo apt-get install build-essential

        sudo apt-get install qt3-dev-tools

        启动xconfig之后，选择File菜单中的load，把先前拷贝过来的.config加载上。

 5、 根据需要配置

 6、 配置结束后，选择File中中save。把配置保存在.config文件中。

 7、 用命令

        make -jn

        生成压缩的内核文件以及内核模块，其中n是个数字，表示同时开几个线程进行编译，有几个物理核心就开几个吧。

 8、 命令

        sudo make install

        安装内核压缩文件到/boot分区中

        命令

        sudo make modules_install

        安装内核动态加载模块文件到/lib/modules中相应的内核版本目录中。

 9、 命令

        sudo mkinitramfs -o /boot/initrd.img-2.6.34.1

        在/boot分区中生成启动内存磁盘镜像文件。

10、 更新grub的启动菜单。Ubuntu 10.04采用了新版本的grub，

        用update-grub命令可以直接生成grub启动菜单，此时新版本的内核应该在第一个启动位置；但是默认状态下启动菜单并不显示。要想显         示启动菜单，需要修改/etc/default/grub文件中

        GRUB_HIDDEN_TIMEOUT=1

        GRUB_TIMEOUT=n   这里n表示菜单显示超时时间，默认是10，这里改成自己喜欢的时间。但是这时候菜单的超时时间还是0，还需要           修改/etc/grub.d/30_os-prober文件中

if [ \${timeout} != -1 ]; then

  if keystatus; then

    if keystatus --shift; then

      set timeout=-1

    else

      set timeout=n


    fi

  else

    if sleep$verbose --interruptible 3 ; then

      set timeout=n


    fi

  fi

fi

EOF

      else

cat << EOF

if [ \${timeout} != -1 ]; then

  if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then

    set timeout=n


  fi

fi



       这里黑体的n原本数值为零，n的数值与GRUB_TIMEOUT相同。保存文件后，运行

       sudo update-grub

       系统自动生成grub.cfg文件。

11、sudo reboot选择刚刚安装的内核。

12、至少vmware的lsilogic模式的scsi的模拟程序有一个bug，由于vmware的模拟固件总是对它的连接的最大设备数报告为零，因此linux kernel不能从lsilogic模式的scsi设备启动。解决方法一个是不用lsilogic模式的scsi磁盘，而改用buslogic或者干脆就是ide模式磁盘，美中不足的是vmware 7.0的buslogic模式不支持64位系统；一个是修改内核源代码，可参考http://theether.net/download/VMware/linux-2.6-scsi-mpt-vmware-fix.patch 网页内容摘录如下

（The attached patch is a workaround for a bug in VMWare's emulated LSI

　　
Fusion SCSI HBA.  The emulated firmware returns zero for the maximum
number of attached devices; the real firmware returns a positive
number.  Therefore, the kernel that boots and works fine on bare metal
will fail on VMWare because this firmware value is handed to the SCSI
midlayer, which then skips the entire bus scan.
F7 bz 241935
The patch below was submitted by Eric Moore of LSI to the linux-scsi
mailing list:
http://marc.info/?l=linux-scsi&m=117432237404247
then immediately rejected by Christoph Hellwig, who prefers that
VMWare fix their emulation instead.
---
drivers/message/fusion/mptbase.c |   15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
--- linux-2.6.22.noarch.orig/drivers/message/fusion/mptbase.c
+++ linux-2.6.22.noarch/drivers/message/fusion/mptbase.c
@@ -2573,8 +2573,19 @@ GetPortFacts(MPT_ADAPTER *ioc, int portn
pfacts->MaxPersistentIDs = le16_to_cpu(pfacts->MaxPersistentIDs);
pfacts->MaxLanBuckets = le16_to_cpu(pfacts->MaxLanBuckets);
-max_id = (ioc->bus_type == SAS) ? pfacts->PortSCSIID :
-    pfacts->MaxDevices;
+switch (ioc->bus_type) {
+case SAS:
+max_id = pfacts->PortSCSIID;
+break;
+case FC:
+max_id = pfacts->MaxDevices;
+break;
+case SPI:
+default:
+max_id = MPT_MAX_SCSI_DEVICES;
+break;
+}
+
ioc->devices_per_bus = (max_id > 255) ? 256 : max_id; 


ioc->number_of_buses = (ioc->devices_per_bus < 256) ? 1 : max_id/256;）

我这两天被这个问题困扰了好久，每次安装上新内核总是报告pci 18.2: no compatible bridge window for [io 0xf000-0xffff]，然后就说不能加载/lib/modules/2.6.34.1/modules.dep，系统就停在内存磁盘了。后来偶尔一次在vmware 6.5上的虚拟机测试成功了，结果发现6.5版本的默认磁盘是ide的，于是想到可能是vmware scsi的问题，然后上网找了一大圈，才找到这么个文章，确定了这个想法。接下来在vmware 7.0平台的测试中，将磁盘模式改为ide，系统启动的时候虽然也报告no compatible bridge window，但是已经可以正常启动了。现在的疑惑是为什么Ubuntu 10.04自带的内核没这个问题？再研究吧，linux的学问深着呢，呵呵。