SSD Nodes Learn 🎉 VPS $5.50/월부터
가이드 Matt Connor작성자 Matt Connor · 업데이트됨 2026-08-13

Linux 커널 7.1 서버 주요 변경 사항 및 업데이트 확인법

2026년 6월 14일 릴리스된 Linux 커널 7.1의 서버 핵심 기능과 배포판 적용 시기를 정리합니다. 현재 실행 중인 커널 버전 확인 명령어와 uname -r 및 virt-what을 활용한 가상화 환경별 커널 업데이트 가능 여부를 상세히 안내합니다.

Linux 커널 7.1의 새로운 기능

Linux 커널 7.1은 7.0 출시 9주 후인 2026년 6월 14일에 릴리스되었습니다. VPS(가상 사설 서버) 사용자가 주목해야 할 변경 사항은 스토리지 및 파일 시스템, 네트워킹, 메모리 관리, 프로세스 및 컨테이너 제어라는 네 가지 영역에 집중되어 있습니다. 나머지 릴리스 내용은 대부분 헤드리스 서버에서는 로드되지 않는 데스크톱 및 그래픽 관련 작업입니다.

먼저 알아두어야 할 중요한 사실이 하나 더 있습니다. 현재 귀하의 서버에서 7.1 버전이 실행되고 있을 가능성은 거의 없으며, 앞으로도 상당 기간은 그렇지 않을 것입니다. kernel.org는 7.1을 장기 지원(longterm) 릴리스로 분류하지 않았습니다. 2026년 8월 11일 기준으로 장기 지원 라인은 6.18, 6.12, 6.6, 6.1, 5.15, 5.10이며, 모든 주류 서버 배포판은 이 중 하나를 기반으로 하거나 자체적으로 유지 관리하는 라인을 사용합니다. "커널의 새로운 기능"과 "서버에 적용된 새로운 기능" 사이에는 수년의 간극이 존재하므로, 이 가이드는 두 가지 측면을 모두 다룹니다.

현재 VPS에서 실행 중인 커널 확인하기

uname -r
uname -srm
systemd-detect-virt

uname -r는 현재 실행 중인 커널 릴리스를 출력합니다. Ubuntu 24.04에서는 6.8.0-79-generic와 같이 표시됩니다. 첫 번째 대시 앞부분은 업스트림 라인을 의미합니다. 그 뒤에 오는 모든 내용은 배포판 자체의 빌드 번호이며, 업스트림 버전과는 무관합니다. Canonical의 6.8.0-79에는 이후 커널에서 백포트된 수천 개의 수정 사항이 포함되어 있으므로, 2024년 3월 Linus가 6.8로 태그한 코드와는 다릅니다. 이것이 "내 커널이 오래되었다"는 말이 실제보다 큰 의미를 갖지 않는 이유입니다. 기능은 오래되었을지라도 보안 수정 사항은 대개 최신 상태이기 때문입니다.

systemd-detect-virt은 커널을 변경할 수 있는지 여부를 알려줍니다. 전체 가상 머신(full virtual machine)에서는 kvm를 출력하며, 이 경우 사용자가 직접 커널 이미지를 부팅하므로 업그레이드가 실제로 적용됩니다. 컨테이너 가상화 환경에서는 lxc 또는 openvz을 출력하며, 이때는 호스트 커널을 공유합니다. 컨테이너 플랜에서 uname -r는 제공자의 커널을 보여줍니다. 이 환경에서는 커널 패키지를 설치해도 부팅 가능한 항목이 변경되지 않으며, 제공자가 호스트를 더 최신 커널로 재부팅하기 전까지는 해당 릴리스의 어떤 기능도 사용할 수 없습니다. 커널 관련 작업을 계획하기 전에 이 확인 절차를 먼저 수행하십시오.

ChartDefault server kernel by platform, and upstream releases behind 7.1, checked 11 August 2026
The data behind this chart
[
  {
    "distro": "Ubuntu 26.04 LTS (7.0)",
    "releases_behind_7_1": 1,
    "notes": "GA kernel, shipped with the April 2026 release"
  },
  {
    "distro": "Ubuntu 24.04 LTS, HWE (6.17)",
    "releases_behind_7_1": 4,
    "notes": "6.17 came with 24.04.4; 7.0 is rolling out ahead of 24.04.5 on 27 August 2026"
  },
  {
    "distro": "Debian 13 trixie (6.12)",
    "releases_behind_7_1": 9,
    "notes": "upstream longterm line, kernel.org projected EOL December 2028"
  },
  {
    "distro": "RHEL 10 and its rebuilds (6.12)",
    "releases_behind_7_1": 9,
    "notes": "Red Hat backports fixes into its own frozen 6.12 stream"
  },
  {
    "distro": "Ubuntu 24.04 LTS, GA (6.8)",
    "releases_behind_7_1": 13,
    "notes": "the default unless you install the HWE stack"
  },
  {
    "distro": "Ubuntu 22.04 LTS, GA (5.15)",
    "releases_behind_7_1": 26,
    "notes": "upstream longterm line, kernel.org projected EOL December 2026"
  }
]

