배포판이 아니라 Linux 커널이 커스텀 (컴파일)인지 알 수 있습니까?

10

우분투를 예로 들어서, 배포판에 포함 된 것이 아니라 커널이 커스텀 컴파일되었는지 알 수 있습니까?

ubuntu  linux-kernel 
— 바이트 파이어
소스
이 글타래를 확인하십시오 : unix.stackexchange.com/questions/43164/…
— nomadrc
2
음, 단지 바이너리 패키지 파일과 비교 ... 볼, 그것은 원래의 커널이 있는지 여부 또는이 변경되었는지 여부를 ..
— kravemir

답변:

13

물론, dpkg알고 있는지 확인 하십시오.

먼저 실행중인 커널 버전을 확인하십시오.

uname -a
Linux orwell 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux

그런 다음 데이터베이스 dpkg에서 커널 이미지 파일을 검색하도록 지시하십시오 dpkg.

dpkg -S /boot/vmlinuz-3.2.0-4-amd64
linux-image-3.2.0-4-amd64: /boot/vmlinuz-3.2.0-4-amd64

또는 패키지 dlocate에서 사용 하는 것이 좋습니다 dlocate. dlocate먼저 dpkg데이터베이스 에서 캐시를 빌드하고 이를 사용합니다. 그래서 빠릅니다.

dlocate /boot/vmlinuz-3.2.0-4-amd64
linux-image-3.2.0-4-amd64: /boot/vmlinuz-3.2.0-4-amd64

마지막으로 데비안 아카이브에이 패키지가 포함되어 있는지 확인하십시오.

apt-cache policy linux-image-3.2.0-4-amd64

linux-image-3.2.0-4-amd64:
  Installed: 3.2.68-1+deb7u1
  Candidate: 3.2.68-1+deb7u1
  Version table:
 *** 3.2.68-1+deb7u1 0
        500 http://security.debian.org/ wheezy/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     3.2.65-1 0
        500 http://httpredir.debian.org/debian/ wheezy/main amd64 Packages

그렇지 않은 경우 사용자 정의 패키지입니다. 물론 dpkg가 이미지 파일을 모른다면 커널은 패키지의 일부가 아니지만 로컬로 컴파일 된 것입니다.

참고 apt 수 데비안 아카이브에 패키지와 동일한 이름의 로컬로 컴파일 된 하나의 차이를 말한다. 패키지의 md5sum을 확인한다고 생각하지만 그 방법에 대한 세부 정보는 잊어 버렸습니다. 이진 패키지에는 해시에 대한 정보가 포함되어 있습니다 ( apt-cache show linux-image-3.2.0-4-amd64예 : 하단 참조) . 예 :

Package: linux-image-3.2.0-4-amd64
Source: linux
Version: 3.2.68-1+deb7u1
Installed-Size: 105729
[...]
Size: 23483788
MD5sum: f9736f30f8b68ae79b2747d8a710ce28
SHA1: 64bfde903892801dccd04b52b12316901a02cd96
SHA256: 775814b3eff4a964b593c0bdeaac20587a4e3ddb1257a9d2bfcf1e9d3b9bfd15
— 파힘 미타
소스
1
exussum의 답변에 대한 의견을 참조하십시오. 다른 옵션을 사용하여 동일한 커널을 재결합하지만 다른 이름을 지정하지 않으면 어떻게됩니까?
— terdon
@terdon은 편집을 참조하십시오.
— Faheem Mitha
2
아, 그렇습니다, 해시는 똑똑해야합니다!
— terdon
이 방법은 대부분의 경우 작동하지만 로컬로 컴파일 된 패키지를위한 전용 리포지토리가 있으므로 로컬에서 컴파일 된 패키지를 사용하는 경우에도 공급 업체 패키지로 표시됩니다. 물론 공급 업체 패키지에 버전의 일부로 공급 업체 이름이 있으므로 내 패키지의 이름이 다르기 때문에 차이점을 쉽게 확인할 수 있습니다.
— 3
1
@bytefire가 apt-cache show ...작동합니다. 내가 잘못 입력 한 것을 봅니다. 지금 수정 중입니다.
— Faheem Mitha
7

최소한, uname -r같은 커널 버전을 제공합니다 3.18.6. 그러나 커널이 컴파일 될 때 추가 문자열을 구성하고 이에 연결할 수 있으며 배포판은 일반적으로 (대시 후) 자체 패치 수준 및 풍미를 나타 내기 위해이를 수행합니다 3.18.6-32-generic. 그것은 하나의 단서입니다. 사용자 정의 커널을 만들 때 분명히 자신의 문자열을 사용하는 것은 다른 것일 수 있습니다.

