Linux 커널 4.9.0, 데비안 9에서 최대 절전 모드 재개 실패


9

최근에 커널을 3.16.4 (Debian jessie)에서 4.9.0 (Debian stretch)으로 업그레이드했습니다. "최대 절전 모드"(디스크 일시 중단)를 시도 할 때까지 모든 것이 정상이었습니다.

LXDE에서 최대 절전 모드 옵션을 사용하면 최대 절전 모드로 나타납니다. 디스크 스핀들이 똑딱 거리고 데이터를 쓰는 것을들을 수 있습니다. 그러나 최대 절전 모드에서 다시 시작할 때 문제가 나타납니다. 커널은 스왑에서 이미지를 성공적으로 복원 한 다음 작업을 잃어버린 후 정지 및 재부팅합니다. 인터넷 어디에서나 답을 찾을 수 없습니다. 사람들은 /etc/initramfs-tools/conf.d/resume을 설정하지 않거나 커널 매개 변수를 설정하지 않았거나 / etc / fstab에 잘못 입력 한 것과 관련된 몇 가지 실수를 해결하고 있습니다. 나는 이것들이 정확하다. /etc/initramfs-tools/conf.d/resume에서 UUID를 수정하고 fstab을 수정하고 resume kernel paramter를 다시 설정하지 마십시오.

  • 스왑 파티션을 확장 파티션 외부에서 기본 파티션으로 옮겼습니다. UUID가 저장되어 새 스왑에 적용되었습니다.

  • 시스템이 "이미지 복원 100 %"및 "일시 중지 콘솔"에 도달 한 후 모든 작업이 유실 된 상태에서 전원이 꺼지고 정상적으로 부팅됩니다.

  • 깨끗한 설치를 시도했지만 운이 없습니다.

  • i386 (32 비트 x86)에서만 발생하며 amd64 (64 비트 x86)에서는 문제가 발생하지 않습니다.

디스크 파티션 테이블 레이아웃 :

NAME   FSTYPE LABEL    UUID                                 MOUNTPOINT
sda                                                         
├─sda1 ext4   HDD      <ROOT-UUID> /
└─sda2 swap   HDD-SWAP <SW-UUID> [SWAP]
sr0

sda2는 업그레이드 전에 논리적 (내부 확장)이었습니다.

Fstab :

UUID=<ROOT-UUID> / ext4 errors=remount-ro 0 1
UUID=<SW-UUID> none swap sw 0 0

/etc/initramfs-tools/conf.d/resume

RESUME=UUID=<SW-UUID>

커널 cmdline

BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-686-pae root=UUID=<ROOT-UUID> ro quiet

시스템 정보:

Computer: Compaq CQ60-120ec
Swap Size: 3.5GiB
Processor: AMD Athlon X2 64 QL-66
GPU: Nvidia Geforce 8200M G
Memory: 2G DDR2 667MHz
Desktop Environment: LXDE
Debian Version: 9 (stretch)
Kernel version: 4.9.0-3
Graphics Driver: nvidia legacy 304xxx

(프로세서는 64 비트이지만 원래 32 비트 OS와 함께 제공되므로 / proc / cpuinfo를 검사 할 때까지 32 비트라고 생각했습니다)

답변:


4

이 문제로 인해 최대 절전 모드 사이의 충돌이다 kASLRx86-32 . nokaslr 커널 부팅 옵션으로 kASLR 을 비활성화하면이 문제를 해결할 수 있습니다 . x86-64 는 영향을받지 않습니다.

