Posts Tagged ‘fedora’

RHEL系(Fedora,CentOS) rpm打包

November 6th, 2014

现在Linux下越来越倾向于打包二进制安装文件,rpm,deb都是这种类型。

但是作为内核开发人员我们要对程序进行调试,就要有debug-info package,但是默认内核人是不提供debug-info的包,所以需要我们自动生成。

一般我们要用root用户进行编译,但是编译rpm包,至少需要20GB的临时文件空间!

一键操作:make rpm ———–>自动身成rpmtree,kernel.spec文件,自动编译。

——————————

详细定制:

下面开始创建:

1.用所在的用户输入rpmdev-setuptree,然后会在该用户的目录下生成${HOME}/rpmbuild/SOURCES ,${HOME}/rpmbuild/SPECS 和 ${HOME}/rpmbuild/BUILD 。

2.在多数源玛目录下会自动带有kernel.spec的文件,将这个文件放到${HOME}/rpmbuild/SPECS中,将kernel-3.14.8.tar.gz 放入${HOME}/rpmbuild/SOURCES中,然后在SOURCE中放入.config,

默认生成的spec带着”%debug_package %{nil}” 这就意味着不会生成带debug_info的包。如果需要,我们就要注释掉。

cp .config ~/rpmbuild/SOURCES/config-`uname -m`-generic

3.切换到SPECS目录下。

建立所有内核配置:
rpmbuild -bb –target=`uname -m` kernel.spec

关闭指定的内核配置(为了更快的建立):
rpmbuild -bb –without <option> –target=`uname -m` kernel.spec

其中“ option ”的有效值包括xen、smp、up、pae、kdump、debug 和 debuginfo。指定 –without debug 会剔除内核中的调试代码,指定 –without debuginfo 会禁止建立 kernel-debuginfo 包。

只建立一个特定的内核:
rpmbuild -bb –with <option> –target=`uname -m` kernel.spec
“ option ”的有效值包括 xenonly、 smponly 和 baseonly 。

例如,只建立 kernel 和 kernel-devel 包的命令是:

rpmbuild -bb –with baseonly –without debuginfo –target=`uname -m` kernel.spec
建立时包含固件,用如下命令:

rpmbuild -bb –with baseonly –with firmware –without debuginfo  –target=`uname -m` kernel.spec
建立的过程需要很长时间。会在屏幕上打印大量的信息。这些信息可以被忽略,除非建立过程因为一个 error 而停止。如果成功完成建立过程,一个新的内核包会出现在 ~/rpmbuild/RPMS 目录。

 

参考:

https://fedoraproject.org/wiki/Building_a_custom_kernel
https://fedoraproject.org/wiki/How_to_create_an_RPM_package/zh-cn
http://blog.csdn.net/justlinux2010/article/details/9905425
http://www.linuxfly.org/post/130/

kdump 在Debian/Fedora/CentOS下的配置

November 1st, 2014

Update 2014/11/6

0.why we use kdump?

Kdump is a kernel crash dumping mechanism and is very reliable because the crash dump is captured from the context of a freshly booted kernel and not from the context of the crashed kernel. Kdump uses kexec to boot into a second kernel whenever system crashes. This second kernel, often called the crash kernel, boots with very little memory and captures the dump image.

The first kernel reserves a section of memory that the second kernel uses to boot. Kexec enables booting the capture kernel without going through the BIOS, so contents of the first kernel’s memory are preserved, which is essentially the kernel crash dump.
使用mce-inject注入fatal错误的时候,system会直接panic。不像UCNA,SRAO等可以通过mcelog,rasDamon查看。
system在进去machine check 后,内核调用,用户态下的mcelog,rasDamon都已经无法使用,导致dmesg信息MCE解码信息都无法查看。

kdump原理就是在dump kernel panic后,重新启动后利用kexec载入debug kernel 然后利用这个内核去dump出现panic错误的内核信息。

然后system使用正常kernel启动后,可以分析该dump文件,包括查看demsg/memory/PCIe等各种kernel信息等。
用来诊断kernel出现了哪些致命错误。
在本项目中主要利用该工具用来分析注入mce 错误产生的dumpcore信息。
————————————————————————–