uname -v 기본적으로 다음과 같은 문자열을 제공합니다

#4 SMP PREEMPT Mon Mar 9 13:55:25 EDT 2015

이 수는 트리를 재설정하지 않고 특정 소스 트리를 사용하여이 커널을 빌드 한 횟수라는 점에서 임의적입니다. 이는 사용자가 직접 빌드 할 때 유용 할 수 있습니다. SMP는 멀티 태스킹 (즉, 실시간 아님) 커널을 나타내며 PREEMPT는 스케줄러의 "선점 모델"과 관련된 다른 구성 옵션입니다. 그러나 여기에서 가장 큰 단서는 아마도 그것이 만들어진 시간 일 것입니다. 커널 자체의 수정 / 변경 타임 스탬프와 일치시키는 데 사용할 수 있습니다 (예 :로 변경 가능) touch. 예를 들어, stat해당 커널에서 다음과 같습니다.

  File: ‘3.19-goldilocksSpecial’
  Size: 6858880         Blocks: 13400      IO Block: 4096   regular file
Device: 801h/2049d      Inode: 3156605     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-02-15 15:32:29.000000000 -0500
Modify: 2015-03-03 13:55:21.000000000 -0500
Change: 2015-03-03 14:02:26.767045553 -0500
 Birth: -

어느 것이와 거의 일치합니다 Mon Mar 9 13:55:25 EDT 2015.

— 미역취 속의 일종
소스
2

다른 것과 동일

sudo apt-cache policy linux-generic

패키지 관리자를 통해 설치된 버전이며 

uname -r

버전을 비교

나를 위해 

linux-generic:
  Installed: 3.19.0.15.14
  Candidate: 3.19.0.15.14

과

3.19.0-15-generic

같은 버전을 나타내는

— Exussum
소스
1
다른 옵션으로 동일한 버전을 다시 컴파일하면 변경됩니까? 이 경우 왜 버전 문자열이 변경되는지 알 수 없습니다.
— terdon
같은 이름의 2가 설치 될지 확실하지 않습니다. 나는 그것을 시도하지 않았습니다. 다른 옵션으로 재 컴파일 할 때 충돌을 제거하기 위해 패키지 관리자에서 버전을 제거합니다.
— exussum
나는 같은 이름이 단순히로 덮어 쓰여질 것이라고 생각합니다 /boot. 내 요점은 uname일부 옵션을 변경하는 동안 다시 컴파일하면 출력이 변경되는 이유를 알 수 없다는 것 입니다. 이 경우, 나는 그것을 기대 apt-cache하고 uname -r로컬로 다시 컴파일 한 사실에도 불구하고, 동일한 정보를 반환합니다.
— terdon
@terdon 커널 구성에서 버전 문자열을 사용자 정의 할 수 있습니다. 배포판 소스를 사용하는 경우 좋습니다.
— goldilocks
@ goldilocks 그렇습니다. 나는 당신의 대답에서 그것을 보았습니다. 그러나 내가 그렇게하지 않을 정도로 어리 석고 몇 가지 옵션을 변경하여 배포판의 주식 커널을 다시 컴파일하면 버전 문자열이 동일합니다. 빌드 수에 대한 귀하의 제안은 도움이 될 수 있지만, 내가 아는 한 여기에서 제안 된 것은 아닙니다.
— terdon
0

나는 가장 일반적으로 진정한 대답은 "아니오, 당신은 할 수 없다"고 말할 것입니다. 특정 경우에 도움이 될 수있는 다양한 방법이 있으며 이러한 방법은 이미 제안되었지만 이러한 상황이 실제로 어떻게 이루어 졌는지를 놓치는 것 같습니다. 사실, 커스텀 커널을 사용한다면, 그 커널은 존재를 숨기거나 다른 커널 인 것처럼 보이는 것을 포함하여 무엇이든 할 수 있습니다.

실제로 사용자 정의 커널을 실행하고 있고 이것을 모른다면 걱정할 것입니다. 어떤 커널이 사용되고 있는지 아는 유일한 확실한 방법은 컴파일하고 설치할 커널을주의 깊게 추적하는 것입니다.

시스템이 어떤 커널을 실행하고 있는지 또는이 커널이 어느 소스에서 만들어 졌는지 또는 어디에서 왔는지 확실하지 않다면 알려진 좋은 이미지에서 OS를 다시 설치하고 향후 어떤 커널을 시도하고 부팅하는지 더 신중하게 고려해야합니다. 에서 또는 사용합니다.

— 원자력
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.