USB Disk Check at Boot - XIYO/asuswrt-merlin.ng-kr GitHub Wiki

고지사항

이 가이드에 제시된 솔루션 및 의견은 저자 (latenitetech) 의 것이며, 다른 누군가가 이 특정 위키 문서를 수정하기 전까지 해당합니다. 이는 RMerlin 또는 권한을 가진 다른 누군가에 의해 인증되지 않았으며, 상대적으로 초보자를 대상으로 주로 제공되었으며 이 놀라운 소프트웨어 컴파일레이션을 최대한 활용할 수 있도록 돕기 위해 제공되었습니다. 자기 책임하에 사용하거나, 이것이 너에게 너무 어렵다면 다른 곳으로 이동하십시오.

AsusWRT-Merlin 런닝 라우터의 부팅 시 USB 디스크 확인

이 가이드는 루터를 설정하여 부팅 시 USB 저장 장치를 자동으로 확인하는 한 가지 방법을 보여줍니다. 이는 사용자 스크립트에 관한 위키 가이드에 언급되어 있습니다: User Scripts Wiki Guide

이 가이드는 이미 사용자 스크립트를 활성화한 것으로 가정합니다 (웹 인터페이스에서 "Administration -> System" 아래에서 스크립트가 활성화되어 있어야 함). 이 가이드는 펌웨어에 이미 내장된 기능만 사용하기 때문에 entware에 의존하지 않습니다. 그러나 여기 포함된 일부 팁은 entware와 이 솔루션의 상호 작용과 관련이 있습니다.

이 가이드는 파일 시스템 유형이 혼합되어 있는 경우를 다룹니다. 일반적으로 entware 설치용으로 최소한 하나의 Linux 파일 시스템 (예: EXT2)이 있고 미디어 파일을 위한 대부분의 플래시 드라이브 또는 외부 USB 저장 장치에 포함된 FAT32 또는 NTFS 파일 시스템이 포함됩니다. 또한 잠재적인 함정 및 해결책을 설명하고 관련 주제를 다룹니다.

기본 설치는 상당히 간단합니다. 다음 코드 세그먼트의 내용을 /jffs/scripts/pre-mount로 설치하기만 하면 됩니다.

#!/bin/sh
# pre-mount script (to be installed in /jffs/scripts)
# auto-check filesystems during boot
# first argument is the filesystem to be mounted (e.g. /dev/sda1)

CHKLOG=/var/fsck.log

# determine the type of filesystem being mounted
FSTYPE=`fdisk -l ${1:0:8} | grep $1 | cut -c55-65`

# determine the appropriate checker for the filesystem
case "$FSTYPE" in
        Linux )
                CHKCMD="e2fsck -p" ;;
        Win95* | FAT* )
                CHKCMD="fatfsck -a" ;;
        HPFS/NTFS )
                CHKCMD="ntfsck -a" ;;
        * )
                logger "$0:" "Unknown filesystem type $FSTYPE on $1 - no filesystem check run."
                exit 1 ;;
esac

logger "$0:" "Running '$CHKCMD $1' - see output at $CHKLOG"
echo -e "\nStarting '$CHKCMD $1' at `date`" >> $CHKLOG
$CHKCMD $1 >> $CHKLOG 2>&1

그리고 아래의 링크에서 스크립트 생성 가이드라인을 따르십시오.

... 파일을 UNIX 인코딩으로 저장해야 합니다. Windows의 Notepad는 UNIX 인코딩으로 저장할 수 없으므로 Notepad++을 사용하세요. 또한 펌웨어에 포함된 vi 또는 nano를 사용하여 SSH 또는 텔넷을 통해 라우터에서 직접 편집할 수 있습니다. 이 두 가지 방법은 이미 올바른 형식으로 인코딩된 파일을 생성합니다.

따라서 Windows 사용자를 위한 빠른 옵션 중 하나는 SSH 또는 텔넷을 통해 nano를 실행한 다음 위의 스크립트 내용을 nano 창에 복사/붙여넣기하고 최종적으로 /jffs/scripts/pre-mount로 저장하는 것입니다.

스크립트를 실행 가능하게 만드십시오 (chmod a+rx /jffs/scripts/pre-mount).

[얼마나 많은 시간을 잊고 이 단계를 수행하지 않고 남아있는 상태로 머릿속에서 끙끙대며 왜 작동하지 않는지 궁금해했는지 모를 것입니다!]

