我不是昇腾设备，没有安装驱动，是不是就没有__aicore__这个宏定义

在centos7，RTC支持参数wakealarm（/sys/class/rtc/rtc0/wakealarm），可设置定时开关机。但是鲲鹏的/sys/class/rtc/rtc0/下没有wakealarm参数，是否不支持？

kernel 5.4.214 bcache加速hdd，遇到一个cache回收策略的问题，如何设置回收策略

# yum list | grep kernelkernel.aarch64                           5.10.109-200.el7                @updateskernel-core.aarch64                      5.10.109-200.el7                @updates上面是旧的服务器，新服务器在updates没找到5.10.109的kernel版本。

1. 开启pageowner功能1.1 下载对应版本内核源码uname –a 查看对应内核的version-release方式一：下载 https://gitee.com/openeuler/kernel源码并切换到对应tag方式二：下载对应版本号的src.rpm可 配置source repo：dnf download –source 下载对应src.rpm也可通过wget 对应repo源的软件包地址，openEuler-20.03-LTS-SP1的源码包路径如下：https://repo.openeuler.org/openEuler-20.03-LTS-SP1/source/Packages/https://mirrors.huaweicloud.com/openeuler/openEuler-20.03-LTS-SP1/source/Packages/ 1.2 开启page_owner选项构建软件包以下均以arm架构下下载src.rpm的形式为例安装src.rpmrpm –ivh  kernel-xxxxx.src.rpmcd /root/rpmbuild/SPECSdnf builddep kernel.speccd /root/rpmbuild/SOURCEStar –zxvf kernel.tar.gz (如果没安装tar dnf install tar)cd kernelmake menuconfig键入/  进入搜索界面搜索 page_owner 回车确认键入1  进入配置界面键入Y  选中page_owner选项然后退出grep –rn “PAGE_OWNER” .config 查看选项是否生效使用以下命令构建export INSTALL_MOD_STRIP=1make binrpm-pkg -j200 生成的rpm存放在/root/rpmbuild/RPMS/$basearch/下kernel-xxxx.rpmkernel-headers-xxxx.rpm该软件包的release为空和社区下载的名字明显不同，后面区分grub选项用1.3 获取page_owner数据安装kernel rpm包（只需要安装主包）rpm –ivh –force kernel-xxxxx.rpm 确认grub的菜单是否存在新内核在新的启动项后增加page_owner=on选项以上操作均可以在/boot目录下的grub.cfg或/etc/grub2.cfg中确认2. 获取page_owner数据2.1重启统计page_ownercd /root/rpmbuild/SOURCES/kernel/tools/vmmake –jcat /sys/kernel/debug/page_owner > page_owner_full.txtgrep –v ^PFN page_owner_full.txt > page_owner.txt./page_owner_sort page_owner.txt sorted_page_owner.txt2.2 计算page_owner数据总值最终查看sorted_page_owner.txt文件其中每块数据首行“ times:”前的数据为申请的次数：第二行order后的数据为申请的page数量，结果为2^n个page页大小根据 getconf PAGESIZE或getconf PAGE_SIZE查看最终启动后内存占用总量为 (∑(<times> * 2 ^ <order>)) * <page_size>2.3 简单的计算脚本如下：FILE_NAME = "sorted_page_owner.txt" # 根据获取的page_owenr结果文件位置修改 PAGE_SIZE = 4028 # 根据getconf PAGESIZE或getconf PAGE_SIZE的结果进行修改 def main(fn): result = 0 with open(fn, "r") as f: times = 0 order = 0 for line in f: if " times:" in line: times = int(line.split(" ")[0]) if "order" in line and times > 0: try: line = line.replace(",", "") order = int(line.split(" ")[4]) result += times * int(pow(2, order)) print("times: [{}], order: [{}], result: [{}]".format(times, order, result)) except Exception as e: print(e) finally: times = 0 order = 0 return result if __name__ == "__main__": result = main(FILE_NAME) print("sum: {}M".format((result * PAGE_SIZE / 1024 / 1024)))  

漏洞名称 : Linux Kernel TIPC远程代码执行漏洞组件名称 : Linux Kernel 影响范围 : 5.10-rc1漏洞类型 : 远程代码执行利用条件 :1、用户认证：不需要用户认证2、触发方式：远程综合评价 : <综合评定利用难度>：未知。<综合评定威胁等级>：高危，能造成远程代码执行。漏洞分析：1、组件介绍Linux kernel是美国Linux基金会发布的开源操作系统Linux所使用的内核。Linux内核是一种开源的类Unix操作系统宏内核。整个Linux操作系统家族基于该内核部署在传统计算机平台（如个人计算机和服务器）。2、漏洞描述近日，安全团队监测到一则Linux Kernel TIPC远程代码执行漏洞的信息，漏洞编号：CVE-2021-43267，漏洞威胁等级：高危。TIPC是一种传输层协议，专为在动态集群环境中运行的节点而设计，以比其他协议（如TCP）更高效和容错的方式可靠地相互通信。远程攻击者可以通过TIPC功能以利用MSG_CRYPTO消息类型大小的验证不足来进行攻击。影响范围：Linux操作系统在全世界范围内应用十分广泛。在国内主要应用于浙江、江苏、广东、上海、北京等地区。目前受影响的Linux kernel版本：5.10-rc1解决方案：1、如何检测组件系统版本使用uname -r指令查看Linux内核版本。2、官方修复建议当前官方已发布最新版本，建议受影响的用户及时更新升级到最新版本。链接如下：https://www.kernel.org/

USB输出如下，每隔若干条输出，就会报watchdog isr导致板卡重启Message Queue Get msg:Hello BearPi-HM_Nano!Message Queue Get msg:Hello BearPi-HM_Nano!Message Queue Get msg:Hello BearPi-HM_Nano!Message Queue Get msg:Hello BearPi-HM_Nano!Message Queue Get msg:Hello BearPi-HM_Nano!Message Queue Get msg:Hello BearPi-HM_Nano!**********watchdog isr********************syserr info start**********kernel_ver      : Hi3861V100 R001C00SPC025,2020-09-03 18:10:00**********Exception Information**********PC Task Name    : Thread_MPC Task ID      = 8Cur Task ID     = 8Task Stack Size = 0x2800Exception Type  = 0x80000021**********reg info**********mepc         = 0x3fa866mstatus      = 0x1880mtval        = 0x0mcause       = 0x80000021ccause       = 0x0ra           = 0x3f89b0sp           = 0xfe9c0gp           = 0x11a9c0tp           = 0x7e048208t0           = 0x8t1           = 0xffffffe0t2           = 0x0s0           = 0x200061ds1           = 0x0a0           = 0x200061da1           = 0x0a2           = 0xe4668a3           = 0x0a4           = 0x0a5           = 0xe984ca6           = 0xaa7           = 0x6cs2           = 0x88s3           = 0x12121212s4           = 0x11111111s5           = 0x10101010s6           = 0x9090909s7           = 0x8080808s8           = 0x7070707s9           = 0x6060606s10          = 0x5050505s11          = 0x4040404t3           = 0x0t4           = 0xf27f8t5           = 0x0t6           = 0x4a34ee**********memory info**********Pool Addr    = 0xe8300Pool Size    = 0x302c0Fail Count   = 0x0Peek Size    = 0x15450Used Size    = 0x15450**********task info**********Name         : Thread_MID           = 8Status       = 0x14Stack Index  = 0x8Stack Peak   = 0x270Stack Size   = 0x2800SP           = 0x119880Stack        : 0xfc2e0 to 0xfeae0Real SP      = 0xfe9c0Stack Overflow  = 0**********track_info**********current_item:0x3item_cnt:10Index   TrackType   TrackID  CurTime  Data1  Data20001 0065 0006 0xc00 0x3f5dfa 0x3f5e780002 0065 0008 0xc00 0x3f5e78 0x3f5dfa0003 0016 0007 0xc00 0x3f5dfa 0x00004 0065 0007 0xbfb 0x3f5e78 0x3f5e780005 0065 0008 0xbfb 0x3f5e78 0x3f87a20006 0016 0007 0xbfb 0x3f89e4 0x00007 0016 0007 0xbfc 0x3f5dfa 0x00008 0016 0007 0xbfd 0x3fa86e 0x00009 0016 0007 0xbfe 0x3f87a0 0x00010 0016 0007 0xbff 0x3f5dfa 0x0**********Call Stack**********Call Stack 0 -- 3f89f0 addr:fea7cCall Stack 1 -- 4a1762 addr:fea8cCall Stack 2 -- 4a30c4 addr:feaacCall Stack 3 -- 3f78c0 addr:feaccCall Stack 4 -- 3f5e24 addr:feadc**********Call Stack end**********ready to OS startsdk ver:Hi3861V100R001C00SPC025 2020-09-03 18:10:00FileSystem mount ok.wifi init success!Message Queue Get msg:Hello BearPi-HM_Nano!Message Queue Get msg:Hello BearPi-HM_Nano!Message Queue Get msg:Hello BearPi-HM_Nano!Message Queue Get msg:Hello BearPi-HM_Nano!Message Queue Get msg:Hello BearPi-HM_Nano!Message Queue Get msg:Hello BearPi-HM_Nano!Message Queue Get msg:Hello BearPi-HM_Nano!Message Queue Get msg:Hello BearPi-HM_Nano!Message Queue Get msg:Hello BearPi-HM_Nano!

