SSD Nodes Learn Hosting plans →
가이드 Matt Connor작성자 Matt Connor · 업데이트됨 2026-08-27

VPS 부팅 커널 고정 방법 및 GRUB 설정 가이드

Ubuntu 클라우드 이미지에서 GRUB_DEFAULT 설정이 작동하지 않는 이유를 설명합니다. 서버의 실제 메뉴 항목을 확인하고, SSH 접속이 끊기지 않도록 안전하게 다음 부팅 커널을 고정하는 정확한 절차를 안내합니다. 복구 콘솔 없이 커널 버전을 제어하는 방법을 확인하십시오.

VPS가 부팅할 커널을 결정하는 요소

VPS가 다음에 부팅할 커널은 생성된 파일인 /boot/grub/grub.cfg에 의해 결정됩니다. 이 파일은 직접 수정하지 않습니다. 입력값을 수정하고 파일을 다시 생성해야 합니다. Ubuntu 클라우드 이미지의 경우 입력값 중 하나가 이미지 공급업체로부터 제공되며, 이로 인해 메뉴 선택이 무의미해질 수 있습니다. 이것이 바로 임대 서버에서는 GRUB_DEFAULT=1 후 update-grub을 수행해도 아무런 변화가 없지만, 노트북 설치 환경에서는 동일한 두 단계가 정상적으로 작동하는 이유입니다.

다음 순서대로 작업하십시오. 커널을 직접 선택할 수 있는지 먼저 확인하십시오. 공급업체가 추가한 파일을 포함하여 모든 입력 파일을 읽으십시오. 생성된 출력 파일을 읽고 실제 항목 수를 확인하십시오. 그 후에야 고정(pinning) 방법을 선택하십시오. SSH로만 접근 가능한 장비에서 이 과정을 잘못 수행하면 복구 콘솔을 사용해야 하는 상황이 발생하므로, 이 페이지의 마지막에 있는 가장 안전한 방법을 선택하는 것이 좋습니다.

커널을 고정할 수 있는지 먼저 확인하십시오

uname -r
systemd-detect-virt
ls -1 /boot/vmlinuz-*

systemd-detect-virt 명령을 실행했을 때 kvm, qemu 또는 xen가 출력된다면 사용자가 직접 커널을 운영하는 것이며 아래의 모든 내용이 적용됩니다. lxc 또는 openvz가 출력된다면 서버가 호스트의 커널을 공유하는 상태이므로 사용자가 제어할 수 있는 부트로더가 없으며 고정할 대상도 없습니다. 이 경우 uname -r는 /boot/vmlinuz-*에는 전혀 나타나지 않는 버전을 보고하는데, 이는 실행 중인 커널이 호스트의 것이며 디스크의 어떤 설정으로도 이를 변경할 수 없기 때문입니다.

ls -1 /boot/vmlinuz-*은 선택 가능한 실제 커널 목록입니다. 이 목록에 한 줄만 있다면 이전 커널은 이미 삭제된 상태이며, 어떤 부트로더 설정으로도 복구할 수 없습니다. 이는 보통 autoremove 과정에서 발생하며, 중요한 서버에서 Ubuntu의 오래된 커널 정리를 수행하기 전에 반드시 이해해야 할 부분입니다.

편집하는 파일과 GRUB이 읽는 파일은 서로 다릅니다

/etc/default/grub에는 일반적인 셸 변수 할당문이 포함되어 있습니다. 이는 입력 파일입니다. /boot/grub/grub.cfg는 출력 파일이며, # DO NOT EDIT THIS FILE과 그 이유가 파일 상단에 명시되어 있습니다. 커널 패키지가 설치되거나 제거될 때마다 패키지 스크립트가 이 파일을 재생성하므로, 출력 파일에 직접 작성한 내용은 모두 사라집니다.

cat /usr/sbin/update-grub

update-grub은 래퍼(wrapper)입니다. 이 명령은 grub-mkconfig -o /boot/grub/grub.cfg를 실행하며, grub-mkconfig -o /boot/grub/grub.cfg는 변수를 읽고 /etc/grub.d/에 있는 모든 스크립트를 실행한 뒤 결과를 기록합니다. 두 명령은 한 방향으로 작동합니다. 입력값이 들어가면 grub.cfg가 생성됩니다.

