이는 Yocto 자체의 문제가 아니라 Avenger96(STM32MP1) 보드에서 Linux를 올바르게 부팅하는 데 문제가 있을 수 있습니다. 저는 현재 Yocto(Dunfell)와 함께 Avenger96을 작업하고 있습니다. 목적은 SWUpdate OTA 업데이트 시스템을 구현하는 것입니다. 이를 위해 저는 A/B 전략을 사용합니다. 나는 또한 systemd대신 을 사용 하고 있습니다 sysVinit.conf/local.conf
DISTRO_FEATURES_append = " systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
내 .wks파일은 다음과 같습니다.
part fsbl1 --source rawcopy --sourceparams="file=u-boot-spl.stm32" --part-name "fsbl1" --ondisk mmcblk --align 1 --size 256k
part fsbl2 --source rawcopy --sourceparams="file=u-boot-spl.stm32" --part-name "fsbl2" --ondisk mmcblk --align 1 --size 256k
part ssbl --source rawcopy --sourceparams="file=u-boot.itb" --part-name "ssbl" --ondisk mmcblk --align 1 --size 2M
part / --source rootfs --ondisk mmcblk0 --fstype=ext4 --label root_A --part-name "rootfs_A" --align 4096 --use-uuid --active --size 3G
part / --source rootfs --ondisk mmcblk0 --fstype=ext4 --label root_B --part-name "rootfs_B" --align 4096 --use-uuid --size 3G
bootloader --ptable gpt
이미지를 생성하고 SD 카드에 복사할 수 있습니다. 하지만 시작 시 다음과 같은 문제/오류가 발생합니다.
[ OK ] Started D-Bus System Message Bus.
Starting Load/Save RF Kill Switch Status...
You are in rescue mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Press Enter for maintenance
(or press Control-D to continue):
"Ctrl+D"를 누르면 다음을 얻습니다.
Reloading system manager configuration
[ 1306.916497] systemd-fstab-generator[202]: Mount point fsbl1 is not a valid path, ignoring.
[ 1306.940236] systemd-fstab-generator[202]: Mount point fsbl2 is not a valid path, ignoring.
[ 1306.947455] systemd-fstab-generator[202]: Mount point ssbl is not a valid path, ignoring.
Starting default target
.
.
그런 다음 로그인을 요청하고 "root"로 로그인할 수 있습니다. 왜 비상 모드나 복구 모드로 전환되는지 이해가 되지 않습니다. Google에서 나는 그것이 일반적으로 /etc/fstab과 관련되어 있음을 발견했습니다. /etc/fstab/의 내용은 다음과 같습니다(보드에서 복사).
# stock fstab - you probably want to override this with a machine specific one
/dev/root / auto defaults 1 1
proc /proc proc defaults 0 0
devpts /dev/pts devpts mode=0620,ptmxmode=0666,gid=5 0 0
tmpfs /run tmpfs mode=0755,nodev,nosuid,strictatime 0 0
tmpfs /var/volatile tmpfs defaults 0 0
# uncomment this if your device has a SD/MMC/Transflash slot
#/dev/mmcblk0p1 /media/card auto defaults,sync,noauto 0 0
/dev/mmcblkp1 fsbl1 vfat defaults 0 0
/dev/mmcblkp2 fsbl2 vfat defaults 0 0
/dev/mmcblkp3 ssbl vfat defaults 0 0
질문 하나 더: 긴급/구조 모드에서 소프트웨어 업데이트를 수행하면 어떻게 되나요? 제 경우에는 SWUpdate를 사용하여 업데이트를 설치할 수 있었지만 재부팅 후 시스템이 이전 파티션에서 다시 부팅되었습니다. 하지만 수동으로 최신 파티션으로 전환하여 u-boot env새 이미지가 설치되었는지 확인할 수 있습니다. 따라서 저는 이 동작이 다시 u-boot의 일부 문제와 관련이 있다고 가정합니다(새로 설정된 환경이 다음 부팅 시 지워질 수도 있음). 또한 fw_printenv/fw_setenvu-boot 환경에서 파티션 액세스, 설정 및 변경 과 같은 다른 작업도 수행할 수 있습니다 .bootlimit
a가 사용되고 있는 것을 발견 boot.scr하고 이를 스크립트에 설정했습니다. rootfspartu-boot 헤더 파일에는 다음과 같습니다."rootfspart=4\0" \
setenv bootargs "${bootargs} root=/dev/mmcblk0p${rootfspart} rdinit=/bin/kinit rw rootwait single"
여기에 어떤 잠재적인 문제가 있는지 말해 줄 수 있는 사람이 있나요? 연구 방향에 대한 제안이 있으면 도움이 될 것입니다.
귀하의 도움에 크게 감사하겠습니다.
미리 감사드립니다.
추신: 누락된 정보가 있으면 알려주세요. 그리고 로그인 후 확인해 보면 및 journalctl -xb만 찾을 수 있습니다 . 하지만 어쩌면 여기에 뭔가 빠졌을 수도 있습니다.Alternate GPT is invalid, using primary GPT.GPT: Use GNU Parted to correct GPT errors.