【功能模块】AR-CORE-220安全可信机制【操作步骤&问题现象】1、AR-CORE-220E上电启动是怎么保证boot,kernel和根文件系统的可信的？2、升级系统时，可信是怎么保证可信3、AR-CORE-220E可信是遵循哪个标准和可信机制？【截图信息】【日志信息】（可选，上传日志内容或者附件）

kernel 中的卷积核介绍：简介卷积核（kernel），也叫卷积矩阵（convolution matrix）或者掩膜（mask），本质上是一个非常小的矩阵，最常用的是 3×3 矩阵。主要是利用核与图像之间进行卷积运算来实现图像处理，能做出模糊、锐化、凹凸、边缘检测等效果。

问题背景与现象安装OMS失败。原因分析查看gaussDB安装日志“/var/log/gaussdbinstall.log”。操作系统shared_buffers参数的值大于kernel.shmmax。解决办法编辑“/etc/sysctl.conf”文件，设置“kernel.shmmax”的值，格式如下。kernel.shmmax = value建议将shmmax的值设置为物理内存大小的一半。可用如下命令查看本机的物理内存：grep MemTotal /proc/meminfo显示类似如下的信息：MeMTotal: 6088240 kB则kernel.shmmax的大小可设置为6088240*1024/2=3117178880。kernel.shmmax = 3117178880执行如下命令，使SUSE Linux启动时自动读取内核参数。/sbin/chkconfig boot.sysctl on执行如下命令使内核参数生效。/sbin/sysctl -p 