首先我们分清要使用的系统:

1.Fedora Configure

由于Fedora的软件比较新,如果你用的是是Fedora 20

我们直接可以 yum install –enablerepo=fedora-debuginfo –enablerepo=updates-debuginfo kexec-tools crash kernel-debuginfo
下载安装好kdump crash kexec工具

2.然后我们在/etc/default/grub里面的

GRUB_CMDLINE_LINUX=”rd.lvm.lv=fedora/swap rd.md=0 rd.dm=0 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkerne l-param || 🙂 rd.luks=0 vconsole.keymap=us rd.lvm.lv=fedora/root rhgb quiet crashkernel=240M”
最后加入crashkernel=240M

这个预先留出的内存大小,在下次使用就被占用。
一般 1G——80M 2G——-160M 3G——–240M

最后更新grub :$grub2-mkconfig -o /boot/grub2/grub.cfg 即可

3.重新启动,选择该内核进入system

[root@localhost mce-inject-encode]# service kdump start
Redirecting to /bin/systemctl start kdump.service
[root@localhost mce-inject-encode]# systemctl status kdump
kdump.service - Crash recovery kernel arming
Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled)
Active: active (exited) since 一 2014-10-27 09:15:31 CST; 2 days ago
Process: 652 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
Main PID: 652 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/kdump.service

10月 27 09:15:22 localhost.localdomain systemd[1]: Starting Crash recovery kernel arming...
10月 27 09:15:31 localhost.localdomain kdumpctl[652]: kexec: loaded kdump kernel
10月 27 09:15:31 localhost.localdomain kdumpctl[652]: Starting kdump: [OK]
10月 27 09:15:31 localhost.localdomain systemd[1]: Started Crash recovery kernel arming.
10月 29 09:29:36 localhost.localdomain systemd[1]: Started Crash recovery kernel arming.

4.开始等待panic错误,如果发现panic错误,system会立刻切换到crashkernel收集信息,收集完毕重新启动。

5.进入到system。键入到/var/crash文件夹下有通过kdump产生的文件:

[root@localhost 127.0.0.1-2014.10.29-09:59:07]# ls
vmcore vmcore-dmesg.txt
[root@localhost 127.0.0.1-2014.10.29-09:59:07]# vim vmcore-dmesg.txt

[175451.136453] Triggering MCE exception on CPU 0
[175451.136463] [Hardware Error]: MC0 Error:
[175451.136467] [Hardware Error]: Corrupted MC0 MCE info?
[175451.136469] [Hardware Error]: Error Status: System Fatal error.
[175451.136472] [Hardware Error]: CPU:0 (f:6b:2) MC0_STATUS[-|UE|-|PCC|-]: 0xb200000000000000
[175451.136475] [Hardware Error]: cache level: RESV, tx: INSN
[175451.136480] mce: [Hardware Error]: CPU 0: Machine Check Exception: 0 Bank 0: b200000000000000
[175451.136662] mce: [Hardware Error]: TSC 15f2d1714af92
[175451.136765] mce: [Hardware Error]: PROCESSOR 2:60fb2 TIME 1414547938 SOCKET 0 APIC 0 microcode 0
[175451.136933] [Hardware Error]: MC0 Error:
[175451.137020] [Hardware Error]: Corrupted MC0 MCE info?
[175451.137132] [Hardware Error]: Error Status: System Fatal error.
[175451.137249] [Hardware Error]: CPU:0 (f:6b:2) MC0_STATUS[-|UE|-|PCC|-]: 0xb200000000000000
[175451.137412] [Hardware Error]: cache level: RESV, tx: INSN
[175451.137431] mce: [Hardware Error]: Machine check: Invalid
[175451.137431] Kernel panic - not syncing: Fatal machine check on current CPU

通过vmcore-dmesg.txt 可以查看panic时的dmesg 。如果需要对panic core 进行debug的时候,需要
使用[root@localhost 127.0.0.1-2014.10.29-09:59:07]# crash vmcore /usr/lib/debug/lib/xxxxxx/vmlinux

PS:注意这个vmcore与你的debugcore 版本要一致否则无法进行crash!

