Handle btrfs root subvolume for fedora extract-image

This adds a check for the root device having filesystem type btrfs,
and when it is assume there is a subvolume called "root". This fixes
extract-image when using Fedora-Cloud-Base btrfs images.

This should be sufficient until there is another btrfs base image with
a different subvolume layout.

Change-Id: Ib18979090585ba92566e523951b521b9d902fcb7
This commit is contained in:
Steve Baker 2022-03-11 15:48:03 +13:00
parent e78159cd44
commit 7de5bc6fa3

View File

@ -131,7 +131,8 @@ function extract_image() {
done done
mkdir $WORKING/mnt mkdir $WORKING/mnt
if [ "xfs" = "$(sudo blkid -o value -s TYPE $ROOT_LOOPDEV)" ]; then ROOT_FSTYPE=$(sudo blkid -o value -s TYPE $ROOT_LOOPDEV)
if [ "xfs" = "$ROOT_FSTYPE" ]; then
# mount xfs with nouuid, just in case that uuid is already mounted # mount xfs with nouuid, just in case that uuid is already mounted
# use ro to avoid/workaround xfs uuid issues on older # use ro to avoid/workaround xfs uuid issues on older
# kernels with newer rhel images which seem to set # kernels with newer rhel images which seem to set
@ -139,6 +140,12 @@ function extract_image() {
# xfs superblock has incompatible features (0x4) # xfs superblock has incompatible features (0x4)
# we don't need to worry about this, we just want the data # we don't need to worry about this, we just want the data
MOUNTOPTS="-o nouuid,ro" MOUNTOPTS="-o nouuid,ro"
elif [ "btrfs" = "$ROOT_FSTYPE" ]; then
# Fedora has a btrfs filesystem with a subvolume called root.
# For now assume there will be a 'root' subvolume, but in the
# future the subvolume layout may need to be discovered for different
# images
MOUNTOPTS="-o subvol=root"
else else
MOUNTOPTS="" MOUNTOPTS=""
fi fi