Devuan ASCII에서 실행되는 Sun Ultra 24 워크스테이션에서 발생하는 성가신 종료 문제를 해결하려고 합니다.
groucho@devuan:~$ inxi -b
System: Host: devuan Kernel: 4.9.0-8-amd64 x86_64 (64 bit) Desktop: Xfce 4.12.3
Distro: Devuan GNU/Linux ascii
Machine: Device: portable System: Sun Microsystems product: Ultra 24 v: 0.00.01
Mobo: Sun Microsystems model: Ultra 24 v: 50 BIOS: American Megatrends v: 1.56 date: 01/21/2011
--- snip ---
groucho@devuan:~$
분명히 휴대용 시스템은 아닙니다. 단지 이 BIOS 파일이 2010년 1월(Sun이 붕괴된 날짜) 이후에 출시되었다는 것뿐입니다.
groucho@devuan:~$ uname -a
Linux devuan 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux
groucho@devuan:~$
이는 배포와 무관한 문제인 것 같습니다. 이는 Emergency TCore Linux와 동일한 장치에서도 발생하며 부팅 시 F8을 통해 메모리 스틱의 Emergency TCore Linux에 액세스할 수 있습니다.
MSOS 설치에서 이런 일이 발생하는지 모르겠습니다. MSOS가 없고 테스트를 위해 XP를 실행하는 가상 머신만 있기 때문입니다.
질문은 기본적으로 다음과 같습니다.
종료되면 기계는 다음 두 가지 작업 중 하나를 수행합니다.
- 제대로 닫히다
- 현재 종료 중 동결 중...
e1000e: EEE Tx LPI Timer
Preparing to enter sleep state S5
Reboot: Power Down
...팬이 최고 속도로 회전합니다.
처음에는 이는 두 부분으로 구성된 문제였습니다. 첫 번째는 종료 시 재부팅 문제였지만 이는 WoL을 비활성화하여 (분명히) 해결되었으며 다시는 발생하지 않았습니다.
두 번째 부분(첫 번째 부분과 마찬가지로)은 완전히 예측할 수 없는 방식으로 발생하므로 복제하거나 특정 항목에 연결할 수 없습니다.
WoL을 비활성화하는 것(BIOS를 통해 수행할 수 없기 때문에 약간 번거로움) 외에도 Intel e1000e 컨트롤러에서 EEE 설정도 비활성화했지만 아무런 효과가 없었습니다.
종료 시 스크립트를 사용하여 e1000e 드라이버 모듈을 제거하거나 커널 명령줄에 다양한 restart= 섹션을 삽입하는 것도 효과가 없습니다. 즉, 재부팅=강제, 재부팅=acpi, 재부팅=BIOS 등입니다.
무슨 일이 일어나고 있는지 이해하기 위해 종료 프로세스의 각 단계를 격리하고 MS-DOS에서 했던 것처럼 터미널에서 피드백을 제공하는 스크립트를 사용하여 장치를 종료하기로 결정했습니다. 이전과 마찬가지로 config.sys 및 autoexec.bat를 단계별로 실행하여 시작 문제를 제거하십시오.
#!/bin/sh
#Shut down system without the use of shutdown helper
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin:
for i in s u o; do echo $i | sudo tee /proc/sysrq-trigger; sleep 2; done # halt
하지만 아니요, 여러 번 종료한 후에 마침내 다시 발생하며 이것이 화면에 표시되는 내용입니다.
s
u
sudo: unable to open log file: /var/log/sudo.log: read only file system
...팬이 최고 속도로 회전합니다.
종료 정지가 발생하지 않으면 var/log/messages는 항상 파일을 읽습니다.
Mar 8 09:37:16 devuan kernel: [ 8831.030260] sysrq: SysRq : Emergency Sync
Mar 8 09:37:16 devuan kernel: [ 8831.051494] Emergency Sync complete
Mar 8 09:37:18 devuan kernel: [ 8833.038247] sysrq: SysRq : Emergency Remount R/O
Mar 8 09:37:18 devuan kernel: [ 8833.069992] EXT4-fs (sdb1): re-mounted. Opts: (null)
Mar 8 09:37:18 devuan kernel: [ 8833.139131] EXT4-fs (sdb6): re-mounted. Opts: (null)
그러나 때때로 (전부는 아니지만) 동결을 끄면 관련 로그 파일에 긴 ASCII "비텍스트" 코드 문자열, 특히 0xx(문자열 종료 문자)가 기록됩니다. 이는 다음과 같은 비정상적인 중지에 대한 표준 동작으로 보입니다. 동결로.
이로 인해 로그 파일이 엉망이 되고 일반적인 텍스트 편집기가 로그 파일(Pluma) 열기를 완전히 거부하는 지점까지 파일(Leafpad)에 표시됩니다. 실제로 파일의 모든 내용을 표시하는 16진수 편집기나 MC로 파일을 열어야 합니다.
따라서 지금 나에게 필요한 것은 종료 프로세스의 이 부분을 더 자세히 조사하고 종료가 정지되는 원인을 이해하는 방법입니다.
그럼 내가가능한안정적으로 재현할 수 있습니다.
이는 Ultra 24의 보기 흉한 BIOS로 인해 발생할 수도 있고, 충분한 수의 설치에 영향을 주지 않았고 보고, 배포 및 포기되지 않았기 때문에 관리자가 무시한 커널의 모호한 버그일 수도 있습니다. 지원은 거기서 끝나니까 귀찮아어느.
나는 잘못된 할당(예: LibreOffice)의 몇 가지 예를 보았습니다. 담당자가 가용성 부족으로 인해 작업을 중단한 후 어떤 이유로든 작업을 수행하지 않고 다른 사람에게 전달되어 결국 작업을 수행하지 못하는 경우가 있었습니다. 수년 동안 할당되었습니다.
이 문제를 추가로 해결하기 위해 종료 프로세스를 확인하는 다른 방법이 있습니까?