설정을 덮어쓰는 요소: /etc/default/grub.d

grep -rn '^[^#]' /etc/default/grub /etc/default/grub.d/

두 번째 경로는 사용자가 자주 놓치는 부분입니다. grub-mkconfig는 먼저 /etc/default/grub을 불러온 뒤, /etc/default/grub.d/에 있는 모든 *.cfg 파일을 glob 순서대로 읽어 들입니다. 이를 수행하는 코드는 다음과 같습니다.

grep -n 'default/grub' /usr/sbin/grub-mkconfig

소스 불러오기(sourcing)는 일반적인 셸 방식으로 동작하므로, 마지막에 할당된 값이 최종적으로 적용됩니다. Ubuntu 클라우드 이미지는 해당 디렉터리에 파일을 포함하여 배포하며, 사용자의 파일이 읽힌 이후에 타임아웃이나 커널 명령줄과 같은 설정을 덮어씁니다. 사용자가 /etc/default/grub에 작성한 GRUB_TIMEOUT=10는 잠시 후 0으로 설정하는 벤더 파일에 의해 덮어쓰여집니다. 위에서 실행한 grep 명령은 현재 이미지에 적용된 정확한 할당 값을 출력하므로, 이 문장을 무조건 신뢰하기보다 해당 출력 결과를 직접 확인하십시오.

따라서 실무적인 규칙은 다음과 같습니다. /etc/default/grub를 직접 수정하는 대신, /etc/default/grub.d/99-local.cfg과 같이 정렬 순서상 마지막에 위치하는 파일에 설정을 작성하십시오. 이렇게 하면 이미지와 함께 배포된 어떤 파일도 사용자의 설정 이후에 실행될 수 없습니다.

GRUB_FORCE_PARTUUID가 메뉴 선택을 무의미하게 만드는 이유

grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/
grep -n GRUB_FORCE_PARTUUID /etc/grub.d/10_linux
sudo grep -n 'root=PARTUUID' /boot/grub/grub.cfg

GRUB_FORCE_PARTUUID은 생성기가 부팅 중에 파일시스템 UUID를 검색하는 대신, 커널 명령줄에 root=PARTUUID=...와 같이 파티션 UUID를 직접 기록하여 루트 파일시스템을 찾도록 지시합니다. 이미지 공급업체가 이 설정을 사용하는 이유는 제작되지 않은 하드웨어에서도 단일 디스크 이미지가 안정적으로 부팅되도록 하기 위함입니다. 두 번째 grep 명령은 /etc/grub.d/10_linux 내에서 해당 변수를 처리하는 코드를 보여줍니다. 이 스크립트는 사용자의 디스크에 존재하며, 해당 이미지가 어떻게 동작하는지를 결정하는 권한을 가집니다.

여기서 중요한 결과는 다음과 같습니다. 해당 경로에서 생성기는 설치된 전체 커널 목록 대신 직접적인 부팅 항목을 작성합니다. 최종적으로 남은 항목의 개수를 확인하십시오.

sudo grep -cE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg
sudo grep -nE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg

항목 개수가 1개라면 선택할 두 번째 항목이 없으므로, GRUB_DEFAULT=1은 존재하지 않는 항목을 가리키게 됩니다. GRUB은 이를 해석할 수 없으므로 첫 번째 항목으로 부팅하며, 이는 사용자가 피하려고 했던 새로운 커널입니다. grub-set-default 또한 도움이 되지 않습니다. 기본값 설정이 문제가 아니라 메뉴 자체가 생성되지 않았기 때문입니다.

전체 메뉴를 복구하려면 공급업체 파일을 다른 곳으로 옮기고, 변경 사항을 적용하기 전에 결과를 미리 확인하십시오. -o 없이 grub-mkconfig을 실행하면 표준 출력으로 결과가 표시되며 디스크에는 아무런 영향도 주지 않습니다.

sudo grub-mkconfig 2>/dev/null | grep -cE '^\s*(menuentry|submenu) '
sudo mkdir -p /root/grub-backup
sudo mv /etc/default/grub.d/<the file your grep named> /root/grub-backup/
sudo grub-mkconfig 2>/dev/null | grep -cE '^\s*(menuentry|submenu) '

