Fix installer to work with the OnLogic FR201 device #4543
Conversation
Fix the test command argument to check for directories '-d' instead of
regular file ('-e').
Signed-off-by: Renê de Souza Pinto <rene@renesp.com.br>
The installer script (within the installer container) look for EFI files under /parts/boot. Currently this directory it's not being populated at all, so the installer script will just create a link for the files from u-boot container (mounted at /uboot/boot). For default installations there is no issues on this behavior. However, for the OnLogic FR201 device, the workflow to produce an installer image is the following: 1. Create the installer raw image 2. Flash the installer image to an USB Stick 3. Change the config.txt file of the EFI partition in the USB Stick to enable the options for the FR201 device 4. Boot the USB Stick into the device For this particular case, the config.txt from the EFI partition of the USB Stick (installer device) must be copied to the destination EFI partition of the target storage device (eMMC or SSD). However, the default config.txt (from the u-boot container) is copied and the device is not able to boot. This commits adds a function to search for the EFI partition and copy the files to /parts/boot, so the installer script will install these files instead of the default ones from u-boot container. In this way, changes in the config.txt of the installer USB Stick will reflect in the target device. Signed-off-by: Renê de Souza Pinto <rene@renesp.com.br>
|
I keep trying to understand this and failing. Probably because the installer has some confusing logic. We cleaned some of it during the major installer rewrite, but not all of it. This isn't specifically about FR201, but a generic process that seems to say, when running an installer, if I already have an EFI partition, mount it, and copy everything in it to my target I don't understand what that does, and how it changes the flow. Doesn't that mean that we now are using the EFI files already on there? Or was the purpose of |
@deitch , what I recall (please, notice that maybe I can't be 100% correct) is that for the former installer, all the files were populated into /parts directory. When you rewrote the installer, the container didn't have access to these files anymore, so that's why the files were taken from u-boot container, see this PR #4293. This wasn't a problem so far, because for generic arm64 the EFI partition of the final image would just contain the same files provided by the u-boot container, so it didn't matter from where we were taking these files. However, with the introduction of the FR201 device support, now we use the same EFI files, but with a an additional step: EFI files will be exact the same for RPi 4B and for the FR201. However, we need additional configuration that must be enabled in the config.txt for the FR201. For live images that's not a big deal, users flashes the image into an SD-Card, USB, etc, just mount the EFI partition and edit the config.txt. Unfortunately, this cannot be easily done when you install EVE into the internal storage, like eMMC or SSD device. So the installer must take the files from the EFI partition of the installer device, in this way it can get the "correct" config.txt for the FR201 device. For any other device, it doesn't change the behavior, because the files will be exact the same from the u-boot container. TBH, for me "the /parts stuff" is a legacy from the old installer, we can cleanup when convenient, for now, I would like to unblock the installation image for this device.... |
| @@ -336,8 +336,8 @@ ln -s /bits/* ${ARTIFACTS_DIR} 2>/dev/null | |||
| # and now a few measures of last resort - make sure the ${ARTIFACTS_DIR}/* we need exist, or else | |||
| # symlink to the root filesystem | |||
| [ -e ${ROOTFS_IMG} ] || { echo "ERROR: no rootfs.img found"; exit 1; } | |||
| [ -e ${EFI_DIR} ] || ln -s /root/EFI ${EFI_DIR} | |||
| [ -e ${BOOT_DIR} ] || ln -s /uboot/boot ${BOOT_DIR} | |||
| [ -d ${EFI_DIR} ] || ln -s /root/EFI ${EFI_DIR} | |||
There was a problem hiding this comment.
So, before the fix, were the links being created regardless of whether the directory already existed? How did that even work then? oO
There was a problem hiding this comment.
Exactly @OhmSpectator , in this case it was working because the directories didn't exist...
Overview
This PR provides two changes in the installer script: one small fix and an additional functional to make installer work with the OnLogic FR201 device.
Commits
installer: Copy bootloader files from the installer device EFI partition
The installer script (within the installer container) look for EFI files under /parts/boot. Currently this directory it's not being populated at all, so the installer script will just create a link for the files from u-boot container (mounted at /uboot/boot). For default installations there is no issues on this behavior. However, for the OnLogic FR201 device, the workflow to produce an installer image is the following:
For this particular case, the config.txt from the EFI partition of the USB Stick (installer device) must be copied to the destination EFI partition of the target storage device (eMMC or SSD). However, the default config.txt (from the u-boot container) is copied and the device is not able to boot.
This commits adds a function to search for the EFI partition and copy the files to /parts/boot, so the installer script will install these files instead of the default ones from u-boot container. In this way, changes in the config.txt of the installer USB Stick will reflect in the target device.
installer: Fix directory checking
Fix the test command argument to check for directories
-dinstead of regular file (-e).