创建kernel-debuginfo-devel
https://fedoraproject.org/wiki/Building_a_custom_kernel
https://fedoraproject.org/wiki/How_to_create_an_RPM_package/zh-cn
http://blog.csdn.net/justlinux2010/article/details/9905425
http://www.linuxfly.org/post/130/

具体操作看http://www.lizhaozhong.info/archives/1143

——————————————————————————————————

CentOS 7 Configure

CentOS 7 与 Fedora很类似,这个发行版在程序安装的时候就提供了kdump配置,为了我们手动安装,我们先手动关闭。

CentOS 7 与 Fedora操作类似,都是使用yum机制安装程序。在本项目中,我制作了kernel-3.14.8.rpm包,方便后期注入使用。

CentOS 7 使用了systemctl管理系统service ,当我们安装完成3.14.8 内核,与kdump-tools等工具链。
配置文件放在/etc/sysconfig/kdump中

当然我们要在/etc/default/grub中定义crashkernel的大小,重启以后,使用systemctl enable kdump.service 设置为开机启动。
systemctl start kdump.service 启动kdump.service 服务。
systemctl status kdump.service 可以查看该服务状态:

[root@localhost sysconfig]# systemctl status kdump.service -l
kdump.service - Crash recovery kernel arming
Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled)
Active: active (exited) since 一 2014-12-22 09:10:30 EST; 1 day 11h ago
Process: 809 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
Main PID: 809 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/kdump.service

12月 22 09:10:27 localhost.localdomain kdumpctl[809]: cat: /sys/kernel/security/securelevel: No such file or directory
12月 22 09:10:30 localhost.localdomain kdumpctl[809]: kexec: loaded kdump kernel
12月 22 09:10:30 localhost.localdomain kdumpctl[809]: Starting kdump: [OK]
12月 22 09:10:30 localhost.localdomain systemd[1]: Started Crash recovery kernel arming.

当遇到panic事件后,kdump会转储故障内核,重新启动后,我们以可以在/var/crash下找到vmcore

具体加载vmcore方式是使用
[root@localhost 127.0.0.1-2014.12.22-09:09:51]# crash vmcore /boot/vmlinux-3.14.8.bz2

/boot/vmlinux-3.14.8.bz2 是我们自己打包的rpm包,带有debug symbol 的 镜像,可以用于debug vmcore

————————————
Debian Configure

因为在本项目中我们使用kernel 3.14.8,所以我们要使用crash 7.0.8.在Deibian 7.6中,默认的crash 6.0.6版本中
无法分析kernel 3.6以及以后内核的SLAB内存,crash载入dump文件,会出现以下错误信息:

please wait... (gathering kmem slab cache data)
crash: invalid structure member offset: kmem_cache_s_next
FILE: memory.c LINE: 7903 FUNCTION: kmem_cache_init()
[/usr/bin/crash] error trace: 466a99 =&gt; 47b44b =&gt; 491f5c =&gt; 547d43
547d43: OFFSET_verify+164
491f5c: (undetermined)
47b44b: vm_init+10841
466a99: main_loop+239

一个方法是我们可以在/etc/apt/source.list 中将wheezy改为jessie,可以顺利将crash升级到7.0.8

Debian Configure 有一个问题是需要手动配置crashkernel 内核地址

1. aptitude install kdump-tools crash kexec-tools makedumpfile

2.在 /etc/default/grub中修改为GRUB_CMDLINE_LINUX_DEFAULT=”crashkernel=128M quiet”

3.# update-grub2
4.里面的DEBUG_KERNEL也要对应产生的vmcore版本,进行crash时vmcore与这个debug_kernel must版本一致!

主要是在编译内核的目录下使用make deb-pkg 这时会产生专门针对3.14.8内核的dbg vmlinux,以及header

root@debian:/usr/src/kernels# ls
linux-3.14.8 linux-headers-3.14.8_3.14.8-2_amd64.deb linux-libc-dev_3.14.8-2_amd64.deb
linux-3.14.8.tar linux-image-3.14.8_3.14.8-2_amd64.deb
linux-firmware-image-3.14.8_3.14.8-2_amd64.deb linux-image-3.14.8-dbg_3.14.8-2_amd64.deb