현재 이 스크립트는 모든 종류의 Linux 파일 시스템 (EXT2, EXT3, EXT4 - 모두 'Linux'로 식별됨), Windows FAT (FAT16), FAT32 및 NTFS를 지원합니다. 현재 이 스크립트는 Apple의 HFS를 처리하지 않습니다. HFS는 현재 내가 Apple 사용자가 아니기 때문에 HFS 파일 시스템에 대해 fdisk가 반환하는 문자열을 모르기 때문입니다. 아마도 'HFS'일 것이지만 FAT32가 'Win95'로 반환되어 예상치 못한 결과가 나왔으므로 잘못된 결과를 얻는 것을 피하기 위해 제외했습니다. 누군가가 올바른 항목을 확인할 수 있다면 이 위키를 업데이트하고 이 주석을 제거하십시오!

*fsck의 모든 실행에서 수행한 작업을 정확히 알려주는 출력은 RAM의 /var/fsck.log에 저장됩니다 (실제로는 /tmp/var에 있으며 이는 부팅 시 생성되는 RAM의 가상 파일 시스템인 /tmp에 연결됩니다). 이 모든 것은 다음 부팅 시 로그 파일이 사라지므로 부팅하기 전에 관심이 있다면 확인하러 가보세요.

이 스크립트는 가장 빠르고 침입적이지 않은 디스크 확인 방법을 실행합니다. 디스크가 'dirty'로 표시되지 않았다면 (마지막으로 깨끗하게 마운트되었다면) 디스크 확인은 최소한의 작업만 수

행하고 종료되며, 일반적으로 1초 이내에 완료됩니다. 그러나 'dirty bit'가 설정되어 있다면 디스크 자동 확인 및 정리를 수행하며, 디스크의 크기와 발생한 오류의 수에 따라 시간이 오래 걸릴 수 있습니다. 제 개인적인 철학은 디스크에 오류가 있다면 얼마나 오래 걸리더라도 서비스로 돌아가기 전에 고치는 것이 나을 것이라는 것입니다. 라우터의 주요 기능(예: 연결된 클라이언트에게 인터넷 트래픽 제공)은 이 스크립트와 병렬로 동작하기 때문에 이로 인해 지연되지 않습니다.

주의 사항

1) 부팅 시간 연장

이 스크립트로 인한 부팅 시간의 변동 가능성 때문에, 현재 추가 기능이 영향을 받을 수 있습니다. 가장 가능성 있는 상호작용은 entware의 rc.unslung을 호출하여 entware 하에 설치된 서비스를 시작하는 것입니다. entware의 기본 설치 스크립트는 서비스 시작에 entware 볼륨이 사용 가능해질 때까지 30초만 기다리는 간단한 대기 루프를 설치합니다. 타임아웃이 되면 시스템 로그에 "Entware를 시작할 수 없습니다." 라는 메시지를 보냅니다. 디스크 검사를 수행하는 데 걸리는 추가 시간은 이 대기 루프가 실패할 수 있으며, 특히 fsck가 실제로 디스크 정리 작업을 해야 할 경우 더욱 그렇습니다.

http://www.snbforums.com에서 스레드를 살펴보면, 'entware 시작을 위한 대기 루프'는 오래된 문제이며, 적어도 2013년까지 거슬러 올라가고, 아마도 그 이전부터 있었습니다. 그리고 이에 대한 해결책에 대한 다소 종교적인 논쟁이 있습니다. 가장 간단한 해결책은, 이 환경의 오랜 사용자들이 많이 지지하는 방법으로, 단순히 대기 루프를 더 길게 만드는 것입니다. 서비스 시작 스크립트 상단의 _'i=30'_을 _'i=60'_으로 변경하는 것(대기할 초 수)은 "정상" 부팅(디스크 검사가 빠르게 진행될 때)을 해결할 수 있지만, 디스크 검사가 심각한 작업을 해야 하는 경우에는 여러 분 동안 설정하지 않는 한 좋지 않은 해결책입니다. 이 경우, 서비스를 수동으로 시작해야 할 수도 있습니다(텔넷이나 ssh 창에서 _'/opt/etc/init.d/rc.unslung start'_를 실행), 또는 모든 것이 올바르게 시작되도록 다시 부팅해야 할 수도 있습니다. 하지만 좋은 대안이 있습니다(적어도 제 생각에는 좋습니다…), 하지만 대안을 추구하기 전에 이러한 주의사항을 먼저 읽어보세요.

