On Mar 2, 2014, at 1:16 PM, drago01 <drago01(a)gmail.com> wrote:
On Sun, Mar 2, 2014 at 9:12 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> On Sun, 2014-03-02 at 20:43 +0100, drago01 wrote:
>> On Sun, Mar 2, 2014 at 8:25 PM, Adam Williamson <awilliam(a)redhat.com>
wrote:
>>> On Sat, 2014-03-01 at 09:48 +0100, drago01 wrote:
>>>
>>>> As for the installation QA I don't think the
>>>> file system itself is a major source
>>>> of churn / bugs.
>>>
>>> The people who do the installation QA are the ones who are telling you
>>> differently...
>>
>> Care to provide any details? I mean I different partitions setups /
>> raid / lvm / iscsi / $somethingthatalomostnooneuses ok .. but the fs ?
>> All that anaconda has to do is call mkfs.whatever and add the proper
>> name to fstab ... unless the mkfs.whatever itself is broken there
>> shouldn't be much difference.
>
> Sure, so we immediately have twice as many mkfs'es that could be broken.
> We also have to make sure the tools are available to the installer
> environment and the initramfs; that was what went wrong with LVM thinp
> in F21 - the tools were missing from the initramfs because dracut
> over-optimized. There's always one more darn thing.
>
> Yes, difference between container/non-container and complex filesystems
> like btrfs is more significant, but any difference adds failure points.
OK ... (I said "not a major source of bugs" not "never has any
issues").
I don't see the distinction. LVM thinp blows up, it's a major bug if the user
can't boot because not booting after install is typically a blocker bug, which is a
major sort of bug. Grubby can't update grub.cfg because Btrfs subvolumes confuse it?
It's a major bug, we compelled a code change to disallow /boot on Btrfs subvolumes
because the grubby failure is silent with Gnome initiated updates and means updated
kernels aren't ever used for booting - so it's potentially a security risk.
Chris Murphy