然后安装这些生成的deb.
5.在/etc/default/kdump-tools中配置为

USE_KDUMP=1
KDUMP_SYSCTL="kernel.panic_on_oops=1"
KDUMP_KERNEL=/boot/vmlinuz-3.14.8
KDUMP_INITRD=/boot/initrd.img-3.14.8
KDUMP_COREDIR="/var/crash"
KDUMP_FAIL_CMD="reboot -f"
DEBUG_KERNEL=/usr/lib/debug/boot/vmlinux-3.14.8
MAKEDUMP_ARGS="-c -d 31"

//在/etc/default/kexec中配置为:
root@debian:/usr/src/kernels# cat /etc/default/kexec
# Defaults for kexec initscript
# sourced by /etc/init.d/kexec and /etc/init.d/kexec-load

# Load a kexec kernel (true/false)
LOAD_KEXEC=true

# Kernel and initrd image
KERNEL_IMAGE="/boot/vmlinuz-3.14.8"
INITRD="/boot/initrd.img-3.14.8"

# If empty, use current /proc/cmdline
APPEND=""

# Load the default kernel from grub config (true/false)
USE_GRUB_CONFIG=false

6.重新启动:

root@debian:/usr/src/kernels# service kdump-tools restart
[ ok ] unloaded kdump kernel.
[ ok ] loaded kdump kernel.

7.kdump就开始捕捉错误。

8.关于分析dump的操作crash

This GDB was configured as "x86_64-unknown-linux-gnu"...

      KERNEL: kernel_link
    DUMPFILE: dump.201410311601  [PARTIAL DUMP]
        CPUS: 2
        DATE: Fri Oct 31 16:01:04 2014
      UPTIME: 00:09:57
LOAD AVERAGE: 0.21, 0.11, 0.07
       TASKS: 209
    NODENAME: debian
     RELEASE: 3.14.8
     VERSION: #2 SMP Fri Oct 31 14:38:20 CST 2014
     MACHINE: x86_64  (2199 Mhz)
      MEMORY: 1.7 GB
       PANIC: "Kernel panic - not syncing: Fatal machine check on current CPU"
         PID: 0
     COMMAND: "swapper/1"
        TASK: ffff88006d7ea8e0  (1 of 2)  [THREAD_INFO: ffff88006d7ee000]
         CPU: 1
       STATE: TASK_RUNNING (PANIC)

crash> help

*              files          mach           repeat         timer
alias          foreach        mod            runq           tree
ascii          fuser          mount          search         union
bt             gdb            net            set            vm
btop           help           p              sig            vtop
dev            ipcs           ps             struct         waitq
dis            irq            pte            swap           whatis
eval           kmem           ptob           sym            wr
exit           list           ptov           sys            q
extend         log            rd             task           

crash version: 7.0.8    gdb version: 7.6
For help on any command above, enter "help <command>".
For help on input options, enter "help input".
For help on output options, enter "help output".

crash>

参考:

http://wiki.incloudus.com/display/DOC/Debian+-+Kdump
http://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes
http://debian-handbook.info/browse/stable/sect.kernel-compilation.html

推荐一个fedora非常好用的gnome-shell扩展。

July 17th, 2013

官方网站:

http://intgat.tigress.co.uk/rmy/extensions/index.html

» Read more: 推荐一个fedora非常好用的gnome-shell扩展。

Effective in GNOME3

July 15th, 2013

Even with the latest version of GNOME 3 looking a whole lot better than earlier versions, I still find that it is not suitable for my daily desktop computing. But thanks to a couple of extensions, I can customize my GNOME 3 desktop to suite me, in a manner that makes for a more productive time in front of the monitor.

» Read more: Effective in GNOME3

记录一下fedora18安装后,需要安装的一些必备的软件包:

June 13th, 2013

1. 安装fedora18后的初始化配置

1.1. 防火墙

如果你的电脑处于局域网内,那么防火墙是不需要的的,停止它!

sudo systemctl stop firewalld.service
sudo systemctl disable firewalld.service

» Read more: 记录一下fedora18安装后,需要安装的一些必备的软件包: