[PATCH] add setting of the exiting subvolume UUID for fstab

Gene Czarcinski gene at czarc.net
Mon Oct 28 21:56:15 UTC 2013


On 10/28/2013 01:57 PM, David Lehman wrote:
> On Sat, 2013-10-26 at 16:13 -0400, Gene Czarcinski wrote:
>> Earlier in BTRFSData, the BTRFS volume (the parent of all
>> subvolumes) is determined and assigned to "dev".  The value of
>> dev.uuid can be used to set the uuid value for the subvolume which,
>> in turn, will then be used in fstab.
>>
>> This patch was tested as an updates img against Fedora 20 Beta TC6.
>> The current code works, this patch just makes it work a little better
>> by using the UUID.
> As I said the last time you posted a patch for this, this is not the
> place to fix it. If the subvolumes' UUIDs are not getting set up
> correctly during detection of existing storage we should fix it there --
> not here.
>
I guess I do not understand your point.  This is the place in the 
kickstart code where the mountpoint is set for the existing volume. 
However, as the code now is, when it comes time to actually create the 
fstab entry, there is no associated UUID value set so the /dev/___ value 
is used instead.  For BTRFS subvolumes, the UUID value is that of the 
parent BTRFS-volume.  The BTRFS-volume device was identified  a few 
lines earlier in this code and the value was assigned to "dev".  If you 
look a fiew lines after where my patch adds the code, you will see that 
the sixth paramter of storage.newBTRFS is parents=members which has the 
BTRFS volume devices list.

Now I probably should have coded the right side as "members[0].uuid" 
rather than "dev.uuid" but, since all devices which make up a BTRFS 
volume have the same UUID, it really does not matter.

This is the point there the parent BTRFS volume is known.  Where else 
would you have the uuid assigned for existing subvolumes  This is where 
it is assigned for new subvolumes.  Where else do you have all the right 
information so readily available?

BTW, this IS where existing subvolumes are detected as far as kickstart 
is concerned!

Gene


More information about the anaconda-patches mailing list