Add support for resizing BTRFS based images#194
Conversation
The assumption that all SBC images use ext[234] seems a bit overly simplistic. This adds a simple check to make sure we are actually dealing with an extN filesystem before running fsck against it. Next it adds an attempt to handle BTRFS file systems. This is a bit challenging since BTRFS needs to be online in order to be resized (how odd is that?) and it seemed that mounting the filesystem at times failed for strange reasons - which resulted in the hacky code that attempts to unmount the loop device (even though it clearly isn't mounted) and listing the content of the freshly created temporary mount point. This seems pointless, but with those two lines in place I no longer got the mount failures. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Seems rather odd, but I encounter this eith an OrangePi5 image. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
Hey @dirkhh thanks for your contribution! @dirkhh if you want you can also PR an entry for adsb-feeder-image to: https://github.com/guysoft/CustomPiOS#list-of-distributions-using-custompios |
|
@guysoft thx for the ping. We will test it, as soon as possible. |
|
Heads up, looks like file is now a dependency due to this change |
|
Here is a test of these changes. It fails dring resizing the final image. Maybe we could add something to BASE Module to skip resizing? |
|
The PR should support resizing AFAIK. see: The line (and functions) that need to be fixed are: @dirkhh are you using these functions or did you do some change so your images build? Error for reference from that build (they get deleted): |
Yes I do. |
|
How do I skip it then? I have to resize it on build start, but func |
|
BTRFS works now but does not resize correctly |
The assumption that all SBC images use ext[234] seems a bit overly simplistic. This adds a simple check to make sure we are actually dealing with an extN filesystem before running fsck against it.
Next it adds an attempt to handle BTRFS file systems. This is a bit challenging since BTRFS needs to be online in order to be resized (how odd is that?) and it seemed that mounting the filesystem at times failed for strange reasons - which resulted in the hacky code that attempts to unmount the loop device (even though it clearly isn't mounted) and listing the content of the freshly created temporary mount point. This seems pointless, but with those two lines in place I no longer got the mount failures.