(2.8)을 설치 했고 unattended-upgrades프로세스가 실행 중입니다.
그러나 업그레이드를 설치하려고 하면 다음 오류가 계속 발생합니다.
Processing triggers for initramfs-tools (0.140) ...
update-initramfs: Generating /boot/initrd.img-5.10.0-18-amd64
pigz: abort: write error on <stdout> (No space left on device)
E: mkinitramfs failure pigz 28
update-initramfs: failed for /boot/initrd.img-5.10.0-18-amd64 with 1.
dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
initramfs-tools
이 문제는 다음 명령을 사용하여 이전 커널 이미지를 수동으로 제거하면 해결될 수 있습니다.여기.
커널 이미지 제거가 작동하지 않을 때(한 번 발생함) 일부 배경 및 해결 방법은 다음과 같습니다.여기데비안의 완전히 오래된 90년대 스타일 이메일 기반 버그 추적기에서 지금까지 사용되지 않은 버그 보고는 다음과 같습니다.여기.
저는 데비안 11과 KDE를 사용하고 있습니다. 이런 일은 오랫동안 일어났고 지금도 여러 번 일어났습니다. 이것이 왜(또는 알아내는 방법)?
자동으로 제거되지 않으면 부팅 파티션 디스크 공간 부족으로 인해 업그레이드가 실패할 때 최소한 위의 명령을 사용하여 이전 커널 이미지를 제거해야 한다고 생각합니다.
답변1
일부 의견에서 지적했듯이 어떤 커널 이미지가 필요하고 필요하지 않은지 결정하는 것은 데비안의 일이 아닙니다. 데비안은 새 버전을 설치할 때 커널 이미지를 보존하기 위해 올바른 조치를 취하고 있으므로 새 버전에 문제가 있는 경우 이전 버전으로 부팅할 수 있습니다. Frost Schutz가 자신의 의견에서 지적했듯이 Arch Linux에는 새 커널 이미지를 설치할 때 이전 커널 이미지를 삭제하는 반대 문제가 있습니다. 이는 내 경험상 매우 바람직하지 않은 동작입니다. 일반적으로 꽤 잘 작동하지만 항상 그런 것은 아닙니다. 특히 새로운 커널에서의 회귀입니다.
이 동작은 시스템에서 수행하려는 작업, 구성 방법, apt 사용 방법, 새 커널 설치에 사용하는 방법에 따라 달라질 수 있지만 저는 항상 그대로 두기로 했습니다. 새 커널이 제대로 작동하는지 확인한 후 시스템 유지 관리의 일부로 커널을 명시적으로 제거할 때까지 이전에 설치한 커널을 사용했습니다.
그러나 나는 여러분이 안정적인 데비안에서 커널 메타패키지를 사용하고 있다고 생각하는데, 이는 약간 다릅니다. 그리고 업그레이드된 커널을 설치할 때마다 새로운 항목이 grub 부팅 목록에 추가된다고 믿습니다(예: initrd.img-4.15.0-191 to to initrd.img-4.15.0-192). 따라서 커널은 제거할 때까지 계속 설치되어 있는 패키지입니다. 데비안은 시스템 관리자가 장기적으로 작업을 수행할 수 있을 만큼 파티션이 충분한지 확인하고 파티션 크기가 문제가 될 때 예약된 정리를 수행하는 것과 같은 간단한 사항에 대해 알기를 원한다고 안전하게 말할 수 있습니다.
그러나 이는 각각의 새 이미지가 설치 후 약 150MiB를 차지한다는 점에서 완전히 벗어난 것이므로 여기서 실제 문제는 단순히 /가 너무 작다는 것입니다. 또는 별도의 /boot 파티션을 사용하는 경우 너무 작습니다. 세부 정보를 제공하지 않은 설정에 따라 다르지만 이것이 주요 문제입니다.
일반적으로 이 기능을 사용하여 apt autoremove더 이상 사용하지 않는 오래된 패키지를 제거할 수 있으므로 가장 쉬운 솔루션이 될 수 있습니다. 매일 또는 매주 실행하도록 스크립트를 작성하기만 하면 됩니다.
/boot, initrd.img, System.map 및 vmlinux- 파일을 확인하면 각각 약 22MiB이고 원격 서버의 그룹당 3개 파일은 약 55MiB로 그다지 크지 않습니다. 이는 /boot가 실제로 너무 작다는 것을 나타냅니다. , 그러나 이는 / 및 /boot의 모양과 별도의 파티션인지 여부에 따라 다릅니다.
환경을 제어할 수 없거나 장기적으로 더 유용하게 만들기 위해 파티션 크기를 조정할 수 없는 경우 apt autoremove자동 업그레이드가 실행된 후 밤에 실행하는 것이 아마도 최선의 선택일 것입니다. 또는 apt-get autoremove데비안이 더 오래된 경우.
일부 원격 서버를 확인해보니 현재 커널과 이전 커널 2개를 사용하는 경향이 있음을 발견했지만 정리 작업이 무엇인지, apt로 수행할 수 있는 설정이나 구성인지, 아니면 스크립트로 작성된 것인지는 알 수 없습니다. 늦게 실행되는 솔루션. 이것은 확실히 수동으로 수행되지 않습니다.
나는 또한 Frost Schutz가 개별 파티션이 매우 작은 크기를 제안한다면 종종 테라바이트급의 저장 공간이 있지만 열이 없을 때 /boot 크기 조정에 대한 온라인 지침이 의미가 없다는 점에 동의합니다. 시스템 사양이므로 이는 단지 추측일 뿐입니다. 일반적으로 질문을 게시할 때 질문과 관련된 정보를 게시해야 합니다. 그렇지 않으면 사람들이 추측해야 합니다.
오랫동안 시스템을 실행할 계획이라면 사용된 용량의 최소 2배/사용된 용량이 필요하며, 콘텐츠는 시간이 지남에 따라 항상 커지기 때문에 3~4배가 더 좋습니다. /boot가 분리된 경우 시간이 지남에 따라 각 반복이 약 10% 증가한다고 가정하고 각 코어가 차지하는 양을 계산하면 활성 상태로 유지하려는 코어 수가 분리될 경우 사용될 코어 수를 결정합니다. /boot는 커야 합니다. 보안상의 이유로 오버헤드가 추가됩니다.
또한, 물론 모든 업데이트 후에 apt-get clean을 실행하고 싶을 수도 있습니다. 그렇지 않으면 /var/cache/apt가 이전 패키지로 채워질 것입니다.