You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix Aboot breakage in sonic package manager in sonic-installer (sonic-net#1625)
> Failure cause
The `get_rootfs_path` contextmanager was repurposed to implement
`get_file_in_image` and later used as a function by leveraging some
python complexity to bypass the restrictions coming with the
contextmanager which were added purposefuly.
It was then called multiple times to compute paths though a simple
path join using `new_image_dir` could have been performed.
The `get_rootfs_path` implementation for Aboot behaved differently
when a rootfs was extracted or kept within the SWI image. It also
behaved differently on secureboot systems.
The updated method was then called on non-existing files for which
the method was never meant to process.
> Context around the failure
Over time, the installation and boot process has slightly diverged from
the ONIE one. There are 3 scenarios to consider.
1) Regular boot similar to ONIE
This one should just work the same as the filesystem layout is
unchanged.
2) docker_inram where dockerfs.tar.gz is extracted in tmpfs at boot
In this scenario the boot is similar to the regular one beside that
dockerfs.tar.gz is preserved intact on the flash and not extracted.
By design this does not fit the sonic-package-manager requierements and
the migration should be skipped which is what I did in this review.
In the coming month this boot mode will look closer to 3) below.
3) Secureboot on Arista devices
In this scenario the SWI image is kept intact and nothing extracted
from it. By ensuring the integrity of the SWI we can guarantee that no
code/data has been tampered with. This mode also relies on
`docker_inram` at the moment.
It could be enhanced when sonic-package-manager can guarantee the
integrity of code and data that is both installed and migrated.
> Solution provided
The method `get_file_in_image` was reverted to its original meaning
`get_rootfs_path` as there is no point in keeping the new one.
It doesn't have the necessary logic to handle more than the rootfs and
the logic can be easily be achieved by the following line.
`os.path.join(bootloader.get_image_path(binary_image_name), 'something')`
A new Bootloader method called `support_package_migration` is
introduced to allow the bootloader to skip the package migration based
on the image (docker_inram) or its own configuration (secureboot).
By default all bootloaders enable the package migration.
That change leads to 1) above running package migration while 2) and 3)
skip it.
echo_and_log("Warning: SONiC package migration is not supported currenty on aboot platform due to https://github.com/Azure/sonic-buildimage/issues/7566.", LOG_ERR, fg="red")
0 commit comments