Grub의 경우 / etc / default / grub을 편집하고 nokaslr 을 부팅 옵션에 추가 하면 됩니다 (예 : GRUB_CMDLINE_LINUX_DEFAULT = "quiet nokaslr "

그런 다음 update-grub 을 실행 하여 구성을 업데이트하고 다시 부팅 하여 사용해보십시오.


나는 정확히 같은 문제가 있었고 PAE 커널만이 문제의 영향을받는 것으로 보입니다. PAE가없는 동일한 커널은 문제없이 작동합니다.

나를위한 해결책은 linux-image-686을 설치하고 linux-image-686-pae 및 linux-image-4.9.0-4-686-pae를 제거하는 것이 었습니다. 정확한 커널 버전은 업그레이드로 인해 시간이 지남에 따라 변경 될 수 있지만 기본적으로 현재 실행중인 PAE 커널은 PAE가없는 커널로 교체해야합니다.

내 CPU가 / proc / cpuinfo에 따라 PAE를 지원하기 때문에 실제로 CPU의 PAE 지원과는 아무런 관련이 없습니다. 그러나 PAE는 어쨌든 오래된 노트북에서는 많이 사용되지 않습니다.

데비안 백 포트의 커널 4.13 PAE와 동일한 문제가 발생하므로 커널 4.9 PAE와는 아무런 관련이 없습니다.


이 훌륭한 대답은 훨씬 더 많은 것을받을 가치가 있지만, 나는 단 하나만 줄 수 있습니다.
peterh-Reinstate Monica

네, 감사합니다.이 사이트는 전문가가 아닙니다. (Un) 다행히 amd64 버전이 문제없이 실행된다는 것을 알았으므로 686 버전 유지를 중단했다고 생각했지만 PAE가없는 686 버전이 있다는 것을 알지 못했습니다. 데비안이 문제를 해결하기를 바랍니다. 그렇지 않으면 사람들이 불평 할 것입니다.
Enginecrafter77

3

아마도 /etc/uswsusp.conf'재개 장치'에 대한 변경된 항목을 원할 것입니다. 이 장치를 사용하지 않으면 myabe는 모든 파일에서 이전 UUID를 grep하여 /etc변경이 필요한 장소를 찾으십시오. 또한 update-initramfs필요할 것입니다.


이 중 아무것도 uswsusp를 설치하고 파일이 올바른지 확인하는 데 도움이되었지만 운이 없었습니다. / etc의 구성 파일에는 이전 UUID가 포함되어 있지 않습니다.
Enginecrafter77

2

같은 오류가 발생했습니다. 최신 netinst iso (예 : debian-9.1.0-amd64-netinst.iso)로 다시 설치하면 정렬됩니다. 버그는 (적어도이 아키텍처에서는) 수정 된 것으로 보입니다.


예, 동의합니다. amd64 (예 : x64)로 수정되었지만 버그는 여전히 i386 (별명 686 또는 x86)에 있습니다
Enginecrafter77

1

나는 uswsusp를 제거했으며 최대 절전 모드는 다시 매력처럼 작동합니다. BTW 나는 nvidia 드라이버를 사용할 때 Jessie 이전의 경우라고 생각했는데, uswsusp를 사용하여 테스트했으며 최대 절전 모드 작업을 위해 제거해야했습니다.


32 비트 컴퓨터 테스트에 uswsusp가 설치되어 있지 않지만 최대 절전 모드는 여전히 작동하지 않습니다.
Enginecrafter77

너무 나쁘다. nvidia 드라이버를 제거하고 nouveau를 사용해 보셨습니까?
Alain

예, 데비안 9 설치 (32 비트)를 완전히 청소하려고했지만 여전히 문제가 있습니다. 인텔 그래픽이있는 컴퓨터에서도 발생하므로 GPU와 관련이 없다고 생각합니다.
Enginecrafter77

1

스왑 파티션 (올바른 크기)을 가지고 있고 "#blkid"결과로 "/etc/initramfs-tools/conf.d/resume"을 편집하면 i386은 데비안 i386 4.9의 버그보다 최대 절전 모드가되지 않습니다. 커널! 커널을 4.9보다 큰 버전으로 업데이트하거나 3.16 커널로 롤백하십시오.


0

이 회신의 일반적인 특성을 변명하십시오. 나는 웹 전체에서 비슷한 질문을 보았고 모두를 위해 하나의 답변을 작성하기로 결정했습니다. HP2510에서 Debian-Jessie를 업그레이드 할 때와 같은 문제가 발생했습니다. 나는 Ubuntu-desktop으로 전환하여 거기에서도 발견했습니다. 그 후 우분투와 Hp2510에서 테스트를 수행하여 귀하의 상황에 완전히 적용되지 않을 수 있습니다.

새로운 Linux 시스템으로 업데이트 된 일부 구형 컴퓨터에는 부팅 문제가 발생합니다. 전혀 부팅되지 않거나 부팅하는 데 3 분 정도 걸릴 수 있습니다. 우연히도, 그들은 동면에 실패하거나 동면과 동면을 해제하는 데 시간이 오래 걸리므로 기능이 쓸모가 없습니다. 오래된 컴퓨터가 느리기 때문이 아니라 4.8 Linux 커널에서 도입 된 변경으로 인해 종종 svideo 출력을 포함하는 매우 일반적인 인텔 칩셋에 문제가 발생하기 때문입니다. 이 커널로 시작하면이 칩셋이있는 모든 컴퓨터는 Linux 명령 줄 인수가 없으면 부팅 문제가 발생합니다"video=SVIDEO-1:d"GRUB_CMDLINE_LINUX에 포함되어 있습니다. 이렇게하면 64 비트 및 32 비트 부팅 시간이 크게 단축되지만 64 비트에 대해서만 최대 절전 모드 문제가 해결됩니다. 이 시점 이후에는 32 비트 시스템이 최대 절전 모드를 지원하지 않습니다. 또한 모든 4.8 및 4.9 커널 버전의 부팅 시간이 잘못되었습니다 (4.8.rc1-7 제외). 이것은 4.10에서 마침내 해결되었습니다. 커널 4.8과 4.9는 피해야합니다 (어쨌든 쓸모가 없습니다).

가장 빠른 부팅 시간을 원하면 4.8 이전 커널을 사용하십시오. 커널이 4.7.10으로 업데이트 된 Ubuntu-desktop 15.04를 사용합니다. 32 시스템에서 최대 절전 모드를 수행 할 수있는 유일한 방법입니다. 64 비트 시스템은 32 비트보다 7 % 느리게 부팅되지만 이후 버전보다 여전히 빠릅니다. 현재 지원되는 32 비트 시스템을 원하고 최대 절전 모드를 해제하려는 경우 4.10 이상 커널로 릴리스되거나 업데이트 된 시스템을 사용하십시오. 모든 64 비트 버전은 4.8 이후 비디오 수정과 함께 작동하지만 최상의 성능을 위해서는 4.8 및 4.9를 피하십시오.

비디오 수정 프로그램을 추가하려면를 수행하십시오 sudo nano /etc/default/grub. 나노를 닫은 후 sudo update-grub. GRUB_CMDLINE_LINUX 이후에 삽입되는 GRUB_CMDLINE_LINUX_DEFAULT가 비어 "video=SVIDEO-1:d"있지 않으면, 일부 사람들이 필요로하는 마지막 Linux 명령 행 인수가되지 않습니다. 실제로 어디에나있을 수 있습니다.

터미널 (또는 tty)에서 pm-hibernate 명령을 사용하여 최대 절전 모드를 항상 호출 할 수 있지만 사용 가능한 GUI 옵션을 사용 /etc/polkit-1/localauthority/50-local.d/ com.ubuntu.enable-hibernate.pkla하려면 다음 텍스트를 정책 파일에 작성하거나 추가해야합니다 (분명히 distro 특정).

[Re-enable hibernate by default for login1]
    Identity=unix-user:*
    Action=org.freedesktop.login1.hibernate
    ResultActive=yes
[Re-enable hibernate for multiple users by default in logind]
    Identity=unix-user:*
    Action=org.freedesktop.login1.hibernate-multiple-sessions
    ResultActive=yes

0

때때로 문제는 grub 또는 UUID에 없습니다. 저장 공간이 부족한 경우에도 발생합니다. 남은 쓰기 공간이 없으므로 최대 절전 모드에서 다시 시작하면 정지됩니다.

해당 오류가 발생하면 클릭 alt+ f2/f3/f7하거나 ctrl+alt+ f2/f3/f7터미널을 열 수 있습니다 . 터미널을 사용하여 계정 또는 루트에 로그인하십시오.

그런 다음 명령 sudo df -h을 실행하여 저장 공간을 확인하십시오. 내 경우에는 공간이 없었습니다./dev/sda1 으므로 목록의 드라이브에서 여유 공간을 확인하십시오.

공간이 부족한 경우 일부 파일을 삭제하여 상당한 공간을 확보하십시오.

그런 다음 alt+f1또는을 클릭 ctrl+alt+f1하고 로그인 GUI가 나타날 때까지 기다리거나 입력하십시오.reboot in the terminal to reboot


시도해 주셔서 감사하지만이 문제는 이미 해결되었습니다. 문제는 4.9.0 i386 + PAE 커널에 있습니다. 나중에 내 PC가 64 비트 소프트웨어를 실행할 수 있음을 알았지 만 (PC는 내가 얻은 날부터 항상 32 비트를 실행했지만) 64 비트 커널로 문제가 해결되었습니다.
Enginecrafter77

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