| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implementation follows 'doc/filesystem-layout.md':
Elevator update writes the testing new OS_PREFIX into `/boot/config.txt`
and writes the previous into `/boot/sys_last` as a fallback.
* If 'ROOT' != 'file', perform normal boot operations (the 'root' cmdline.txt argument)
* If `/boot/sys_last` exists, loop_rootfs will
** If '/boot/sys_cntr' doesn't exist, create it with value '1': Boot the new update.
** If '/boot/sys_cntr' exist and holds value <= 0, increment it: Boot the new update.
** Otherwise: Fallback to `/boot/sys_last`
The fallback has been simplified to:
* copy '/boot/config.txt' -> '/boot/config.bak'
* copy '/boot/<sys_fallback>/config.txt' -> '/boot/config.txt'
In any case where the `rootfs.img` check fails,
a fallback escalation will be used:
* `/boot/sys_last` if exists, i.e. pre-update system
* `sys_arm64_000` factory default, i.e. the last resort
The following 'rootfs.img' checks are performed:
* file exists
* filesystem type known
* 'fsck -V -t fstype rootfs.img'
The following '/boot' partition check is performed
```
while ! fsck -f -y -V -t vfat "${BOOT_PART}"; do
panic "The vfat filesystem on ${BOOT_PART} requires a manual fsck"
done
```
Whenever a system has been booted,
it shall determine whether it is working.
If working, it shall remove the files (if exists):
* `/boot/sys_last`
* '/boot/sys_cntr'
Now the new system has been accepted.
Otherwise the system shall reboot.
In case the system is frozen and broken,
the user shall reset the system
which will cause aforementioned fallback procedure.
Manual testing on developer machine performed with 'stage2/01-sys-tweaks/files/initramfs/test/loop_rootfs_test'.
|
