현장 업데이트를위한 권장 기술 임베디드 리눅스를 안전하게 업데이트합니다

Question

내장 된 Linux 기반 장치에는 종종 응용 프로그램 및 시스템 파일을 업데이트하는 메커니즘이 필요합니다. 예를 들어, USB 포트가있는 (네트워크가없는) 실험실 악기는 USB 스틱에서 소프트웨어 업데이트를 얻을 수 있습니다.

장치의 내부 플래시 메모리에 파일을 제자리에 복사하는 스크립트를 실행하는 것은 간단한 문제입니다. 그러나 장치가 업데이트 중간에 전력을 잃고 벽돌이 발생할 위험이 있습니다.

응용 프로그램 파일의 상황은 응용 프로그램 디렉토리를 복제하고 하나의 사본을 업데이트하고 실패 창을 최소화하는 이전 및 새 디렉토리를 신속하게 교체 할 공간이 있기 때문에 약간 쉽습니다.

파일 시스템 전체에 퍼져 있기 때문에 커널 및 시스템 파일에 대한 상황이 더욱 맛있습니다.

우리는 파일 시스템에서 하드 및 소프트 링크를 사용하여 중요한 파일을 식별했습니다. 파일 및 아카이브에서 해시를 사용하여 파일 무결성을 확인합니다. 업데이트 된 파일 시스템에서 시작하는 경우 폴백을 제공하기 위해 커널에 비상 RAMF를 사용하는 것을 고려했습니다.

이 요구 사항에 대한 귀하의 접근 방식은 무엇입니까?

Answer 1

응용 프로그램 파일과 동일한 접근 방식으로 이동합니다. 중요한 파일을 만들고 자체 파티션을 완료하고 링크하고 파티션을 복제합니다. 모든 Init에서는 링크가 동일한 파티션에 모두 표시되는지 확인해야합니다. 그렇지 않은 경우 (특정 파일의 최신 날짜가있는 파일과 파티션) 재설정하는지 확인해야합니다. 업데이트하려면 모든 것을 새 파티션에 복사하고 모든 것이 정상이면 파일 위로 (CRCS OK) 루프를하고 각 링크를 한 파일 시스템에서 다른 파일로 설정하십시오.

이렇게하면 중요한 파일은 항상 제정신 상태에 있어야합니다.

시나리오 :

1. 새 파티션에 파일을 복사하는 동안 업데이트가 실패합니다

   링크가 오래된 작업자에게 여전히 표시되기 때문에 문제 없습니다.

2. 연결 중에 업데이트가 실패합니다

   모든 새 파일이 유효하고 이미 복사 되었기 때문에 문제 없음 (그렇지 않으면 Relink 단계가 시작되지 않았습니다)

Answer 2

신뢰성을 보장 해야하는 경우 현재 작동하는 구성과 하나는 새로운 구성이있는 두 개의 플래시 파티션 (또는 칩)을 가질 수 있습니다. 그런 다음 장치를 재설정하고 활성 부트 플래시 파티션을 "마지막으로 알려진 좋은"구성으로 전환하는 하드웨어 워치 독을 사용하십시오.

Answer 3

적어도 두 개의 파티션이 있습니다. 나는 4를 제안 할 것이다

• 신병

• 대체 부팅

• 프로그램 데이터 백업

• 프로그램 휘발성 데이터

Boot가 실패한 경우 Grub Fallback Booting을 사용하여 Boot Boot를 대체하십시오.

따라서 업데이트가 실패하면 대체가 작동합니다.

부트 로더를 업데이트하지 마십시오.

데이터 파티션이 토스트 된 경우 백업 데이터 파티션을 통해 개혁 및 복사하십시오.

이제 플래시 디스크가 죽지 않으면 실패 할 수 없습니다. COTS 하드웨어를 사용하고 있으며 메인 디스크가 소형 플래시라고 말하면 작은 USB 키에 물리적으로 격리 된 백업을 가질 수 있습니다.

Answer 4

IMHO 원자가 아닌 업데이트는 시스템을 깨뜨 리거나 일관성을 확인할 수 있습니다. Boot Loader를 업데이트하는 것은 전원 끄기 안전하지 않기 때문에 피해야한다는 데 동의합니다. 일반적으로 제조업체는 커널 및/또는 단일 파일이 업데이트 된 경우 펌웨어 XXX에서 버전 YYY로 업데이트를 원합니다. 단일 파일을 업데이트하는 것은 고객의 하드웨어에서 실행중인 내용을 이해하기가 매우 어렵 기 때문에 서비스의 악몽이 될 수 있습니다. 어쩌면 듀얼 카피 접근법 (애플리케이션은 중복됩니다)과 단일 코피 접근 방식을 혼합하고있을 수 있습니다. 시스템의 무결성은 체인의 약한 구성 요소에 의해 수행되기 때문에 이것이 많은 도움이되지 않는다고 생각합니다. 루트 파일 시스템의 업데이트가 실패하면 응용 프로그램이 복제되는 것이 중요하지 않습니다.

이중 복사 접근 방식은 필요한 경우 서비스를 중단하지 않고 업데이트를 보장 할 수 있습니다. 그러나 모든 구성 요소가 복제되어야하기 때문에 많은 리소스가 필요합니다. 개인적으로, 나는 기본 응용 프로그램이 실패하거나 마지막 업데이트가 성공하지 못한 경우 RAM의 작은 루프가 시작되는 폴백 접근법을 사용합니다. 부트 로더에 의해 자동으로 시작된이 폴백 시스템은 잘못된 문제가 발생하면 USB 펜에서 시스템을 업데이트하십시오 (로컬 업데이트가 필요한 경우).

나는 이러한 문제에 대한 OSS 프로젝트를 찾지 못했고 최근의 경험을 바탕으로 최근에 새로운 프로젝트를 시작했습니다. 몇 가지 제품을 실행하고 있으며 고객이 만족합니다.

어쩌면 당신은 그것을 볼 수 있습니다. "Swupdate"(프로젝트 이름)의 출처를 찾을 수 있습니다. github.com/sbabic/swupdate.

스테파노

Answer 5

여기서 달성하려는 것은 업데이트 프로세스의 원자력이라고 생각합니다. 원자력은 임베디드 장치에 중요하며 강조된 이유 중 하나는 전력 손실입니다. 그러나 하드웨어/네트워크 문제와 같은 다른 사람들이있을 수 있습니다. 업데이트의 맥락에서 원자력에 사용하는 정의는 다음과 같습니다.

• 업데이트는 항상 완전히 완료되거나 전혀 완료되지 않습니다.
• 업데이터 외에도 절반 설치된 업데이트를 보는 것 외에는 소프트웨어 구성 요소가 없습니다.

임베디드 리눅스의 경우 업데이트하려는 몇 가지 소프트웨어 구성 요소와 다른 디자인을 선택할 수 있습니다. 여기에 논문이 있습니다. https://mender.io/user/pages/04.resources/_white-papers/software%20updates.pdf