GaussDB Kernel ODBC 问题定位指南1         基础知识一个典型的用户应用程序如下： 用户的应用程序，调用的ODBC的API，其实是由驱动管理器提供的，这个驱动管理器在微软上就是odbcad32(.exe/.dll)，在Linux上就是UnixODBC。再由它们来调用ODBC的具体驱动（Gauss、Oracle、TD……）。所以一般问题基本会出在以下几个方面：·         应用加载驱动管理器·         驱动管理器加载驱动·         驱动连接数据库2         问题处理2.1        应用程序加载驱动管理器2.1.1        WindowsWindows由于操作系统实现机制的问题，ODBC属于操作系统组件的一部分，除非操作系统损坏，一般不会出现应用程序加载驱动管理器失败；只会出现驱动管理器加载驱动失败。所以这里不再赘述。2.1.2        LinuxLinux上应用程序加载驱动管理器，是指的应用程序依赖于UnixODBC的相关动态库，启动时要将其加载到自己的进程空间中。加载出现问题多表现为在启动时找不到libodbc.so.x/libodbcinst.so.x等库。解决此问题：1.       首先确认环境中是否安装了UnixODBC。如果安装了，那么至少会有isql/odbcinst等工具可用。例如可使用which isql这样的命令来确定安装路径。相关的lib库一般会在which isql指定的bin目录的同级目录下，将其添加到LD_LIBRARY_PATH中重启应用程序便可。export LD_LIBRARY_PATH=/where/unixodbc/installed/lib:$LD_LIBRARY_PATH特别注意，此语句只影响当前shell会话中的后续命令，其他会话不受影响，特别是后台启动的进程。如果是后台进程，请与应用程序的开发人员确认其运行环境如果修正。2.       如果确认LD_LIBRARY_PATH已经生效（可以打开/proc/应用程序pid/environ文件确认）,依然无法加载libodbc.so.x/libodbcinst.so.x，那么可能是.1或者.2的库的问题。历史原因，一般的开发环境中，UnixODBC提供的库既可能叫libodbc.so.1也可能叫libodbc.so.2。用户程序可能依赖了.2，但是环境中只有.1；也有可能是存在.2，但是依赖了.1。解决此问题，只需要在UnixODBC的lib目录下，将不存在的版本建立成软链接，保证.1与.2都存在，这样出问题的机率便会小很多。特别注意，这里强烈建议是建立软链接，而不要拷贝物理文件，不然可能出现一个应用程序进程中，加载了两个导出函数完全相同的.so，这样可能会引起一些比较难定位的启动错误，后文中会讲到。2.2        驱动管理器加载驱动 2.2.1        Windows最常见x86与x64架构不同，导致的加载失败；此问题的典型报错为：在指定的 DSN 中，驱动程序和应用程序之间的体系结构不匹配此问题可能的原因：在64位程序中使用了32位驱动，或者相反。在64位系统上：·         C:\Windows\SysWOW64\odbcad32.exe：这是32位ODBC驱动管理器。·         C:\Windows\System32\odbcad32.exe：这是64位ODBC驱动管理器。使用不同架构的应用程序时，请使用不同的驱动管理器；同时安装不同的驱动类型。32位系统上只能跑32位程序，也无法安装64位驱动，所以基本不用区分。如果是64位系统，那么它既支持32位程序，也支持64位程序；如果不能确定应用程序是32还是64，可以使用以下办法：1.       ctrl + shift + esc 打开任务管理器2.       查看进程列表中某进程后边有没有*32的字样（有就是32位，没有就是64位），如下图：2.2.2        Linux2.2.2.1       环境中缺少psqlodbcw.so的库一般这个问题的报错是[UnixODBC][Driver Manager]Can't open lib 'xxx/xxx/psqlodbcw.so' : file not found.可能的原因有：1.       odbcinst.ini中配置的路径不正确，最简单的办法是  ls -l 一下这个报错的文件，看看这个是不是真的存在，同时具有执行权限。2.       依赖的库不存在，此时最简单的办法是ldd 一下这个报错的文件，看看是不是真的缺少库，如果缺少库会出现如下问题：要处理这个问题，需要将unixodbc的安装目录下的lib，添加到LD_LIBRARY_PATH里，例如：export LD_LIBRARY_PATH=/where/unixodbc/installed/lib:$LD_LIBRARY_PATH同时，在UnixODBC的安装的lib目录下，看看libodbcinst.so.x后边的后缀是.1还是.2。如果是.2，那么请建立一个软链接，链接到.1，便可以解决此问题。如果该目录下只有.1的库，没有.2的库，也建议建立一个.2的软链接，防止应用程序依赖于.2，我们依赖于.1，引起冲突。特别注意，当前会话的LD_LIBRARY_PATH不代表应用程序运行时也是同样的LD_LIBRARY_PATH，必要的时候，与应用程序开发人员对齐。如果是常驻进程，可以通过如下方法获取到当前进程的环境变量：cd /proc/应用程序PIDcat environ打印出来的结果可能比较乱，耐心看一下；如果内容有误，与应用程序开发人员对齐修改方法。2.2.2.2       既有.2又有.1的库，导致重复加载这种勤快的用户比较少见，但是一旦出现，很难定位，典型的报错信息是：Driver's SQLAllocHandle on SQL_HANDLE_DBC failed这种情况这时应用与驱动加载的是不同的物理文件，便会导致两套完全同名的函数列表，同时出现在同一个可见域里（UnixODBC的libodbc.so.*的函数导出列表完全一致），产生冲突，无法加载数据库驱动。解决此问题的办法也比较简单，查看LD_LIBRARY_PATH中的第一个unixodbc的lib目录。在其目录下，缺少.2或.1，建立对应的.2或.1的软链接便可。2.3        连接问题2.3.1        服务器不可达典型报错：connect to server failed: no such file or directory此问题可能的原因：·         配置了错误的/不可达的数据库地址，或者端口请检查数据源配置中的Servername及Port配置项，确认网络是通达的。·         服务器listen不正确如果确认Servername及Port配置正确，请根据资料中listen_addresses参数的配置方法，确保数据库listen了合适的网卡及端口，特别是Servername中指定的网卡地址及LVS的虚拟IP地址。修改完记得重启数据库，使listen生效。·         防火墙及网闸、流控设备请确认防火墙设置，将数据库的通信端口添加到可信端口中。如果有网闸、流控设备，请确认一下相关的设置。此问题一般都是第三方商业产品导致，需要咨询服务/产品提供商相关的策略。2.3.2        SSL配置不正确典型报错1：The password-stored method is not supported.解决办法1：请将数据源配置中的的sslmode调整至allow及以上级别，允许使用SSL连接。典型报错2：Server common name "xxxx" does not match host name "xxxxx"  此问题是由于sslmode中使用了全校验(verify-full)，它不仅会校验证书，还会校验证书所在的域名/机器名是否与证书符合，不符合时将报出此问题。解决办法2：重新让CA机构以新的域名/机器名签发证书；或者将SSLMODE调整至verify-ca选项或其以下级别（具体级别见产品资料中的说明）。2.3.3        使用开源驱动连接问题我们的数据库是支持低版本及开源驱动的（V1R7C10及以后），所以可以放心使用。但是偶尔一些从V1R6C10升级上来的数据库，接受开源驱动连接时，会碰到用户认证算法不支持的问题，典型报错如下：authentication method 10 not supported.此问题机理比较复杂，下面详细展开，先说解决办法：·         请使用管理新账号新建一个数据库的用户，并给予其相关的访问权限，使用新用户连接数据库。·         更改当前业务用户的密码，使用新密码连接数据库。解释一下此问题发生的机理：我们的数据库在连接时，是会让客户端将认证信息发过来的。但是发过来的信息不会是明文密码，这是不安全的；客户端发到数据库的认证信息一般是经过加盐后的密码哈希(md5/sha256算法)，迭代次数也非常多。数据库本身也并不存储用户的明文密码，存储的是一个哈希值（所以密码要是丢了，就真的丢了，只能重置不能找回）。数据库在校验这个密码的时候，是比较哈希的，这就涉及到数据库中存储的哈希是使用的什么算法得到的哈希值，常见的是sha256（高斯自研）及MD5（开源）。V1R7C00及以前，数据库中只存储了SHA256的哈希，升级时我们也无法推导用户原有密码，所以升级后仍然只有SHA256的哈希；但是开源客户端只识别MD5的哈希，这就导致数据库无法认证；数据库也只会让客户端以SHA256的哈希来做认证，这时开源就不识别该认证请求，导致报出如上的错误。在创建用户和修改用户密码时，我们的新版本会同时记录两份哈希，所以后续将会同时支持开源及自研的各个版本。 2.3.4        因数据源配置不正确，导致的连接错误典型报错：Data source name not found, and no default driver specified可能原因：1.       数据源名称书写错误（或含有特殊符号）2.       不同的操作系统用户下，数据源可见性不一样；3.       Linux上的数据源配置文件(odbc.ini)位置不正确解决办法：1.       修正数据源名称2.       Windows下，请在当前用户下打开驱动管理器，查看数据源配置是否正确。请注意在64位系统上使用正确的数据源管理器：C:\Windows\SysWOW64\odbcad32.exe：这是32位ODBC驱动管理器。C:\Windows\System32\odbcad32.exe：这是64位ODBC驱动管理器。3.       Linux下使用odbcinst -j 命令，查看当前环境中配置文件的正确路径，输出一般如下：unixODBC 2.3.0DRIVERS............: /usr/local/etc/odbcinst.ini/odbcinst.iniSYSTEM DATA SOURCES: /usr/local/etc/odbcinst.ini/odbc.iniFILE DATA SOURCES..: /usr/local/etc/odbcinst.ini/ODBCDataSourcesUSER DATA SOURCES..: /usr/local/etc/odbc.iniSQLULEN Size.......: 8SQLLEN Size........: 8SQLSETPOSIROW Size.: 8其中USER DATA SOURCES就是用户数据源，优先生效；SYSTEM DATA SOURCES是系统数据源，整个系统可用。请针对这些文件路径，注意：有时用户数据源的配置文件可能是$(HOME)/.odbc.ini2.3.5        通信协议不匹配问题典型报错：unsupported frontend protocol 3.51: server supports 1.0 to 3.0可能原因：使用了新版本的数据库驱动连接老版本的数据库(V1R6C10)；或者使用了我们的驱动，连接到了开源的数据库上。解决办法：1.       请使用老版本的数据库驱动连接该数据库。我们的数据库中，默认低版本客户端可以连接高版本数据库；使用高版本驱动连接低版本客户端，不在规格约束范围内。这个规格也比较好理解：因为用户一般是对数据库集中管理，升级也是有计划的。但是客户端驱动可能嵌入到业务中的每一个角落，有时甚至是已经发布的装备中，升级相对比较困难。2.       如果是开源服务器：我们的数据库驱动不支持开源数据库，无法连接；请使用开源客户端连接。3         其他常见疑问3.1        与开源的区别？1.       增加了安全性，使用了SHA256算法做认证加密；同时调整密钥哈希加密次数2.       提升了批量性能（V1R7C10 2019-4-30及以后版本）3.        3.2        是否可以增加新API？不可以。还是基础知识里那张图，用户引用的API是由驱动管理器提供的，我们提供的API只可供驱动管理器使用；新增API无法穿过中间层为用户提供服务。3.3        是否支持COPY接口？Copy是PG的特有语法及通信协议;而ODBC是微软提出的通用调用接口，所以无此特殊接口。3.4        Linux上的驱动管理器有哪些？驱动管理器在Linux上并不是操作系统的一部分，它也是由其他开源组织开发的。所以并不是只有UnixODBC一种。但是目前使用最广泛的，其实只有UnixODBC，多数据操作系统安装时基本都已经自带了UnixODBC的某个特定版本；除此之外，还有iODBC等，现在已经慢慢退出市场了。3.5        UnixODBC的版本有限制么？有。我们支持2.3.0及以上版本。3.6        UnixODBC的.1与.2的库有什么区别？没有什么区别。这个与UnixODBC的历史有关，历史上有一段时间提供.1，后来做了一次大升级，动态库版本也跟着升级了，变成了.2。但是一大批存量业务受制无法运行，就又添加了.1的支持。.1与.2其实只是UnixODBC的configure配置的一部分，其函数导出，功能完全一致，不必纠结于此。3.7        可以打印日志么？可以。一般建议打印驱动管理器的日志，此日志比较清晰，定位问题比较快。操作办法：·         Windows上：打开驱动管理器，调整到跟踪页面，确定日志文件路径后，点击开始跟踪便可，如图：·         Linux上：打开odbcinst.ini文件（可使用odbcinst -j 来确定文件路径），添加以下章节：[ODBC]Trace=YesTraceFIle=/tmp/odbc.log         重启业务便可。3.8        查询结果集过大，内存吃不消怎么办？打开UseDclareFetch开关，它将会把查询包装成游标操作。对于不支持Cursor with hold的版本慎用。同时由于使用了服务器端的游标，游标的前后滚操作也会反馈给数据库，通信会有所增加，所以性能会有部分下降；可以通过调整Fetch参数来确定每次数据库向客户端反馈的数据量大小，来降低该性能影响。·         Linux下打开UseDeclareFetch的方法：在数据源配置项中添加：UseDeclareFetch=1Fetch=1000·         Windows下打开UseDeclareFetch的方法：         其中的Cache Size选项，就是Fetch的大小。 ##如需完整附件，请留下您的邮箱，我们会及时发送给您