현재 6개의 플랫폼이 있으며, 그중 7.1로 부팅되는 플랫폼은 하나도 없습니다. 가장 최신 버전은 Ubuntu 26.04 LTS (7.0)로, 업스트림 릴리스보다 1단계 뒤처져 있습니다. 여전히 지원되는 가장 오래된 버전은 26단계 뒤처져 있습니다. Ubuntu 24.04의 기본 GA 커널은 13단계 뒤에 위치하며, Debian 13과 RHEL 10은 6.12 롱텀 라인에서 9단계 뒤에 위치합니다. 릴리스 횟수를 세는 것은 배포판이 백포트하는 모든 내용을 무시하기 때문에 대략적인 측정치에 불과하지만, 격차의 규모를 보여줍니다. 이 중 어떤 것을 운영할지 고민 중이라면, 서버 운영 시 LTS와 중간 릴리스 간의 절충안이 이 수치들 밑바닥에 깔린 핵심 결정 사항입니다.

7.1 버전의 스토리지 및 파일 시스템

7.1 버전은 블록 계층뿐만 아니라 파일 시스템 내부에서도 T10 PI(protection information)를 생성하고 검증할 수 있는 기능을 추가했으며, 유연한 T10 정렬 지원도 포함했습니다. T10 PI는 각 블록에 추가되는 바이트로, 체크섬과 해당 데이터가 속한 블록을 식별하는 태그를 포함합니다. 이를 통해 잘못된 방향으로 기록되거나 손상된 쓰기 작업이 정상 데이터로 반환되지 않고 즉시 탐지됩니다. VPS 사용자가 주의할 점은 하드웨어입니다. 무결성 메타데이터는 장치에서 노출되어야 하지만, 가상 디스크는 일반적으로 이를 노출하지 않습니다.

ls /sys/block/vda/integrity/

대부분의 VPS 디스크에서 해당 명령은 No such file or directory을 반환합니다. 블록 계층은 장치가 무결성 지원을 등록할 때만 integrity 디렉터리를 생성하기 때문입니다. 이 오류는 결함이 아니라 정상적인 응답입니다. 스토리지 기능을 자세히 살펴보기 전에 현재 디스크의 실제 상태를 확인하려면 VPS 디스크가 실제로 NVMe인지 확인하기를 먼저 수행해야 하며, VPS에서 NVMe와 SATA SSD의 차이를 통해 이 답변이 성능 수치에 어떤 영향을 주는지 이해할 수 있습니다.

Btrfs는 메모리 압박 상황에서의 copy-on-write 증폭 문제를 수정했으며, 추적 범위 내 첫 번째 익스텐트(extent)를 지우는 속도를 개선하여 병합 보고서 기준 샘플 워크로드에서 10%의 처리량 향상을 보였습니다. 또한 종료 작업이 더 이상 실험적 기능으로 분류되지 않습니다. XFS는 iomap을 통한 zero range 플러싱 및 조회 기능을 개선했으며, zoned 장치를 위한 기반 작업으로 실시간 그룹 지오메트리에 쓰기 포인터를 추가했습니다. 이번 릴리스에서 NTFS는 완전히 재작성되어 전체 쓰기 지원과 iomap 변환이 가능해졌으며, 이는 서버에서 Windows 머신의 디스크 이미지를 마운트할 때 중요합니다.

알아두어야 할 소규모 스토리지 변경 사항은 다음과 같습니다. 사용자 공간 블록 드라이버인 ublk에 zero-copy I/O가 추가되었고, io_uring은 SCSI 패스스루 명령을 지원합니다. SED-OPAL 자체 암호화 드라이브 지원에는 STACK_RESET 명령과 확장된 단일 사용자 모드가 추가되었습니다. 직접 접근 장치를 위한 새로운 fs-dax 문자 드라이버가 도입되었으며, VFS는 inode->i_ino을 unsigned long에서 u64로 확장하여 32비트 빌드에서의 inode 번호 제한을 제거했습니다. 네트워크 파일 시스템 측면에서는 커널 내 NFS 서버가 sign_fh 마운트 옵션을 통해 파일 핸들에 서명할 수 있게 되었고, CIFS 클라이언트는 O_TMPFILE 기능을 습득했습니다.

네트워킹: 큐 리싱(queue leasing)과 컨테이너에 미치는 영향

네트워킹 분야의 핵심 변경 사항은 하드웨어 큐 리싱입니다. 이제 가상 네트워크 장치(netdev)는 물리적 네트워크 장치의 실제 큐에 바인딩된 큐를 임대하여 프록시 역할을 수행할 수 있습니다. 이 기능의 목적은 컨테이너 지원에 있습니다. 지금까지 AF_XDP(네트워크 스택을 거치지 않고 원시 패킷을 사용자 공간으로 직접 전달하는 소켓 유형)를 사용하려는 컨테이너는 장치 전체에 가까운 권한을 할당받아야 했습니다. 큐 리싱을 사용하면 컨테이너는 하나의 하드웨어 큐만 할당받아 AF_XDP와 메모리 공급자를 네이티브 속도로 실행할 수 있으며, 호스트는 나머지 NIC 자원을 그대로 유지할 수 있습니다. 이 기능은 io_uring의 제로 카피 경로에 있는 AF_XDP 지원과 함께 도입되었습니다.

일반적인 측면에서, sockfs의 소켓은 이제 user.* 확장 속성(extended attributes)을 지원합니다. 경로 기반의 AF_UNIX 소켓은 이미 하위 파일 시스템으로부터 xattr 지원을 상속받았으나, sockfs에만 존재하는 소켓은 이러한 기능이 없었습니다. 이제 프로세스는 소켓에 라벨을 지정할 수 있으며, eBPF 프로그램은 해당 라벨을 기반으로 필터링을 수행할 수 있습니다.

두 가지 기능이 제거되었습니다. UDP-Lite는 사용자가 없어 삭제되었습니다. IPv6는 더 이상 로드 가능한 모듈로 빌드할 수 없으며, IPv6가 필요한 경우 커널에 내장(compiled in)해야 합니다. 두 번째 변경 사항은 일반적인 서버 배포판 커널에서는 이미 IPv6를 내장하여 빌드하고 있으므로 사용자에게는 영향을 주지 않습니다.

메모리 관리: 스왑 테이블 작업 완료

스왑 재설계 작업이 3단계에 도달했으며, 이번 단계에서는 정적 스왑 맵(static swap map)을 제거합니다. 이제 스왑 카운트가 스왑 테이블에 직접 저장됩니다. 보고된 절감 효과는 정적 스왑 메타데이터의 약 30% 수준이며, 이는 스왑 사용 여부와 관계없이 스왑 장치 크기에 비례하여 커널이 점유하던 메모리입니다. 절대적인 수치로 보면 작은 스왑 파일에서는 미미하지만, 설정한 스왑 크기가 커질수록 절감되는 메모리 양도 늘어납니다.

MGLRU(multi-generational least recently used, 최신 페이지 회수 알고리즘)는 이제 페이지의 young 플래그를 한 번에 하나씩 확인하는 대신 일괄적으로 처리할 수 있습니다. 이번 변경 사항과 함께 공개된 수치에 따르면 Arm64 32코어 서버에서 60% 이상의 성능 향상이 확인되었습니다. 일괄 처리는 페이지당 비용이 가장 높은 환경에서 효과가 극대화되므로, 해당 수치는 대규모 Arm 장비에서 측정되었습니다. 만약 x86이 아닌 Arm VPS를 운영 중이라면, 2~4코어 환경에서는 그 정도의 수치는 아니더라도 7.1 버전에서 가장 체감될 만한 변경 사항입니다.

그 외에도 소멸하는 메모리 cgroup에서의 전송 기능이 제거되었고, khugepaged의 CPU 스캔 부하가 줄었으며, maple tree의 대형 노드 처리 방식이 대대적으로 리팩터링되었습니다. 이러한 항목들은 사용자가 직접 설정하는 것이 아닙니다. 시스템 타임(system time)이 미세하게 줄어드는 것으로 그 효과를 체감할 수 있습니다.

스케줄러: sched_ext 하위 스케줄러 및 FRED 기본 활성화

BPF 프로그램으로 CPU 스케줄러를 작성하고 런타임에 로드할 수 있게 해주는 확장 가능한 스케줄러 클래스인 sched_ext가 6.12 버전에 도입되었습니다. 7.1 버전에는 하위 스케줄러를 위한 핵심 구조가 추가되어, 향후 제어 그룹(control group)이 자체 스케줄러 하에서 동작할 수 있게 되었습니다. 이 문장을 주의 깊게 읽으십시오. 7.1 버전에서 구현이 완료된 것은 아니며, 특히 enqueue 경로가 누락되어 있으므로 이는 오늘 당장 활성화할 수 있는 기능이라기보다 향후 릴리스를 위한 기반 작업입니다.

Intel FRED(flexible return and event delivery)가 이제 이를 지원하는 하드웨어에서 기본적으로 활성화됩니다. FRED는 기존의 x86 이벤트 전달 경로를 더 깔끔한 방식으로 대체하며, 6.9 버전부터 fred=on 부팅 인자를 통해 커널에 포함되어 있었습니다. 이를 기본값으로 설정한 것은 출시된 하드웨어에 대한 테스트가 충분히 이루어졌음을 의미합니다. 지금까지 발표된 I/O 집약적 워크로드에서의 4%에서 7% 성능 향상 수치는 Phoronix의 클라이언트 실리콘 테스트 결과이므로, 서버 환경에서는 직접 워크로드를 측정하기 전까지는 이 수치를 예산에 반영하지 마십시오.

프록시 실행(Proxy execution)에는 원격 락 소유자를 가속하기 위한 도너 마이그레이션(donor migration)이 추가되었고, EEVDF는 음수 지연(negative lag) 관련 수정 사항이 적용되었으며, 고해상도 타이머 코어는 대대적으로 재작성되었습니다. 이러한 변경 사항은 지연 시간 품질 개선을 위한 것으로, 설정 파일에서 직접 제어할 수 있는 항목은 없습니다.

clone3()의 새로운 프로세스 및 컨테이너 제어

clone3()에 세 가지 플래그가 추가되었으며, 각 플래그는 관리자가 수년간 수동으로 해결해 온 공백을 메워줍니다. CLONE_AUTOREAP는 자식 프로세스가 종료될 때 스스로를 정리(reap)하게 하여, wait()를 호출하지 않을 수도 있는 부모를 기다리는 좀비 프로세스가 생성되지 않도록 합니다. CLONE_NNP은 생성 시점에 자식 프로세스에 no_new_privs를 설정하며, 이는 clone 호출과 자식 프로세스가 직접 플래그를 설정하기 사이의 시간적 공백을 제거합니다. CLONE_PIDFD_AUTOKILL은 자식 프로세스의 수명을 부모에게 반환된 pidfd에 연결합니다. pidfd를 닫으면 자식 프로세스가 즉시 종료되므로, 관리 프로세스가 비정상 종료되더라도 고아 프로세스가 남지 않게 됩니다.

마운트 네임스페이스도 동일한 개선이 이루어졌습니다. clone3()를 위한 CLONE_EMPTY_MNTNS과 unshare()을 위한 UNSHARE_EMPTY_MNTNS은 기존처럼 부모의 마운트 정보를 모두 복사한 뒤 런타임이 일일이 언마운트할 필요 없이, 아무것도 없는 빈 마운트 네임스페이스를 생성합니다. FSMOUNT_NAMESPACE를 사용하면 fsmount()이 파일 시스템을 새로운 네임스페이스에 즉시 배치할 수 있습니다. 컨테이너 런타임은 지난 10년간 이를 수동으로 구성해 왔으므로, 단일 호출로 처리함으로써 런타임이 호스트의 마운트 정보로 가득 찬 네임스페이스에서 시작하지 않아도 됩니다.

가상화 측면에서는 guest_memfd가 이제 userfaultfd를 지원하여 하이퍼바이저가 사용자 공간에서 게스트 페이지 폴트를 처리할 수 있게 되었습니다. Arm 기반의 Protected KVM은 익명 메모리 지원을 추가했으나, 병합 내용 자체에서는 아직 프로덕션 환경에서 사용할 준비가 되지 않았다고 설명합니다.

커널 7.1은 언제 서버에 적용되는가

Fedora는 이미 이를 지원합니다. Fedora 44 업데이트 저장소는 2026년 7월과 8월 사이에 7.1 시리즈로 전환되었습니다. Fedora는 릴리스 주기 내에서 커널을 새로운 안정화 버전으로 재기반(rebase)하기 때문입니다. Arch와 openSUSE Tumbleweed도 같은 이유로 이를 포함하고 있습니다. 이러한 배포판은 테스트용이며, 서비스를 운영하는 용도로는 적합하지 않습니다.

그 외의 모든 배포판은 대기하며, 이 대기는 의도된 설계입니다. Debian 13은 6.12 버전으로 출시되었으며, 릴리스 수명 동안 6.12 버전을 유지하면서 수정 사항만 백포트(backport)합니다. RHEL 10 역시 6.12.0 버전으로 출시되어 동일한 방식을 따릅니다. Ubuntu 26.04 LTS는 2026년 4월에 7.0 버전으로 출시되었습니다. Ubuntu 24.04 LTS는 HWE(Hardware Enablement) 스택을 통해 이후 Ubuntu 릴리스의 최신 커널을 가져오는데, 24.04.4 포인트 릴리스 기준으로 6.17 버전을 사용하며 2026년 8월 27일 24.04.5 릴리스와 함께 7.0으로 전환될 예정입니다.

사람들이 흔히 오해하는 부분이 있습니다. HWE 스택은 최신 중간 릴리스가 포함하는 커널 버전으로 바로 건너뛰기 때문에, 업스트림 커널 라인을 완전히 건너뛸 수도 있습니다. 7.0은 Ubuntu LTS에 포함되어 있습니다. 7.1은 LTS의 기본 커널이 되지 않을 수도 있는데, 그 이후의 중간 릴리스가 더 최신 커널 라인을 포함하기 때문입니다. LTS에 적용되는 7.1 관련 변경 사항은 현재 사용 중인 커널 라인으로 백포트된 수정 사항뿐입니다. 새로운 기능은 대부분 포함되지 않습니다.

안정적인 서버에서 더 최신 커널을 사용하고자 한다면, 지원되는 경로는 제한적입니다.

# Ubuntu 24.04 LTS: install the hardware enablement stack
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

# Debian 13, with trixie-backports enabled in your apt sources
apt-cache policy linux-image-amd64
sudo apt install -t trixie-backports linux-image-amd64
sudo reboot

재부팅 후 실제로 어떤 커널로 부팅되었는지 확인하십시오:

uname -r
dpkg -l 'linux-image-*' | grep ^ii
ls /var/run/reboot-required

uname -r 명령을 실행하면 새로운 커널 라인이 표시되어야 하며, dpkg -l 명령은 현재 설치된 모든 커널 이미지를 보여줍니다. 만약 uname -r 명령에 이전 버전이 표시되고 dpkg -l 목록에 새 버전이 있다면, 패키지는 설치되었으나 부트로더의 기본값이 변경되지 않은 것입니다. 이 경우 GRUB 메뉴 항목을 확인하십시오. /var/run/reboot-required 파일이 존재한다면 패키지가 커널을 업그레이드했으나 재부팅이 이루어지지 않았음을 의미합니다. 이는 패치가 적용된 서버가 여전히 취약한 코드를 실행하고 있는 가장 흔한 원인입니다.

운영 환경의 VPS에서 7.1 버전을 쫓아야 하는가

아니오. 단순히 신중을 기하기 위해서가 아닙니다. 배포판 커널은 기술 지원 계약과 같습니다. Canonical, Red Hat, SUSE, Debian은 각자 고정된 커널 버전에 보안 패치를 백포트(backport)하고, 함께 제공되는 사용자 공간(userspace)과의 호환성을 테스트합니다. 제3자 아카이브에서 가져오거나 직접 빌드한 메인라인 커널은 새로운 기능을 제공하지만, 이러한 검증 과정을 제거합니다. 아무도 당신의 빌드에 보안 패치를 백포트해주지 않기 때문입니다. 결과적으로 당신이 직접 커널의 유지보수 담당자가 되어야 합니다.

예외적인 경우가 존재하지만 매우 제한적입니다. 이전 커널에서 구동되지 않는 하드웨어를 사용하거나, 자신의 워크로드에서 성능 향상을 직접 측정하여 그에 따른 책임을 감수할 만큼 절실한 경우입니다. VPS 환경에서는 하드웨어가 가상화되어 있으므로 첫 번째 경우는 거의 발생하지 않습니다. 그 외의 모든 상황에서는 배포판 커널을 최신으로 유지하고, 업데이트가 요구할 때 재부팅하십시오. 만약 배포판 업그레이드가 이미 계획에 있다면, Ubuntu 24.04에서 26.04로 이동하는 과정에서 커널이 6.8에서 7.0으로 한 번에 올라갑니다. 이는 단일 커널 패키지 업데이트보다 훨씬 큰 폭의 변화입니다.

FAQ

VPS에서 실행 중인 Linux 커널 버전을 확인하려면 어떻게 해야 합니까?

uname -r을 실행하십시오. 그러면 6.8.0-79-generic과 같은 결과가 출력됩니다. 첫 번째 대시 앞의 숫자는 배포판이 기반으로 하는 업스트림 라인이며, 그 뒤의 모든 숫자는 배포판 자체 빌드 번호로 백포트된 수정 사항을 포함합니다. 그 다음 systemd-detect-virt를 실행하십시오. 만약 lxc 또는 openvz가 출력된다면 컨테이너 가상화 환경을 사용 중인 것이며, 호스트의 커널을 공유하므로 커널을 직접 변경할 수 없습니다. kvm가 출력된다면 자체 커널 이미지를 부팅하는 것이므로 직접 업그레이드를 수행할 수 있습니다.

Linux 7.1은 장기 지원(LTS) 커널입니까?

아닙니다. 2026년 8월 11일 기준으로 kernel.org에 나열된 장기 지원 라인은 6.18, 6.12, 6.6, 6.1, 5.15, 5.10이며, 7.1은 포함되지 않습니다. 이는 일반적인 안정화 릴리스이며, 다음 메인라인 릴리스가 나오면 곧 안정화 지원이 종료됩니다. 수년간의 수정 사항이 반영되어 있고 앞으로도 지원이 보장되는 커널을 원한다면, 이미 배포판에서 제공하는 커널이 그 역할을 하고 있습니다.

Ubuntu나 Debian은 언제 커널 7.1을 배포합니까?

기본값으로는 아마 배포하지 않을 것입니다. Debian 13은 릴리스 수명 동안 6.12 버전을 유지하며, RHEL 10은 6.12.0 버전을 유지합니다. Ubuntu 26.04 LTS는 7.0 버전을 탑재했으며, Ubuntu 하드웨어 활성화(HWE) 스택은 최신 중간 릴리스의 커널로 이동하므로 특정 업스트림 라인을 완전히 건너뛸 수 있습니다. Ubuntu 24.04 LTS는 2026년 8월 27일 예정된 24.04.5 포인트 릴리스에서 HWE 커널을 7.0으로 이동할 예정입니다. 7.1의 수정 사항은 이전 커널 라인으로 백포트되어 제공되겠지만, 새로운 기능은 보통 포함되지 않습니다.

Linux 7.1에서 VPS에 실제로 중요한 변경 사항은 무엇입니까?

네 가지 항목이 있습니다. 하드웨어 큐 리싱(Hardware queue leasing)을 통해 컨테이너가 AF_XDP를 위해 실제 NIC 큐를 네이티브 속도로 사용할 수 있습니다. 스왑 재작업의 3단계에서는 정적 스왑 맵을 제거하여 커널이 스왑 장치를 위해 유지하는 메타데이터를 약 30% 절감합니다. MGLRU는 페이지의 young 플래그를 일괄적으로 확인할 수 있으며, 다중 코어 Arm 서버에서 가장 큰 성능 향상을 보입니다. 또한 clone3()에 CLONE_AUTOREAP, CLONE_NNP, CLONE_PIDFD_AUTOKILL가 추가되어 자식 프로세스 관리가 더 안전해졌습니다. 파일 시스템 수준의 T10 보호 정보도 추가되었으나, 가상 디스크가 필요한 무결성 메타데이터를 노출하는 경우는 드뭅니다.

커널을 업그레이드하면 VPS가 손상됩니까?

일반적인 오류는 부팅 시 발생합니다. 디스크 공간이 가득 찬 상태에서 /boot을 실행하면 설치 중 No space left on device 오류와 함께 update-initramfs이 실패하여 패키지가 절반만 구성된 상태로 남을 수 있습니다. sudo apt autoremove --purge으로 이전 커널을 정리한 후 다시 설치하십시오. 이전 커널을 기준으로 빌드된 외부 모듈은 로드되지 않으므로 DKMS로 관리되는 모든 항목은 다시 빌드해야 하며, 빌드 실패 시 런타임에 모듈이 누락될 때까지 오류를 알 수 없습니다. 재부팅 후 dpkg -l에는 새 이미지가 나열되는데 uname -r가 여전히 이전 버전을 보고한다면 설치 과정에서 문제가 생긴 것이 아니라 부팅 로더의 기본 설정이 변경되지 않은 것입니다.

#linux#kernel#lts#servers#upgrades