항목 개수가 1개에서 여러 개로 늘어났다면 강제 설정이 제거된 후 항목이 나타난 것입니다. 아직 아무것도 기록되지 않았습니다. 두 번째 개수가 올바르지 않다면 파일을 원래대로 되돌리십시오. 강제된 PARTUUID는 공급업체의 이미지가 루트 파일시스템을 찾는 방식이며, 이를 제거하면 시스템은 검색 경로를 사용하는 방식으로 전환되기 때문입니다. update-grub을 실제로 실행하기 전에 스냅샷을 생성하십시오.

단지 잘못된 커널로부터 시스템을 복구하는 것이 목적이라면 여기서 멈추고 아래에 설명된 더 안전한 옵션을 사용하십시오. 단일 업그레이드를 피하기 위해 원격 서버에서 부팅 메뉴를 재구성하는 것은 문제보다 더 큰 위험을 초래할 수 있습니다.

항목 번호를 고정하는 것이 잘못된 이유

GRUB_DEFAULT은(는) 숫자, 제목 또는 식별자를 인자로 받습니다. 숫자는 최상위 항목을 0부터 순서대로 셉니다. 중첩된 항목은 >를 구분자로 사용하므로, GRUB_DEFAULT="1>2"은(는) 1번 인덱스에 위치한 하위 메뉴 내의 2번 인덱스 항목을 의미합니다.

인덱스는 변합니다. 10_linux는(은) 최신 커널부터 순서대로 나열하므로, 커널을 설치하면 모든 이전 항목이 한 칸씩 아래로 밀리고, 커널을 제거하면 한 칸씩 위로 당겨집니다. 사용자가 신중하게 설정한 1>2도 그 이후에는 다른 대상을 가리키게 됩니다. 이제는 다른 커널을 지칭하게 되는 것입니다. 오류도 발생하지 않고 경고도 없으며, 재부팅을 하고 나서야 이 사실을 알게 됩니다.

식별자는 이동하지 않습니다. 각 식별자에는 커널 버전이 포함되어 있기 때문입니다. 다음 명령으로 식별자를 확인하십시오.

sudo awk -F"'" '/menuentry_id_option/ {print $2, "==>", $4}' /boot/grub/grub.cfg

출력의 앞부분 몇 줄은 헤더에서 정의되는 변수이므로 무시하십시오. 그 이후부터는 왼쪽이 사용자가 보는 제목이고, 오른쪽이 도구에 전달할 식별자입니다. 하위 메뉴 내부의 항목을 지정하려면, 숫자 형식과 동일하게 하위 메뉴 식별자와 항목 식별자를 >으로 연결하십시오.

grub-reboot를 사용하여 이전 커널로 1회 부팅하기

원격 서버에서는 설정이 자동으로 복구되는 1회성 선택 방식을 사용하는 것이 안전합니다. grub-reboot은 next_entry을 /boot/grub/grubenv에 기록합니다. GRUB은 부팅 과정에서 해당 변수를 읽고 삭제한 뒤, 부팅을 시작하기 전에 변경된 값을 저장합니다. 따라서 커널 패닉이 발생해도 다음 부팅 시 다시 시도하지 않습니다. 한 번의 시도 후에는 시스템이 자동으로 기본 설정으로 돌아옵니다.

먼저 생성된 설정 파일이 해당 변수를 읽어오는지 확인하십시오.

sudo grep -n -B2 -A5 'next_entry' /boot/grub/grub.cfg

load_env 라인과 next_entry로부터 default을 설정하는 블록이 있어야 합니다. grep 결과가 출력되지 않는다면 부팅 시 이미지가 grubenv을 읽지 않는 것이며, 이 경우 셸에서 grub-reboot를 입력해도 부트 로더가 이를 무시합니다. 이는 이전 섹션에서 다룬 강제 직접 부팅 경로가 다른 곳에서도 나타나는 것과 같습니다.

sudo grub-reboot '<the identifier you copied>'
sudo grub-editenv list

이제 grub-editenv list를 실행하면 전달한 값이 포함된 next_entry= 라인이 출력되어야 합니다. 브라우저 탭에서 제공업체의 콘솔을 열고 재부팅하여 결과를 확인하십시오.

sudo reboot
uname -r