a) 특정 인기 있는 추가 응용 프로그램들은 entware에 대해 원래의 서비스 시작 디자인을 요구하고/또는 강제합니다. 그 중 하나는 AB-Solution입니다(https://github.com/RMerl/asuswrt-merlin.ng/wiki/How-to-use-Adblock-using-Pixelserv). 이 응용 프로그램을 사용 중이거나 사용할 계획이라면 아래 대안을 건너뛰세요. 그것은 옵션이 아닙니다. 이 제한을 가진 다른 앱들도 있을 수 있으므로, 아래 대안을 채택하고 어떤 것이 작동하지 않는다는 것을 발견하면 '서비스 시작 지연 루프' 방법으로 되돌아갈 수도 있습니다.

b) 특정 라우터들(예: RT-N66U)은 entware 볼륨으로 SD 카드를 사용할 수 있으며, 이렇게 구성되면 순전히 USB 저장 볼륨을 사용하는 라우터들과 다른 부팅 순서를 가집니다. 아래

에서 권장하는 변경사항이 이러한 구성과 호환되지 않는 것으로 보고되었으므로, 아래 방법은 적용되지 않을 수 있습니다.

위의 주의사항을 제외하고, 저와 다른 이들은 서비스 시작 스크립트를 완전히 제거하고 entware rc.unslung 호출을 post-mount로 옮기는 것을 옹호했습니다. '/tmp/opt' 링크가 만들어진 후, 그리고 스왑이 활성화된 후(설치된 경우)에 같은 블록에서 이렇게 보입니다:

#!/bin/sh
#
# /jffs/scripts/post-mount
#

if [ "$1" = "/tmp/mnt/sys" ] ; then
    # Entware 설정 및 실행
    ln -nsf $1/entware /tmp/opt

    logger "$0:" "스왑 활성화 /opt/swap에서"
    swapon /opt/swap

    logger "$0:" "Entware 서비스를 시작하기 위해 rc.unslung 실행 ..."
    /opt/etc/init.d/rc.unslung start
fi

이 솔루션은 서비스 시작의 대기 루프를 완전히 없애고, entware와 관련해서는 서비스 시작을 전체적으로 없애버리는 것과 같습니다. 그리고 이것은 사실상 동일한 것입니다. 왜냐하면 모든 서비스 시작 대기 루프는 post-mount에서 '/tmp/opt'로의 링크가 만들어지기를 기다리는 것이 전부이기 때문입니다. 이것은 부팅 시퀀스에서 디스크 검사에 얼마나 오래 걸리든지 관계없이 항상 entware rc.unslung이 호출될 것임을 보장합니다. 부팅은 항상 라우터를 그 "정상" 상태로 되돌려야 하며, 로그에서 그 두려운 "Entware를 시작할 수 없습니다." 메시지를 찾을 필요가 없습니다.

이 솔루션은 또한 다른 유익한 부수적 효과들을 가지고 있습니다:

• 서비스 시작 대기 루프 모델에서는 rc.unslung이 서비스 시작(서비스 시작에서)에 발동되고 스왑이 활성화되는 시점(post-mount에서) 사이에 경쟁 상태가 있습니다. 서비스가 시작되기 전에 스왑이 마운트되는 것이 바람직하지만, '서비스 시작 대기 루프' 시스템의 로그를 보면 서비스가 스왑이 완전히 활성화되기 전에 시작되는 것을 볼 수 있습니다. 이것이 시작된 서비스가 메모리 집약적인 경우 문제를 일으킬 수도 있고, 아닐 수도 있습니다.

• entware를 담고 있는 USB 드라이브를 제거하고 다시 설치하면, post-mount 솔루션은 entware를 올바르게 재시작합니다(rc.unslung은 리마운트 시 다시 호출됩니다). 하지만 서비스 시작 솔루션을 사용하면, rc.unslung을 수동으로 다시 실행하거나 라우터를 다시 부팅해야 합니다(서비스 시작은 부팅 시 한 번만 실행됩니다).

어쨌든, 모든 종교적 논쟁과 마찬가지로, 어떤 방법이 당신에게 맞는지 자유롭게 선택하세요. 이 대안을 제시하는 것뿐입니다.

2) 부팅 중에 실행되는 FSCK가 '메모리 부족' 오류로 실패합니다

