'mdev -s' run on ramfs initialization is able to mount external media already
detected but fails to automatically mount any media detected afterwards.
Running it as a daemon first it will also be able to mount any media detected
after 'mdev -s' is run.
Use argument '-d' to first run mdev as daemon in background.
Move 2 seconds delay to after mdev has been initialized to give external
hardware all the time possible to be successfully detected and mounted.
https://onedigi.atlassian.net/browse/DEL-7285
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
This commit adds some swupdate parameter to select the sw-description
configuration depending on the used platform.
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
Instead of checking for the existence of /proc/mtd, which might lead to false
positives, check the "root" parameter in /proc/cmdline. Assume eMMC in case of
any error.
https://onedigi.atlassian.net/browse/DEL-7539
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
In the libubootenv implementation of fw_setenv, multiple variables can be set
in one call. When setting a variable with a space-separated list, the app
interprets the list as new variable/value tuples, for example:
fw_setenv myvar value1 value2 value3
Results in:
myvar=value1
value2=value3
This was causing the encrypted eMMC partition mechanism to break, because the
list of encrypted partitions is stored as a space-separated list in an
environment variable. Avoid this by enclosing the variable argument of
set_uboot_var() with double quotes.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Before using the encrypted partition functionality, users have to manually
install the encryption key in the system. Failing to install said key will
result in errors later on.
Even though the installation isn't a difficult operation from a user's point of
view, the recovery script has the necessary logic to detect cases where a
partition is going to be encrypted with no key installed. Automatically
generate a key in these cases to avoid undesired behavior and to improve the
overall user experience.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
If we allow users to manually change the encryption status of the rootfs
partition, we run the risk of wiping it without flashing a proper replacement
image. Because of this, rootfs encryption status should be determined
automatically using information from the update package.
Have the recovery script parse the update package's description to determine
whether to encrypt the rootfs or not.
https://onedigi.atlassian.net/browse/DEL-7174
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Since the update partition might be involved during a software update, we need
to make sure that its contents are accesible and safe when using the partition
encryption feature at the same time.
Mount and unmount the partition correctly if it's encrypted and cancel any
operations that will result in the deletion of the update package.
https://onedigi.atlassian.net/browse/DEL-7174https://onedigi.atlassian.net/browse/DEL-7422
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Modify the recovery and trustfence initramfs scripts to be able to encrypt any
partition on the internal storage media, not just the rootfs.
To implement this functionality, add a new recovery command called
'encrypt_partitions'. When used, this command must contain a comma-separated
list of the partitions that are to be encrypted by the end of the recovery
process, including partitions that were already encrypted beforehand. Any
partition that isn't in the list will be unencrypted. If the command is absent,
no changes will be made, but it's possible to pass an empty command to
unencrypt all partitions.
Include a blacklist to avoid encrypting partitions that shouldn't be encrypted,
such as partitions that need to be accessed by the ROM code/U-Boot or
partitions that contain encryption keys.
While at it, remove unnecessary "get_kernel_version" function from the script.
https://onedigi.atlassian.net/browse/DEL-7174
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
By default, we generate SWU files which update both the linux and rootfs
partitions. This, along with the fact that platforms using NAND as the storage
media require a reboot for the rootfs partition's "enc" flag to take effect,
makes it safe to format the NAND's rootfs partition before performing an
update, regardless of having to encrypt the rootfs or not.
However, customers that wish to use the swupdate feature to update just the
linux partition will find that the rootfs is completely erased after the update
is finished, because a new rootfs hasn't been written in its place.
To avoid this scenario, parse the SWU package's description to verify that it
contains a rootfs image before formatting the partition.
https://jira.digi.com/browse/DEL-7067
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Busybox's device manager mdev was originally meant to be set up by writing its
path to /proc/sys/kernel/hotplug before launching it, but that entry no longer
exists in Linux v5.4's procfs and mdev can be launched directly.
Since mdev is the element in the recovery initramfs that is in charge of
mounting all partitions where .swu packages can be found (update partition on
the eMMC/MTD, uSD and USB), checking for the existence of the hotplug entry in
the procfs before launching mdev in v5.4 was preventing the partitions from
being mounted, and causing all software updates to fail.
While at it, move the two second delay to before mdev is launched, so all
partitions can be mounted. Otherwise, some devices such as the USB might not
be ready when mdev is launched, causing its partition to not be mounted.
https://jira.digi.com/browse/DEL-7143
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This tool was only needed for old kernels, newer kernels use the hardware
random number generator themselves.
https://jira.digi.com/browse/DEL-5518
Signed-off-by: Jose Diaz de Grenu <Jose.DiazdeGrenu@digi.com>
Turns out that the busybox' fdisk applet is also able to parse the GPT
partition tables. This saves around 0.5 MiB of space.
https://jira.digi.com/browse/DEL-4565
Signed-off-by: Jose Diaz de Grenu <Jose.DiazdeGrenu@digi.com>
In the recovery images we are using a custom init so we are not executing
any post-installation that is required for a correct rootfs setup, so call
all the post installation scripts from our custom init.
The package installation could be ipk, rpm or deb, so call to the
*postint folder.
Given that the recovery rootfs is a ramdisk, there is no need to remove the
post installation scripts.
https://jira.digi.com/browse/DEL-4430
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
The recovery init checks if the configured update package exists and it is valid
before setting a new key and/or formatting the rootfs partition.
This change avoids getting non-booting devices after performing a firmware
update with a non-existing or invalid update package.
https://jira.digi.com/browse/DEL-3959
Signed-off-by: Tatiana Leon <tatiana.leon@digi.com>
If the volume is not found, the partition cannot be wiped since it is attached.
Remove 'update' UBI device in:
* mdev automount script if volume is not found
* recovery init script before formatting 'update' partition
https://jira.digi.com/browse/DEL-3962
Signed-off-by: Tatiana Leon <tatiana.leon@digi.com>
This commit adds mdev support into the recovery ramdisk to
mount/unmount storage devices for the firmware up tool.
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
https://jira.digi.com/browse/DEL-3692
For CC6UL, when setting a new key, an "enc" flag must be added to the rootfs in
the "mtdparts" U-Boot variable.
After that a reboot is needed, so the recovery command must be modified to
remove the encryption key and proceed with the rest of commands in the next
boot.
When updating the firmware, a format of the rootfs partition is always
performed, independently if a new encryption key has just been configured.
In case only the encryption key is being configured, we also need to reboot to
format the rootfs properly.
https://jira.digi.com/browse/DEL-3685
Signed-off-by: Tatiana Leon <tatiana.leon@digi.com>
- While trying to update the system using signed swupdate packages, the
swupdate binary requires a new parameter (-k) to specify the location
of the public key that will be used to verify the update package. At
the moment there is no way to check if a package is signed or not, so
we asume that the existence of the public key in the recovery initramfs
is enough to determine that we want to update the system using signed
packages.
https://jira.digi.com/browse/DEL-3775
Signed-off-by: David Escalona <david.escalona@digi.com>
We have seen corner cases (e.g. when the partition to format has already
some corrupted UBI metadata) where ubiformat stops and ask the user for
confirmation to do the format. We cannot have such interactivity in the
recovery ramdisk so use the '-y' argument to assume yes for all
questions.
Also use the '-q' (quiet) parameter instead of the '/dev/null'
redirections to remove command's output.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Instead of using a hardcoded path to the SWU update package, just get
the filename and search the file in the different mounted partitions
(giving priority to the internal 'update' partition over other external
media).
https://jira.digi.com/browse/DEL-3466
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
For block devices we can get the filesystem in the partition using the
'blkid' command.
This cleans up some warnings on mounting:
EXT4-fs (sda2): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (sda2): couldn't mount as ext2 due to feature incompatibilities
EXT4-fs (mmcblk0p4): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (mmcblk0p4): couldn't mount as ext2 due to feature incompatibilities
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
"i" variable in the nested loop is expanded to the absolute path
of the device, so prepending it with the ${device} results in
"/dev/sda/dev/sda1" for a 'sda1' partition.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
- Include psplash package in the recovery initramfs recipe.
- Start psplash in the recovery init.
- Add new methods to communicate with psplash from the init script.
- Show psplash progress information from the init script.
- Start progress binary to update psplash during a firmware update.
https://jira.digi.com/browse/DEL-3356
Signed-off-by: David Escalona <david.escalona@digi.com>
- Added a 5 seconds delay before mounting external disks so they have
time to be recognized in the system.
- Check if UBI volume is mounted before formatting it.
- Check if eMMC block device exists before formatting it.
Signed-off-by: David Escalona <david.escalona@digi.com>
Gonzalo Ruiz
Mike Engel
Gabriel Valcazar
Jose Diaz de Grenu
Arturo Buzarra
Isaac Hermida
Tatiana Leon
David Escalona
Javier Viguera