Add new dmsquash-live-autooverlay module

[iammattcoleman]

This pull request introduces a new module that creates a partition for overlayfs usage in the free space on the root filesystem's parent block device.

Ubuntu 20.04 (the main branch) and Fedora 36 (the fedora-36 branch) Kiwi image descriptions that produce ISO images that demonstrate this feature are available in this repository:
https://github.com/iammattcoleman/overlay-test

Checklist

• I have tested it locally
• I have reviewed and updated any documentation if relevant
• I am providing new code and test(s) for it

[Conan-Kudo]

This looks great! I've approved the test run as you're a first-time contributor.

[iammattcoleman]

Shell linting failed due to a couple instances of missing double quotes.

[Conan-Kudo]

I will run this once the Fedora datacenter maintenance window is over.

[Conan-Kudo]

Unfortunately, we're stuck in a catch-22, and while I can verify the failing test passes locally when I build the container and use it locally, it won't fix itself in here until after we merge it.

Otherwise, this looks good to merge. Thanks!

[LaszloGombos]

This line seems repeat from https://github.com/dracutdevs/dracut/blob/master/modules.d/90dmsquash-live/dmsquash-live-root.sh#L21

Can we avoid repeating and risking making the two modules out of sync for the default value with later PRs ?

[iammattcoleman]

This script must run before dmsquash-live-root.sh in order to work properly and this script won't always run since it's an optional module that complements 90dmsquash-live. So, both scripts will need a similar line, but it would be nice to have the constant ("LiveOS") in a single location.

Can you point me to some code that demonstrates sharing a constant between two related modules so I can follow the project's existing conventions?

[LaszloGombos]

To share a constant, we would need to introduce a shared file between dmsquash-live and dmsquash-live-autooverlay. I think it make sense to limit making changes in other modules as part of this module introduction PR, so perhaps we can do this refactoring as a follow-up PR.

[LaszloGombos]

Would it make sense to reuse devnames from 99base/dracut-lib.sh here ?
crypt and fs-lib modules need similar functionality and we call into devnames in those modules.

[iammattcoleman]

The approach I took was to gather all the data necessary to perform the task before making any destructive changes to the disk. That way it can avoid doing anything if it doesn't have all the information it needs.

devnames provides device names within /dev. This is gathering the root device's label and UUID for use in the createFilesystem() function on line 105, which creates a directory with a name that matches the default path format defined in dmsquash-live-root.sh. So, that's potentially another constant that should be shared between the two modules from a single place.

[LaszloGombos]

Some review comments to better align with existing modules..

[LaszloGombos]

Unfortunately, we're stuck in a catch-22, and while I can verify the failing test passes locally

I find it a better option to just run the job under your personal github fork e.g. https://github.com/iammattcoleman/dracut/actions/workflows/manualtest.yml and post the log of at least one successful run. You might need to trigger container creation first manually under your personal github before triggering the manual test run.

[LaszloGombos]

Changes all look good to me, but perhaps the module is not yet complete, see additional comments.

Also if you have a chance, can you please also update the Gentoo container and add parted ?

[LaszloGombos]

LGTM, thanks for the timely interactions.

[iammattcoleman]

As I mentioned in the Matrix channel, please hold off on merging this: as @LaszloGombos's suggested, I ran the manual test in my fork and it failed:
https://github.com/iammattcoleman/dracut/actions/runs/3193095857/jobs/5211306428

While working on this, I was testing on bare metal (well, really a VM) and successfully running the test from within the TEST-16-DMSQUASH directory. I had not tried running the test from within the tests directory like the manual test GitHub Action.

After I saw the test fail in my fork, I reproduced it in a podman container locally. If I run make V=1 TESTS=16 clean check within /dracut/tests/, it fails. If I run make clean setup run within /dracut/tests/TEST-16-DMSQUASH/, it succeeds.