대규모 디스크 정리 작업(즉, 부팅 시 fsck가 실행될 때 디스크가 실제로 손상된 경우) 중에는 메모리 부족으로 인해 작업을 완료하는 것이 불가능할 수 있습니다. 이는 대용량 HDD 및/또는 많은 오류가 있는 경우에 발생할 수 있습니다. 부팅 중에 실행되기 때문에 시스템에 스왑이 있는 경우 (시스템에 스왑이 있는 경우) 아마도 아직 로드되지 않은 상태입니다.

이를 해결하기 위해 사용 가능한 몇 가지 옵션이 있습니다: a) 드라이브를 다른 컴퓨터(예: PC)로 이동하여 디스크를 정리한 후 라우터에 다시 설치합니다.

b) 라우터에 스왑 파일이 설치되지 않은 경우, 먼저 스왑 파일을 설치하십시오. 스왑을 설치하고 활성화한 후에 라우터가 작동하고 스왑이 활성화된 후에 디스크를 수동으로 확인하십시오. 필요한 'umount' 및 'fsck' 명령을 명령 줄에서 실행하는 것을 피하려면 아래에서 언급된 내장 'Health Scanner'를 사용할 수 있습니다.

하지만 웹 GUI에서 사용 가능한 'Health Scanner'는 어떻게 되나요?

AsusWRT 펌웨어에는 이미 웹 GUI에서 접근할 수 있는 디스크 확인 기능이 내장되어 있다는 사실이 지적되었습니다. 네트워크 맵 화면에서 USB 드라이브 아이콘을 클릭하면 오른쪽에 'Health Scanner' 탭이 있는 패널이 열립니다. 여기서 USB 저장 장치 중 하나에 대한 포괄적인 디스크 스캔을 시작할 수 있습니다. 또한 해당 화면에서 주기적인 확인을 예약할 수도 있습니다. 이 메커니즘의 문제점은 원래 AsusWRT의 일부이며 Merlin 확장 기능을 이해하지 못하기 때문에 먼저 entware를 중지시키지 않으며 (entware가 시작한 서비스 및/또는 스왑 파일을 사용하려면 활성화해야 함) 스토리지 볼륨을 _umount_할 수 없을 때 꽤 우아하지 못한 방식으로 실패합니다.

다음은 이 기능을 더 잘 작동하게 만드는 또 다른 간단한 사용자 지정 스크립트입니다. '/jffs/scripts/unmount'에 설치하십시오 (스크립트 설치에 대한 주의 사항은 위에서 언급한대로 적용됩니다):

#!/bin/sh
#
# /jffs/scripts/unmount
#
# 먼저 "entware 볼륨"을 unmount하기 전에 entware를 중지합니다.
#

# '/opt' 마운트 포인트와 $1을 비교하여 이것이 entware 볼륨인지 확인합니다.
OPT=$(dirname $(readlink /tmp/opt))
if [ "$1" == "$OPT" ] ; then
        # 이 코드는 'services-stop'에 있는 것과 동일하므로 그냥 services-stop을 호출할 수도 있습니다.
        /opt/etc/init.d/rc.unslung stop
        swapoff /opt/swap
fi

이 추가로 Health Scanner가 더 잘 작동합니다. 이제 Health Scanner가 entware 볼륨의 Health Check를 성공적으로 수행할 수 있습니다. 그럼에도 불구하고 아직 몇 가지 문제가 있습니다. 나는 이 문제가 RMerlin이 해결하려고 시도하지 않은 원래 AsusWRT 코드에 있는 것으로 생각합니다. 그것은 내장 Samba와 minidlna 프로세스를 시작하고 중지할 때 혼란스러워 보입니다. 최소한 한 번은 minidlna 데이터베이스를 손상시켰으며 다음 부팅 시 다시 생성해야 했습니다. 큰 문제는 아니지만 원래처럼 동작해서는 안 됩니다. 이 문제가 실제로 무엇이 일어나고 있는지 이해하려는 시간을 들이지 않았으므로 예약된 스케줄로 자동으로 실행할 만큼 믿지 않습니다. 하지만 시도해 보세요. 여러분에게 작동한다면 그만한 가치가 있습니다...

질문/의견이 있으십니까? 저를 SNBForums에서 'latenitetech'로 찾아보세요. 가능한 한 도움 드리겠습니다.

-마크