fix lvm extension and fs-cryptroot extension

[swissiety]

Description

The lvm.sh extension failed as it was refering to the root filesystem in ${LOOP}p${rootpart} - which does not live there when the lvm extension is enabled. The lvm extension replaces the contents of $rootdevice (defined in partitioning:280) with a reference to the device mapper, but in partitioning.sh:303 the $rootdevice was not used so it failed.

stacktrace

--> (500) ERROR: Error  2 occurred in SUBSHELL [ SUBSHELL at /armbian/lib/functions/image/partitioning.sh:303 ]
--> (500) TRAP: main_trap_handler [ ERR and 2 trap_manager_error_handled:0 short_stack:/armbian/lib/functions/image/partitioning.sh:303 ]
--> (500) ERROR: Error 2 occurred in main shell [ at /armbian/lib/functions/image/partitioning.sh:303
                prepare_partitions() --> lib/functions/image/partitioning.sh:303
                   do_with_logging() --> lib/functions/logging/section-logging.sh:81
            build_rootfs_and_image() --> lib/functions/main/rootfs-image.sh:86
      full_build_packages_rootfs_and_image() --> lib/functions/main/default-build.sh:36
             do_with_default_build() --> lib/functions/main/default-build.sh:42
            cli_standard_build_run() --> lib/functions/cli/cli-build.sh:25
           armbian_cli_run_command() --> lib/functions/cli/utils-cli.sh:136
                    cli_entrypoint() --> lib/functions/cli/entrypoint.sh:176
                              main() --> compile.sh:50

(2nd commit)
While working on that Issue I stumbled over leftovers from a/the previous executions and had to remove the lvm volume group + loopdevices manually so I added a cleanup handler to the extension in case of errors.

In the meantime i.e. revelations/discoveries while creating this PR:
Seems this is a regression bug as this line of code was already adapted in #7217
But reintroduced in 8175192 while fixing the fs-cryptroot extension (from the commit naming - as I stumbled over the messed up UUID myself multiple weeks ago and it was working after git pull this seems reasonable)

And it seems this https://armbian.atlassian.net/browse/AR-2489 can be closed afterwards?

I will try to make both extensions work as they seem to interfere with each other.

• just lvm
• just fs-cryptroot
• both

To do that I introduced another variable $physical_root_part_uuid which gets its value from $physical_root_device which can point to the same content as $root_device but e.g. in lvm, fs-cryptroot rootdevice gets replaced, while e.g. in /etc/crypttab the UUID of the physical partition is needed and not the one of the mapper.

How Has This Been Tested?

only lvm

• build firmware ./compile.sh BOARD=rock-3a RELEASE=bookworm BRANCH=vendor DEB_COMPRESS=xz KERNEL_CONFIGURE=no KERNEL_GIT=shallow BUILD_DESKTOP=no BUILD_MINIMAL=no ENABLE_EXTENSIONS="lvm"
• test firmware (on radxa rock 3a): ssh login and firstrun script

cryptroot

• build firmware ./compile.sh BOARD=rock-3a RELEASE=bookworm BRANCH=vendor DEB_COMPRESS=xz KERNEL_CONFIGURE=no KERNEL_GIT=shallow BUILD_DESKTOP=no BUILD_MINIMAL=no CRYPTROOT_ENABLE=yes CRYPTROOT_PASSPHRASE=1234 ENABLE_EXTENSIONS=""
• test firmware (on radxa rock 3a): login into ssh to enter encrypt phrase and to login as root

lvm+cryptroot

• build firmware ./compile.sh BOARD=rock-3a RELEASE=bookworm BRANCH=vendor DEB_COMPRESS=xz KERNEL_CONFIGURE=no KERNEL_GIT=shallow BUILD_DESKTOP=no BUILD_MINIMAL=no CRYPTROOT_ENABLE=yes CRYPTROOT_PASSPHRASE=1234 ENABLE_EXTENSIONS="lvm"
• test firmware (on radxa rock 3a): login into ssh to enter encrypt phrase and to login as root

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings