레드필의 마지막 남은 고질병 DSM 설치중 55% 파일손상현상이 해결 가능할것 같습니다.
화정큐삼https://github.com/RedPill-TTG/redpill-boot-wait/blob/master/src/boot… (2804)https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/boot-wait/src/bo… (2785)
ARPL fabio 님과 TCRP pocopico님도 손을 놓으신 부분인데요.
TTG 그룹의 레드필 창시자 TG 님이 레드필 초기부터 개발해 주셨던 boot-wait 란 스크립트가 있습니다.
55% 파일손상 메시지 현상이 발생하는 이유는
DSM 설치과정에 필수적으로 필요한 /dev/synoboot , /dev/synoboot1, /dev/synoboot2, /dev/synoboot3
이 4개의 노드가 자동으로 수초내 인식되서 올라와야 하는데
그게 어떤 이유에서인지 몰라도 올라오지 못하는 경우가 발생합니다.
그래서 최대 30초를 기다리며 이 4개의 노드인식을 기다립니다.
노드인식이 실패하면 결국 노드가 없는 상태에서는 DSM 설치중간 55% 지점에서 DSM 파일이 손상되었다는 메시지를 보냅니다.
실제로는 이 DSM PAT 파일이 손상된것은 아닙니다.
가장 흔하게 알려진 이유중 하나는 USB 메모리의 VID / PID 가 잘못기록된 경우에 발생했었습니다.
제 M SHELL 에서는 이 VID / PID 부분을 자동처리 하기 때문에 이런 현상이 유발될 확률은 0% 입니다.
하지만, MSATA 나 SATA , VM 등 VID / PID 가 필요없는 케이스에 대해서도 원인모를 이 현상이 발생하는 경우가 있습니다.
지금까지 이런 경우가 발생하면 로더를 TCRP FRIEND / TCRP JOT / ARPL 사이에 바꾸어서 로더를 빌드하거나
USB 메모리를 3.0 이상의 버전으로 3.0 이상 포트에 장착하시라는 가이드를 해왔습니다.
이렇게 해서도 안되는 경우라면 해당 PC 에서는 레드필 설치는 불가능한 경우가 되었습니다.
하지만, 약간의 트릭을 가해서 이부분을 넘어가고 DSM 설치가 가능하도록 조금전 구현 완료 했습니다.
M SHELL for TCRP 에서만 수정된 버전입니다.
boot-wait.sh 스크립트를 보완했는데,
어짜피 이 4개의 노드가 수초내 올라오지 않으면 30초를 기다려서도 절대 나오지 않습니다.
그래서 30초씩 기다리던것을 10초로 줄였고,
10초 안에도 응답이 오지 않는 경우에는 위 4개 노드를 아래 스크립트로 강제로 생성합니다.
mknod /dev/synoboot b 8 1
mknod /dev/synoboot1 b 8 1
mknod /dev/synoboot2 b 8 1
mknod /dev/synoboot3 b 8 1
이 상태에서 DSM 을 설치한 결과 시놀로지가 요구하는 위 4개의 노드가 존재하기 때문에 정상 설치가 되었습니다.
이번 개선으로 55% 파일손상 메시지 없이 DSM 신규설치가 가능하도록 구현을 마쳤습니다.
헤놀포럼에도 반가운 소식이 될것 같습니다.
pocopico / fabio 님께도 알려드려서 TCRP / ARPL 에도 적용하시라고 알려드려야 겠습니다.
pocpico님은 현재 생업이 너무 바쁘셔서 TCRP 코딩을 하실 시간이 없으시다고 합니다.
TCRP 는 당분간 M SHELL 안에서만 사용해 주시기 바랍니다.
이 기능의 사용을 위해선 M SHELL 로더를 다시 빌드해 주셔야 합니다.
[force make synoboot node]
SynologyNAS> mknod /dev/synoboot b 8 1
SynologyNAS> mknod /dev/synoboot1 b 8 1
SynologyNAS> mknod /dev/synoboot2 b 8 1
SynologyNAS> mknod /dev/synoboot3 b 8 1
SynologyNAS> ll /dev/syno*
crw-r--r-- 1 root root 201, 0 Mar 16 11:55 /dev/synobios
brw------- 1 root root 8, 1 Mar 16 12:12 /dev/synoboot
brw------- 1 root root 8, 1 Mar 16 12:12 /dev/synoboot1
brw------- 1 root root 8, 1 Mar 16 12:12 /dev/synoboot2
brw------- 1 root root 8, 1 Mar 16 12:12 /dev/synoboot3
[junior log]
Running "boot-wait.sh" for thethorgroup.boot-wait->on_boot
Still waiting for boot device (waited 1 of 10 seconds)
Still waiting for boot device (waited 2 of 10 seconds)
Still waiting for boot device (waited 3 of 10 seconds)
Still waiting for boot device (waited 4 of 10 seconds)
Still waiting for boot device (waited 5 of 10 seconds)
Still waiting for boot device (waited 6 of 10 seconds)
Still waiting for boot device (waited 7 of 10 seconds)
Still waiting for boot device (waited 8 of 10 seconds)
Still waiting for boot device (waited 9 of 10 seconds)
Still waiting for boot device (waited 10 of 10 seconds)
ERROR: Timeout waiting for /dev/synoboot device to appear.
Most likely your vid/pid configuration is not correct, or you don't have drivers needed for your USB/SATA controller
========== BEGIN DUMP OF ALL PARTITIONS DETECTED ===========
/dev/sda1 2048 147455 145408 83
/dev/sda2 147456 301055 153600 83
/dev/sda3 301056 2097151 1796096 83
/dev/sdg1 8192 16785407 16777216 fd
/dev/sdg2 16785408 20979711 4194304 fd
/dev/sdg3 21241856 3906824351 3885582496 fd
========== END OF DUMP OF ALL PARTITIONS DETECTED ==========
Force the creation of synoboot , synoboot1 , synoboot2 and synoboot3 nodes...
Confirmed a valid-looking /dev/synoboot device
질문 : 어떻게 /dev/synoboot 장치를 나타나게 하는가?
/dev/synoboot 장치는 Synology NAS에서 부팅 파티션을 나타내는 장치입니다. 만약 이 장치가 없다면, Synology NAS가 부팅하지 않을 수 있습니다.
일반적으로 Synology NAS에서 /dev/synoboot 장치는 시스템이 부팅될 때 자동으로 생성됩니다. 하지만, 때로는 이 장치가 생성되지 않는 문제가 발생할 수 있습니다.
이 경우, 아래의 방법 중 하나를 시도해볼 수 있습니다.
부팅 중에 C 키를 눌러 부팅 메뉴에 접근한 후, "repair" 옵션을 선택하고 "rebuild"를 클릭하여 부팅 파티션을 다시 만들어 볼 수 있습니다.
Synology NAS를 셧다운하고 전원을 뽑은 후, 전원을 다시 연결하고 NAS를 켜 보세요.
mknod 명령어를 사용하여 /dev/synoboot 장치를 수동으로 생성할 수 있습니다. 다음 명령어를 사용해보세요.
sudo mknod /dev/synoboot b 8 1
위 명령어는 블록 장치(b)를 생성하고, 주 번호(8)와 부 번호(1)를 사용하여 /dev/synoboot 장치를 생성합니다. 이 방법은 Synology NAS에서 사용하는 리눅스 커널 버전 및 디바이스 파일 시스템에 따라 달라질 수 있습니다. 따라서, 이 방법이 실패할 수도 있습니다. 이 방법을 시도하기 전에 먼저 다른 방법들을 시도해보세요.
결국 6.1로 원복을 했는데요...
다시한번 도전하게 해주셔서 감사드립니다.? ^^
늦은밤까지 수고가 많으십니다. 추천해요 !!!!!
내장 보드 SATA 포트에 물리니 마이그레이션도 그냥 되는군요.
일단 시험결과가 더 많이 필요합니다.
55% 케이스에 걸리신 분들 많이 시험 부탁드립니다.
감사 드립니다.
boot-wait.sh 가 실행되는 시점이
웹브라우져로 접속해서 디스크 인식 메시지 이후 인가요?
화면에 동그란 것이 진행율이 0% 부터 시계 방향으로 100%
으로 채워질때 55% 에서 파일 손상 메시지가 나오는 것인가요?
m shell 에서 선택메뉴가 나오기전에 wait 메시지가 나오는 시점을 말하시는 것인가요?
궁금하신 사항은 junior 모드 (DSM 설치단계) 에서 ping 이 오는 시점에서 웹 브라우저로 아래처럼 접속하시면 TTYD 모드 진입이 가능합니다.
http://IP주소::7681
여기서 궁금하신점들이 많이 확인이 되실겁니다.
주요 로그는 /var/log 하위에 모여있고 제가 계속 모니터링 하는 로그는
/var/log/linuxrc.syno.log 입니다.
첫번째 댓글에도 그 내용을 적어드린겁니다.
boot-wait 를 포함한 각종 리눅스 드라이버는 /exts 에 모여있습니다.
그안에 루트에 있는 ./exec.sh 이 모든 드라이버를 부팅시작하자마자 알파벳순서로 로딩이 들어갑니다.
boot-wait 도 그중하나 입니다.
2번째 질문은 YES / 3 번째 마지막 질문은 NO 입니다.
알려진 이유중 하나는
USB 메모리의 VID / PID 가 잘못 이라면
USB 메모리 벤더 마다 차이가 있을 수 도 있을까요?
저는 샌디스크 usb메모리를 두개 버렸어요
m shell 에서 빌드후 갑자기 이상 증상이 나와서
다시 이미지를 write 하려고
빼서 파티션을 삭제하면 파티션 삭제가 안되고
raw disk으로만 인식이 되더군요
삼성 usb 메모리를 구입해서 사용하는데
갑자기 이상 증상이 발생해도 파티션은 삭제되고
raw disk로 남지는 않습니다
하지만 이미지를 write 하거나 이 usb를 꼽으면
윈도우 창이 차례로 3개가 나오고
usb 디스크가 3개가 생기는데요,
저런 증상이 한번 발생하면 usb에 이미지를 write 해도
usb disk는 하나만 나타납니다.
이때 파티션 정보를 보면 3개 파티션이 있고
헤놀 기기에 삽입해서 부팅하면 m shell 진행 되고
빌드후 리부팅 이후 DSM 설치 화면 전환도 정상적으로
진행됩니다.
USB가 새것일때는 3개 usb disk 로 인식이되는데
이상증상 이후로는 usb 디스크가 하나만 나타나고
파티션은 3개로 존재하면서 동작은 정상으로 보입니다
샌디스크는 구입한지 2-3년 된것이고 삼성 usb는
이번 테스트 하다가 불량된 샌디스크 usb 때문에
신규 구입한 것으로 메모리 셀이 건강해서??
파티션이 raw 로 남지 않는 것 같다는 생각이 듭니다.
파티션 테이블을 지속적으로 여러번 write 하면
동일한 위치에 계속 프로그램이 되서
파티션을 저장하는 셀이 손상되는 것 같습니다
이런 증상을 경험하신적이 있으신지요?
img 파일을 레코딩 할때는 리눅스 커맨드인 dd 로 레코딩합니다.
맥OS도 이게 가능해서 dd 를 사용해서 레코딩을 하구요.
img 파일 자체가 원래 윈도우용이 아닌 유닉스/리눅스 기반의 파일 포맷이라고 얼핏 주워들은것 같습니다.
윈도우에서 이 리눅스 포맷팅 잘 유지하면서도 안전하게 레코딩해주는 툴이 win32 disk imager 정도라고 알고 있는데,
저도 img 파일 shrink 제작을 위해서만 활용하고 자주 사용하지는 않습니다.
혹시 usb 레코딩하실 때 사용하시는 툴은 어떤것 사용하시나요?
파티션 삭제할때 에는 EaseUS Partition Master 13.5 를 이용 합니다.
USB에 이미지를 새로 레코딩 하기전에 EaseUS Partition Master 으로 파티션을 모두 삭제하고 합니다.
그리고 win32 disk imager 으로 USB에 이미지를 새로 레코딩 이후 부터는 USB 디스크가 하나만 인식 됩니다.
파티션은 3개로 존재 합니다. 그러나 TCRP ... 빌드 리부팅 과정은 정상적으로 되고는 있습니다.
새 제품의 USB으로 win32 disk imager 으로 USB에 이미지를 새로 레코딩하면 반드시 USB 드라이브 3개오 인식되면서
파일 시스템이 오류가 있다는 경고는 발생 됩니다.
빌드 리부팅 과정을 계속 반복하다가 TCRP 부팅 불가 상태가 발생하면
이때 USB를 그냥 win32 disk imager 으로 USB에 이미지를 새로 레코딩하면 오류가 발생하고
EaseUS Partition Master 으로 파티션을 모두 삭제하고 win32 disk imager 으로 USB에 이미지를 새로 레코딩하면 동작이 됩니다.
이때 부터는 USB 디스크로 하나만 인식되기 시작 합니다.
USB 디스크로 하나만 인식되는 증상이 심각한 것은 아니지만
EaseUS Partition Master 으로 파티션을 모두 삭제 때문인지 ...
TCRP 빌드 과정에서 문제가 발생 되어서 인지 ...
USB 디스크가 최초 상태와 다르게 동작하는 것이 ... 뭔가 문제가 있는 것 같습니다.
이런 증상을 일일이 스크린 캡쳐 했고 ...
질문으로 올릴 예정 입니다.
파티션을 삭제할때 ... 다른 방법이 있는지 검색하고 ,,, 테스트 중 입니다.
왜 ... TCRP 빌드 과정에서 어떤 문제가 있더라도 파티션 삭제가 완전히 초기화 하지 못하는지 이해 하기가 어렵네요...
3개로 인식되던 USB 디스크를 하나로 밖에 인식되지 않게 되는지 ...
USB 메모리를 손상 시키는 과정이 분명히 있는데 ..
새 USB를 사용하면 항상 3개 USB 디스크로 인식 되기 때문에 ...
문제가 되는 상태를 재현하는 것은 가능 한데 .. 이유를 찾지 못하겠군요...