#化鲲为鹏，我有话说#ARM（鲲鹏），给您不一样的感觉。eBPF（extended BPF）快速入门（ubuntu版）eBPF是BPF(Berkeley Packet Filter)发展而来的kernel虚拟机，支持在用户态编写kernel代码注入到kernel中运行。具体过程是先用llvm编译得到BPF指令集elf文件，从elf中解析出可注入kernel的部分，用bpf_load_program方法注入。 用户态程序和注入到kernel中的代码通过内核中map通信。为了防止注入的代码导致kernel crash，eBPF会对注入的代码进行检查，拒绝不合格的注入。安装sudo apt-get install bpfcc-tools详解附录：https://www.ibm.com/developerworks/cn/linux/l-lo-eBPF-history/index.htmlhttps://www.lijiaocn.com/%E6%8A%80%E5%B7%A7/2019/02/25/ebpf-introduction-1.html

华为云Linux服务器CentOS 7 的内核一般都是3.10的，而CentOS 6.X 的内核一般都是2.6，在2.6的内核下，Docker运行会比较卡，所以一般会选择升级到3.10版本。 升级内核的方式，网上有很多方法是下载内核然后编译，这样需要安装很多必备的环境和工具，比较麻烦，但是也有助于我们了解内核的编译。 编译内核方式升级： https://segmentfault.com/a/1190000000733628#articleHeader13 本文介绍采用elrepo如何升级到内核。 1. 查看当前内核版本 [code][root@localhost ~]# more /etc/issue CentOS release 6.5 (Final) Kernel \r on an \m [root@localhost ~]# uname -a Linux localhost.localdomain 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux[/code] 2. 导入public key [code][root@localhost ~]# rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org[/code] 3. 安装ELRepo到CentOS 可以去http://elrepo.org/tiki/tiki-index.php选择要安装的ELRepo [code]To install ELRepo for RHEL-7, SL-7 or CentOS-7: rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm (external link) To install ELRepo for RHEL-6, SL-6 or CentOS-6: rpm -Uvh http://www.elrepo.org/elrepo-release-6-8.el6.elrepo.noarch.rpm (external link)[/code] 4. 安装 kernel-lt（lt=long-term） [code][root@localhost ~]# yum --enablerepo=elrepo-kernel install kernel-lt -y[/code] 或者 安装kernel-ml（ml=mainline） [code][root@localhost ~]# yum --enablerepo=elrepo-kernel install kernel-ml -y[/code] 5. 编辑grub.conf文件，修改Grub引导顺序 [code][root@localhost ~]# vim /etc/grub.conf[/code] 因为一般新安装的内核在第一个位置，所以设置default=0，表示启动新内核 6. 重启服务器 查看此时内核版本： [code][root@localhost ~]# uname -r 3.10.105-1.el6.elrepo.x86_64[/code] 大功告成！