CentOS 7은 grub.cfg의 커널 메뉴 항목을 잘못 정렬합니까?

CentOS 7은 grub.cfg의 커널 메뉴 항목을 잘못 정렬합니까?

CentOS 7 시스템에서 grub 메뉴 항목의 예상치 못한 순서를 발견했습니다.

다음 커널을 설치합니다.

$ ls /boot/vmlinuz* -ltr
Jun 30 14:17 /boot/vmlinuz-3.10.0-123.el7.x86_64
Nov  6 16:14 /boot/vmlinuz-3.10.0-123.9.3.el7.x86_64
Nov 23 17:12 /boot/vmlinuz-0-rescue-c61cbe0918ab45e0927fb5d31cf45f98

버전 구성표를 해석해 보면 버전 "3.10.0-123.9.3.el7"이 "3.10.0-123.el7"보다 큽니다. 이는 mtime 파일과도 일치하며 uname -a출력과도 일치합니다.

3.10.0-123.el7.x86_64     Mon Jun 30 12:09:22 UTC 2014
3.10.0-123.9.3.el7.x86_64 Thu Nov 6  15:06:03 UTC 2014

그러나 /boot/grub2/grub.cfg다른 명령을 사용하십시오.

$ grep vmlinuz-3 /boot/grub2/grub.cfg | sed 's/root=.*//'
linux16 /vmlinuz-3.10.0-123.el7.x86_64 
linux16 /vmlinuz-3.10.0-123.9.3.el7.x86_64

아?

시스템은 몇 가지 추가 커널 매개변수를 가져오므로 다음을 grub.cfg사용하여 명시적으로 재구축됩니다.

# grub2-mkconfig -o /boot/grub2/grub.cfg 

어느 것이되어야합니까?공식적인 방법- 설명서에 나와 있는 대로입니다.

이 정렬은 다음과 같은 방법으로 수행됩니다.

/etc/grub.d/10_linux
  -> /usr/share/grub/grub-mkconfig_lib
     -> version_find_latest()
        -> version_test_gt()

이것은 grub2-mkconfig의 잘 알려진 버그입니까?

그러나 이에 대한 버그 보고서를 찾을 수 없습니다.

놀랍게도 다른 CentOS 7 시스템(역시 최신)에서는 grub.cfg 순서가 정확합니다.

$ grep vmlinuz /boot/efi/EFI/centos/grub.cfg | sed 's/root=.*//'
linuxefi /vmlinuz-3.10.0-123.9.3.el7.x86_64 
linuxefi /vmlinuz-3.10.0-123.9.2.el7.x86_64 
linuxefi /vmlinuz-3.10.0-123.8.1.el7.x86_64 
linuxefi /vmlinuz-3.10.0-123.6.3.el7.x86_64 
linuxefi /vmlinuz-3.10.0-123.el7.x86_64 
linuxefi /vmlinuz-0-rescue-48235f1ad5c943c3a7dfd1551a1fc5b8 

두 시스템의 차이점은 grub2-mkconfig두 번째 시스템에서는 수동으로 실행되지 않았다는 것입니다.

실제로 수동으로 실행하면 순서도 잘못됩니다.

# grub2-mkconfig -o del.cfg
# grep vmlinuz del.cfg | sed 's/root=.*//' 
linuxefi /vmlinuz-3.10.0-123.el7.x86_64 
linuxefi /vmlinuz-3.10.0-123.9.3.el7.x86_64 
linuxefi /vmlinuz-3.10.0-123.9.2.el7.x86_64 
linuxefi /vmlinuz-3.10.0-123.8.1.el7.x86_64 
linuxefi /vmlinuz-3.10.0-123.6.3.el7.x86_64 
linuxefi /vmlinuz-0-rescue-48235f1ad5c943c3a7dfd1551a1fc5b8

yum update그러면 커널을 설치하여 업데이트를 하면 설치 스크립트가 실행되지 않는 것 같습니다 grub-2-mkconfig -o /boot/efi/EFI/centos/grub.cfg. grub.cfg그러면 커널 패키지 설치 중에 어떻게 다시 생성할 수 있나요?

답변1

이것은 잘 알려진 오류입니다.

커널 패키지가 업데이트되는 방식을 확인하려면 다음을 grub.cfg통해 스크립트를 표시할 수 있습니다.

$ yum whatprovides /boot/vmlinuz-3.10.0-123.9.3.el7.x86_64
kernel-3.10.0-123.9.3.el7.x86_64 : The Linux kernel
[..]
$ rpm -q --scripts kernel-3.10.0-123.9.3.el7.x86_64

이는 /usr/sbin/new-kernel-pkg호출되고 있음을 나타냅니다.더러운.

해결책

(RHEL/CentOS에서 수정될 때까지)

--- /usr/share/grub/grub-mkconfig_lib.orig 2014-06-30 18:16:11.000000000 +0200
+++ /usr/share/grub/grub-mkconfig_lib 2014-11-26 17:38:57.814000000 +0100
@@ -255,13 +255,24 @@

 버전_찾기_최신(​​)
 {
- version_find_latest_a=""
- 나는 "$@"에 대해
- version_test_gt "$i" "$version_find_latest_a" 인 경우;
- version_find_latest_a="$i"
-fi
- 완성된
- 에코 "$version_find_latest_a"
+ # https://bugzilla.redhat.com/show_bug.cgi?id=1124074에 대한 솔루션
+ # 'grub2-mkconfig 정렬 오류'
+ {
+ "$@"의 경우;
+ $i를 에코합니다.
+ 완료 | grep -v 구조 정렬 -V |
+ "$@"의 경우;
+ $i를 에코합니다.
+ 완료 | grep 구조 정렬 -V |
+ } |헤드-n 1
 }

답변2

실제로 문제를 해결한 두 개의 bugzilla.redhat.com 버그 패치를 게시했습니다. maxschlepzig의 패치는 정답에 매우 가깝지만 정답은 아닙니다. 내 패치는 그의 패치를 기반으로 합니다.

답변3

커널을 설치한 후 무슨 일이 일어났는지 판단하는 방법은 rpm+ --scripts스위치를 사용하면 다음과 같다고 생각합니다.

$ rpm --scripts -q kernel-$(uname -r)
postinstall scriptlet (using /bin/sh):

if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&
   [ -f /etc/sysconfig/kernel ]; then
  /bin/sed -r -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/' /etc/sysconfig/kernel || exit $?
fi
preuninstall scriptlet (using /bin/sh):
/bin/kernel-install remove 3.16.6-203.fc20.x86_64 /boot/vmlinuz-3.16.6-203.fc20.x86_64 || exit $?
posttrans scriptlet (using /bin/sh):
/bin/kernel-install add 3.16.6-203.fc20.x86_64 /boot/vmlinuz-3.16.6-203.fc20.x86_64 || exit $?

이는 여러 부분으로 나누어져 있습니다.설치 후,사전 제거, 그리고우편 집배원. 커널 설치/제거를 수행하는 도구는 다음 스크립트입니다.

/bin/kernel-install add <kernel label> </path/to/boot/vmlinuz-...> || exit $

이 스크립트의 소유자는 누구입니까?

이 스크립트는 kernel-installSystemd의 일부입니다.

$ rpm -qf /bin/kernel-install 
systemd-208-28.fc20.x86_64

관련 정보