Linux入門之CentOS7內核編譯三部曲(3)
在上篇通過一些簡單的例子和使用介紹了linux系統中模塊的功能和作用。那麼每次系統啓動完成之後,又是怎麼去自動加載所需要的模塊,那麼回過頭來看還是要連續模塊加載具體在系統啓動中的哪個階段開始觸發的。同時模塊的加載是依據內核本身的預定程序,還是linux文件系統中的相應配置文件呢?
默認安裝的模塊文件路徑:/lib/modules/$(uname -r)/kernel,如:
#查看內核模塊列表目錄
[root@localhost ~]# ls /usr/lib/modules/$(uname -r)/kernel arch crypto drivers fs kernel lib mm net sound
#當然還有另外一個目錄 /usr/lib/modules/$(uname -r)/kernel
[root@localhost ~]# ls /usr/lib/modules/$(uname -r)/kernel arch crypto drivers fs kernel lib mm net sound
注:在CentOS6之前是默認是存放在/lib/modules目錄下的,並沒有在/usr/lib/modules下存放,但是在安裝 CentOS7之後會發現有兩個目錄都存放了內核模塊文件。
#其實是CentoOS7爲了保留原來的結構,添加了軟連接
[root@localhost ~]# ls -dl /usr/lib /lib lrwxrwxrwx. 1 root root 7 Sep 7 16:11 /lib -> usr/lib dr-xr-xr-x. 27 root root 4096 Sep 7 16:17 /usr/lib
具體操作模塊的基本命令及常見方法:
查看當前已經加載的模塊
cat /proc/modules#通過映射文件
lsmod#通過命令工具
實例:
#查找ext4文件系統相關的模塊
[root@localhost ~]# grep '\<ext4\>' /proc/modules ext4 507694 3 - Live 0xffffffffa018e000 mbcache 14958 1 ext4, Live 0xffffffffa004c000 jbd2 98466 1 ext4, Live 0xffffffffa0174000 [root@localhost ~]# lsmod | grep '\<ext4\>' ext4 507694 3 mbcache 14958 1 ext4 jbd2 98466 1 ext4
查看具體指定模塊的信息
modinfo module_name
查看指定包的依賴
modprobe --show-depends module_name
例子:查看ext4的相關的依賴包
#通過命令查詢
[root@mzf ~]# modprobe --show-depends ext4 insmod /lib/modules/2.6.32-642.el6.x86_64/kernel/fs/mbcache.ko insmod /lib/modules/2.6.32-642.el6.x86_64/kernel/fs/jbd2/jbd2.ko insmod /lib/modules/2.6.32-642.el6.x86_64/kernel/fs/ext4/ext4.ko
#通過depmod生成的配置文件查詢
[root@mzf ~]# grep '\<ext4\>' /lib/modules/$(uname -r)/modules.dep kernel/fs/ext4/ext4.ko: kernel/fs/jbd2/jbd2.ko kernel/fs/mbcache.ko
#當然如果此模塊已經被加載,也可以通過 lsmod查看依賴
[root@mzf ~]# lsmod | grep '\<ext4\>' ext4 379655 3 jbd2 93252 1 ext4 mbcache 8193 1 ext4
查看模塊具體參數
modprobe -c
#查看isofs的具體參數
[root@mzf ~]# modprobe -c | grep '\<isofs\>' alias iso9660 isofs
解析:這裏沒有額外的內核參數,但是定義了一個別名爲iso9660表示。
查看指定模塊加載時使用的選項
systool -v -m module_name
#查看ext4的具體選項屬性
手動加載卸載模塊
modprobe modprobe_name #指定模塊名稱卸載模塊 modprobe -r modprobe_name #指定模塊名稱卸載模塊 insmod /path/to/modprobe.ko #指定模塊文件路徑加載模塊 rmmod /path/to/modprobe.ko #指定模塊文件路徑卸載模塊
解析:可以通過modinfo -n module_name來查看模塊的文件存放路徑,如果此模塊功能正在被程序使用中,是不會被卸載掉的,如果想卸載,可以使用 -f選項進行強制卸載,modprobe和rmmod都支持此選項,但是不建議強制卸載,除非出現系統故障。
模塊功能的高級配置
在CentOS6系統開始,使用了udev加載機制,所有必須的模塊的加載均由udev自動完成。所以,如果不需要任何額外的模塊,就沒有必要在任何配置文件中添加啓動時加載的模塊。但是,有些情況下可能需要在系統啓動時加載某個額外的模塊,或者將某個模塊列入黑名單以便使系統正常運行。
開機的模塊加載
systemd進程讀取/etc/modules-load.d/目錄中的配置配置文件加載額外的內核模塊,配置文件名通常爲/etc/modules-load.d/<program>.conf,格式很簡單,一行一個要讀取的模塊名,而空行以及第一個非空白字符爲#或;的行會被忽略,如:
#查看虛擬化驅動目錄
[root@localhost ~]# ls /usr/lib/modules/3.10.89/kernel/drivers/virtio/ virtio_balloon.ko virtio.ko virtio_pci.ko virtio_ring.ko
#希望開機加載額外的virtio-net驅動
[root@localhost ~]# vim /etc/modules-load.d/virtio.conf [root@localhost ~]# cat /etc/modules-load.d/virtio.conf # Load virtio.ko at boot virtio
提示:具體配置可以查看man幫助手冊,man 5 modules-load.d
小案例:解決光盤不能掛載,系統無法識別光盤文件系統。
#掛載光盤,發現掛載出錯
[root@localhost ~]# mount /dev/cdrom /mnt/cdrom/ mount: unknown filesystem type 'iso9660'
說明:這裏提示了未識別的文件系統 iso8660類型,開始推測是不是需要掛載時指定類型,是mount的掛載時出了問題,於是,再次掛載。
#再次掛載,並用mount -t指定類型
[root@localhost ~]# mount -t ISO9660 /dev/cdrom /mnt/cdrom mount: unknown filesystem type 'ISO9660'
說明:仍然不行,難當當前系統內核不支持iso9660文件系統?於是查看當前系統內核模塊支持的文件系統類別。
#查看當前內核支持的文件系統
[root@localhost ~]# cat /proc/filesystems nodevsysfs nodevrootfs nodevbdev nodevproc nodevcgroup nodevcpuset nodevtmpfs nodevdevtmpfs nodevdebugfs nodevsecurityfs nodevsockfs nodevpipefs nodevanon_inodefs nodevconfigfs nodevdevpts nodevramfs nodevhugetlbfs nodevautofs nodevpstore nodevmqueue nodevselinuxfs ext4
說明:其中nodev表示已經加載此功能但是沒有被設備或進程使用,左側顯示空白字符,表示此設備正在被使用。因此發現有autofs 自動掛載功能,就沒有iso9660的文件系統模塊。
#於是開始查看iso9660需要的模塊,在查看前,先使用depmod命令重新生成依賴配置
[root@localhost ~]# depmod -a
#然後通過濾iso來查找對應的配置文件
[root@localhost ~]# grep '\<iso' /usr/lib/modules/$(uname -r)/modules.dep kernel/fs/isofs/isofs.ko:
解析:這裏搜索到了isofs文件系統模塊,而且:後面沒有其它模塊說明此模塊沒有依賴於其它模塊,因此可以直接加載此模塊。
#加載模塊,但是顯示的相對於/usr/lib/modules/版本號/下的kernel目錄,要加全路徑
[root@localhost ~]# insmod /usr/lib/modules/$(uname -r)/kernel/fs/isofs/isofs.ko
#檢查是否已經加載isofs模塊
[root@localhost ~]# lsmod | grep '\<isofs\>' isofs 39846 0 [root@localhost ~]# grep '\<isofs\>' /proc/modules isofs 39846 0 - Live 0xffffffffa022b000
#確定加載isofs模塊後,再次嘗試掛載
[root@localhost ~]# mount /dev/cdrom /mnt/cdrom/ mount: /dev/sr0 is write-protected, mounting read-only
#查看是否已經掛載成功
[root@localhost ~]# findmnt /dev/cdrom TARGET SOURCE FSTYPE OPTIONS /mnt/cdrom /dev/sr0 iso9660 ro,relatime
#將isofs文件系統模塊設置開啓自動加載,修改配置文件
[root@localhost ~]# cat /etc/modules-load.d/virtio.conf # Load virtio.ko at boot virtio #這裏表示模塊名稱
解析:文件名一般建議設置爲模塊的名稱,下面沒一行都可以添加一個模塊名稱,開機會自動從這些配置文件中逐行加載每個指定模塊名稱模塊。
#然後reboot重啓測試
[root@localhost ~]# reboot
#重啓機器後,查看當前是否已經加載了isofs模塊
[root@localhost ~]# lsmod | grep '\<isofs\>' isofs 39846 0 [root@localhost ~]# grep '\<isofs\>' /proc/modules isofs 39846 0 - Live 0xffffffffa0129000
#再次查看此時內核支持的文件系統列表
[root@localhost ~]# cat /proc/filesystems
解析:這裏顯示有剛纔設置的iso9660表示此格式以後開啓都會被加載,就不會再遇到iso9660格式的鏡像文件系統格式不支持了。
總結以及問題遺留:
本片接上篇再次整理了一下模塊管理的相關命令以及其用法,同時補充了一個遇到的問題來說明模塊管理的一些思路。無論是文件系統、硬件設備驅動、以及服務調用,只要功能不能支持,那麼很有可能就是模塊功能沒有正常加載,這點和程序文件需要依賴於相應的庫文件一樣,密不可分。模塊的加載都是通過一些配置,那麼這些模塊又是通過內核中的什麼機制去讀取modprobe.conf配置去加載相應的模塊參數的呢?又是怎麼根據加載硬件驅動後把對應識別到的每個硬件識別一個可訪問的文件呢?這些都是留下的疑問?當然模塊的問題只有不斷的能深刻處理才能去處理之後的加載機制問題。