uname -r이 이전 버전을 출력한다면 고정(pin) 작업이 성공한 것입니다. 새 버전을 출력한다면 식별자가 해석되지 않았거나 grubenv을 읽지 못하는 상황입니다. 어느 경우든 시스템은 정상적으로 부팅되므로, 1회성 방식을 사용하는 목적은 달성한 셈입니다.

GRUB_DEFAULT=saved를 사용하여 설정 고정하기

GRUB_DEFAULT=saved를 사용하면 기본값이 grubenv 내의 saved_entry에서 결정되며, 이 값은 grub-set-default 명령으로 설정합니다. 이 설정은 커널 설치 후에도 유지되는데, 이는 update-grub이 grub.cfg를 다시 작성할 때 grubenv는 건드리지 않기 때문입니다.

echo 'GRUB_DEFAULT=saved' | sudo tee /etc/default/grub.d/99-local.cfg
sudo update-grub
sudo grub-set-default '<the identifier you copied>'
sudo grub-editenv list
sudo grep -n 'set default' /boot/grub/grub.cfg

마지막 명령은 반드시 set default="${saved_entry}"을 출력해야 합니다. 만약 set default="0"이 출력된다면, 설정 파일 이후에 로드된 다른 파일이 GRUB_DEFAULT을 리터럴 값으로 되돌린 것입니다. 따라서 /etc/default/grub.d/를 다시 나열하여 99-local.cfg이 실제로 마지막에 정렬되는지 확인하십시오.

GRUB_SAVEDEFAULT=true은 이 설정과 혼동하기 쉬운 별개의 설정입니다. 이 옵션은 방금 부팅한 항목을 새로운 기본값으로 저장하므로, 가장 마지막에 성공적으로 부팅한 항목이 기본값이 됩니다. 서버 환경에서 이 옵션을 사용하면 무인 재부팅 시 의도치 않게 고정된 커널 버전이 변경될 수 있습니다. 원하는 동작이 아니라면 이 옵션을 끄십시오.

식별자를 통한 고정 방식도 한 가지 문제가 있습니다. 지정된 커널을 삭제하면 식별자를 해석할 수 없게 되어, 부팅 시 첫 번째 항목으로 되돌아갑니다. 따라서 해당 패키지를 고정(hold)하거나, 해당 커널이 자동 삭제(autoremove) 대상에 포함되지 않도록 관리하십시오.

제공자 콘솔에 메뉴 표시하기

대화형으로 선택하려면 화면에 메뉴가 나타나야 하지만, 클라우드 이미지는 이를 숨깁니다. 가장 마지막에 정렬되는 파일에 다음 내용을 추가한 뒤 sudo update-grub를 실행하십시오.

GRUB_TIMEOUT=10
GRUB_TIMEOUT_STYLE=menu
GRUB_RECORDFAIL_TIMEOUT=10

GRUB_TIMEOUT_STYLE=hidden와 GRUB_TIMEOUT=0를 함께 사용하면 아무것도 표시되지 않으므로, 콘솔을 지켜보는 사람은 커널 메시지가 즉시 시작되는 것을 보고 부트로더가 건너뛰어졌다고 결론 내립니다. GRUB_RECORDFAIL_TIMEOUT는 부팅이 완료되지 않았을 때 사용하는 별도의 타임아웃이며, 클라우드 이미지는 이 값도 0으로 설정합니다. 이것이 부팅에 실패한 서버가 멈추지 않고 대기하지 않는 이유입니다.

제공자가 그래픽 콘솔 대신 시리얼 콘솔을 제공하는데도 아무것도 보이지 않는다면, GRUB이 볼 수 없는 터미널로 내용을 출력하고 있는 것입니다. 첫 번째 줄은 출력을 선택하고 두 번째 줄은 포트를 구성하므로 두 줄을 모두 추가하십시오.

GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"

이제부터 모든 부팅 시 10초의 대기 시간이 추가됩니다. 작업이 완료되면 타임아웃을 다시 0으로 설정하십시오.

부트로더를 직접 수정하는 것보다 안전한 방법

SSH로만 접근 가능한 서버에서 부트로더 설정을 변경하는 것은 이 문서에서 가장 위험한 작업입니다. 더 저렴하고 안전한 대안이 존재하며, 보통 이러한 방법으로 근본적인 문제를 해결할 수 있습니다.

커널 패키지를 고정(hold)하십시오. "새로운 커널을 설치하지 마라"는 것이 목표라면, 부트로더가 아닌 패키지 관리자에게 이를 지시해야 합니다.

apt list --installed 2>/dev/null | grep -E '^linux-(image|headers|generic|virtual|kvm|aws|azure|gcp|oracle)'
sudo apt-mark hold linux-image-virtual linux-headers-virtual
apt-mark showhold

첫 번째 명령어가 출력한 이름을 그대로 사용하십시오. 클라우드 이미지는 보통 generic 대신 virtual 또는 kvm 버전을 설치하기 때문입니다. 이미지 갱신 시점에 새로운 커널이 나타나서 릴리스 자체가 변경되었다고 의심할 수 있으나, 실제로는 그렇지 않습니다. 포인트 릴리스는 이미 배포된 업데이트를 새로운 설치 미디어에 통합한 것이므로, 이미 패치가 적용된 서버에는 몇 주 전부터 제공되었던 것 외에 새로운 내용을 전달하지 않습니다. 고정된 패키지는 apt upgrade에서 건너뛰며, 이때 The following packages have been kept back: 메시지가 출력됩니다. 또한 Ubuntu의 자동 업데이트(unattended upgrades)에서도 해당 패키지는 제외됩니다. 이 방법에는 대가가 따릅니다. 고정된 커널은 보안 패치를 받지 못하므로, 이를 기한이 정해진 일시적인 중단으로 간주하고 sudo apt-mark unhold 명령어로 다시 해제해야 합니다. 커널 자체의 결함이 아니라 재부팅으로 인한 서비스 중단이 우려되어 업데이트를 피하는 것이라면, VPS에서의 라이브 커널 패치가 더 나은 해결책입니다.

업그레이드 전 스냅샷을 생성하십시오. 스냅샷을 사용하면 콘솔에서 명령어를 입력할 필요 없이 몇 분 만에 복구할 수 있으며, 부트로더 변경이 불완전하게 적용될 위험도 없습니다. 스냅샷 생성, 업그레이드, 재부팅, 검증 순으로 진행하십시오. 새 커널에 문제가 발생하면 즉시 롤백하여 부팅 경로를 이전 상태로 정확히 되돌릴 수 있습니다.

이미 부팅이 불가능한 서버는 콘솔이나 복구 이미지를 사용하십시오. 서버가 부팅되지 않는 상태에서는 부트로더 설정을 수정하는 것이 해결책이 될 수 없으며, 복구 과정은 별도의 절차를 따라야 합니다. 커널 업데이트 후 VPS가 부팅되지 않을 때의 대처 방법을 참조하십시오.

발생하는 문제와 표시되는 메시지

/boot/grub/grub.cfg에 적용한 수정 사항이 사라졌습니다. 커널 패키지가 설치되거나 제거될 때 관리자 스크립트가 update-grub을 실행하여 입력 파일로부터 해당 파일을 재생성했기 때문입니다. # DO NOT EDIT THIS FILE 헤더에 두 입력 파일의 위치가 명시되어 있으니 해당 파일들을 수정하십시오.

grub-editenv: error: environment block too small. /boot/grub/grubenv 파일이 없거나 내용이 잘렸습니다. sudo grub-editenv /boot/grub/grubenv create 명령으로 파일을 다시 생성한 다음, 값을 다시 설정하고 sudo grub-editenv list 명령으로 확인하십시오.

고정(pinned)된 커널이 VFS: Unable to mount root fs on unknown-block(0,0) 오류로 패닉을 일으킵니다. 고정한 항목이 디스크에 더 이상 존재하지 않는 커널이나 initrd를 가리키고 있습니다. 보통 패키지는 제거되었지만 식별자가 grubenv에 남아 있을 때 발생합니다. 정상적인 항목으로 콘솔 부팅을 수행한 뒤, 유효하지 않은 값을 삭제하여 복구하십시오.

재부팅 후에도 uname -r 값이 변경되지 않았습니다. 다음 세 가지를 순서대로 확인하십시오. grub-editenv list에 여전히 설정한 값이 남아 있는지 혹은 이미 적용되었는지 확인하고, 설정한 식별자가 현재 grub.cfg에 나타나는지 확인하며, grub.cfg에 설정한 변수를 읽어오는 set default 라인이 포함되어 있는지 확인하십시오. 이 세 가지 중 하나가 항상 원인이 됩니다.

시스템 충돌 후 메뉴가 자동으로 나타났습니다. GRUB은 부팅 실패를 grubenv에 recordfail=1로 기록하며, 사용자가 개입할 수 있도록 다음 부팅 시 메뉴를 강제로 표시합니다. 시스템이 정상화되면 sudo grub-editenv /boot/grub/grubenv unset recordfail 명령으로 해당 기록을 삭제하십시오.


기억해야 할 핵심 문장 하나는 다음과 같습니다. 사용자가 편집하는 파일은 GRUB이 읽는 파일이 아니며, 클라우드 이미지에서는 이 둘 사이의 간극이 혼란의 원인이 됩니다. 먼저 생성된 설정을 읽어보십시오. 이 페이지의 모든 결정 사항은 실제 설정 파일의 내용에 근거합니다.

FAQ

GRUB_DEFAULT=1을 설정해도 왜 VPS가 다른 커널로 부팅되지 않습니까?

Ubuntu 클라우드 이미지에서 생성된 /boot/grub/grub.cfg는 보통 단일 부팅 항목만 포함하므로, 인덱스 1은 아무것도 가리키지 않으며 GRUB은 첫 번째 항목으로 되돌아갑니다. sudo grep -cE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg 명령으로 이를 확인하십시오. 항목 개수가 1로 출력될 것입니다. 원인은 /etc/default/grub.d/ 하위 파일에 이미지 제공자가 설정한 GRUB_FORCE_PARTUUID 때문이며, 이 설정은 설치된 커널 전체 목록을 생성하는 대신 직접 부팅 경로를 사용하도록 강제합니다. grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/ 명령으로 해당 파일을 찾을 수 있습니다.

이전 커널로 딱 한 번만 부팅하려면 어떻게 해야 합니까?

본인의 grub.cfg에서 복사한 식별자를 사용하여 sudo grub-reboot '<identifier>'를 실행한 뒤, 제공자의 콘솔을 열어둔 상태에서 재부팅하십시오. GRUB은 부팅 직후 next_entry을 초기화하므로, 이 선택은 단 한 번의 부팅 시도에만 적용되며 커널 패닉이 발생해도 재시도되지 않습니다. sudo grub-editenv list 명령으로 값이 올바르게 설정되었는지 확인하십시오. 이 기능에 의존하기 전에 sudo grep -n next_entry /boot/grub/grub.cfg을 실행하십시오. 설정 파일에서 grubenv를 불러오지 않는 이미지의 경우, 오류 메시지 없이 명령을 무시할 수 있기 때문입니다.

항목 번호와 식별자 중 무엇으로 고정해야 합니까?

식별자를 사용해야 합니다. 항목 번호는 10_linux이 최신순으로 재구성하는 목록 내의 위치일 뿐이므로, 커널을 설치하거나 삭제하면 번호가 바뀝니다. 오래된 1>2 설정은 여전히 유효한 다른 항목을 가리키게 되어 경고 없이 잘못된 커널로 부팅될 수 있습니다. 식별자에는 커널 버전이 포함되어 있으므로, 의도한 커널과 일치하거나 아예 부팅에 실패하게 됩니다. sudo grep -n menuentry_id_option /boot/grub/grub.cfg 명령으로 식별자를 나열하고 각 항목 줄에 표시된 따옴표 안의 문자열을 복사하십시오.

부팅 로더를 변경하는 것보다 커널 패키지를 고정하는 것이 더 안전합니까?

일반적인 목적이라면 그렇습니다. sudo apt-mark hold linux-image-virtual linux-headers-virtual을 사용하면 더 새로운 커널이 설치되지 않으므로 부팅 경로가 변하지 않으며, 콘솔 접근이 불가능한 상황에서 발생할 수 있는 실수를 방지할 수 있습니다. 먼저 apt list --installed 명령으로 현재 설치된 커널 종류를 확인하고, apt-mark showhold 명령으로 고정 상태를 검증하십시오. 단, 고정된 커널은 보안 업데이트를 받을 수 없으므로, sudo apt-mark unhold을 언제 실행할지 미리 계획을 세운 뒤 고정하십시오.