Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix lvm extension and fs-cryptroot extension #7527

Merged
merged 3 commits into from
Dec 13, 2024

Conversation

swissiety
Copy link
Contributor

@swissiety swissiety commented Nov 29, 2024

Description (hint: further down is a TLDR)

The lvm extension replaces the value of $rootdevice (defined in partitioning:280) with a reference to the device mapper to the rootfs partition on lvm, but in partitioning.sh:303 - where the uuid of the filesystem which contains the rootfs is needed, ${LOOP}p2 was used (instead of $rootdevice), so blkid could not find the UUID and the script 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

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)

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

  • just lvm
  • just fs-cryptroot
  • both

TLDR: report: fixing lvm + cryptroot

  1. goal: both extensions should work independently
    context: With the merge of the fs-cryptroot extension fix about 3 weeks ago the lvm extension broke as they both "shared" the rootdevice variable which resulted in a wrong UUID assigned to crypttab/lvm.
    solution: adding another variable to keep track of the "actual"/outmost/first/.. root partition.
  2. goal: LVM over LUKS
    solution: moved loop device creation logic for ${SDCARD}.raw from lvm.post_create_partitions into the default behaviour, if no LOOP device is set by an extension via post_create_partitions hook. This enabled the lvm extension to accept a different device than only the device pointing to ${SDCARD}.raw - e.g. a device mapper from fs-cryptroot ->
  3. goal: cleanup ghost devices after a (failed) build
    added cleanup handlers to both extensions to cleanup volume groups/close LUKS in case of an error (as manually removing leftovers was a bit tedious ;-)) - reduced hardcoded cryptroot extension cleanup code.
  4. goal: improved key name that matches its image filename
    solution: move export into a hook to use the same naming scheme as for .img for the exported private key.

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

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

bare

  • 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
  • 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

@github-actions github-actions bot added size/small PR with less then 50 lines Needs review Seeking for review Framework Framework components labels Nov 29, 2024
@swissiety swissiety force-pushed the swissiety/fix_lvm_extension branch from c24567d to 8cf5289 Compare December 4, 2024 22:42
@github-actions github-actions bot added size/medium PR with more then 50 and less then 250 lines and removed size/small PR with less then 50 lines labels Dec 4, 2024
@swissiety swissiety force-pushed the swissiety/fix_lvm_extension branch from 8cf5289 to c60d751 Compare December 5, 2024 21:22
@swissiety swissiety force-pushed the swissiety/fix_lvm_extension branch from c60d751 to e5280ab Compare December 5, 2024 21:28
@swissiety swissiety marked this pull request as ready for review December 5, 2024 21:30
@swissiety swissiety requested review from a team and igorpecovnik as code owners December 5, 2024 21:30
@igorpecovnik
Copy link
Member

Thank you for looking into this. Can you check if documentation needs updating?
https://docs.armbian.com/Developer-Guide_Build-Switches/

Copy link
Member

@igorpecovnik igorpecovnik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@igorpecovnik igorpecovnik added Ready to merge Reviewed, tested and ready for merge 02 Milestone: First quarter release and removed Needs review Seeking for review labels Dec 13, 2024
@igorpecovnik igorpecovnik merged commit 6607728 into armbian:main Dec 13, 2024
@igorpecovnik
Copy link
Member

It seems this method worsen loop device management:
https://paste.armbian.de/owokeretox
https://github.com/armbian/os/actions/runs/12312659392

@igorpecovnik
Copy link
Member

igorpecovnik commented Dec 18, 2024

Did you perhaps had time to inspect this deeper? We have troubles making daily images after this PR. Loop management was IIRC pain since ever while this change made it a lot more unstable https://paste.armbian.de/ikiduqifum

@swissiety
Copy link
Contributor Author

That's annoying - maybe I have a hunch. I will have a look at it in my lunch break.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
02 Milestone: First quarter release Framework Framework components Ready to merge Reviewed, tested and ready for merge size/medium PR with more then 50 and less then 250 lines
Development

Successfully merging this pull request may close these issues.

2 participants