Fedora 20 Beta blocker bug status: fix and karma requests

Gene Czarcinski gene at czarc.net
Sun Oct 20 10:38:30 UTC 2013


On 10/19/2013 06:36 PM, Adam Williamson wrote:
> On Sat, 2013-10-19 at 09:45 -0400, Gene Czarcinski wrote:
>
>>> * https://bugzilla.redhat.com/show_bug.cgi?id=1017435 - "Anaconda uses
>>> LVM when Standard Partition is selected in text mode" (anaconda) - this
>>> bug has been verified fixed by the update
>>> https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anaconda-20.25.1-1.fc20 , but that update needs more karma to go stable. That is the build that is in TC5, so anyone who's tested TC5 and found it generally OK (no worse than previous builds) can +1 the update: please do!
>> There are two problems with this update and I have submitted patches for
>> both:
>>
>> 1. The fix for handling existing btrfs subvolumes does not work (yet),
>> small fix needed.
>>
>> 2.  The change in the way swap definitions are handled for additions to
>> fstab omits handling the case for existing noformat swap definitions on
>> both regular partitions and logical volumes.
>>
>> Without these patches or equivalent, this is definitely a blocker.
> It's not a blocker unless someone files a bug and proposes it as a
> blocker: that's how the process works. Is there a bug report? And are
> these *new* problems compared to 20.24/20.25?
That depends on how you define "new"

With 20.25.1, there is a claim that it fixes the problem identified in:
https://bugzilla.redhat.com/show_bug.cgi?id=892747
where an existing btrfs subvolume with --noformat specified is ignored 
rather than being added to fstab.  The problem is that it is not fixed.  
I have attached a tested patch to correct this to the bugzilla report.

Before 20.25.1, if you had an existing swap on a regular partition or a 
logical volume and you specified --noformat, that swap specification was 
added to fstab.  With 20.25.1, this is no longer the case and you wind 
up with no swap at all.  You might want to not reformat that swap 
because you are using UUID and you have another system (multiboot) also 
using that swap and refering to it also by UUID.  This problem is 
reported by:
https://bugzilla.redhat.com/show_bug.cgi?id=1020867
Again, I have attached a tested patch to correct the problem to the 
bugzilla report.

This swap problem was introduced by changes made in 20.25.1.

Gene


More information about the devel mailing list