Low priority: I'm tempted to nominate this year old bug as a final blocker under the data corruption provision. And I'm wondering what people think of this.
RFE: Do not persistently mount EFI System partition at /boot/efi https://bugzilla.redhat.com/show_bug.cgi?id=1077984
A crash/panic or power failure has a high degree of FAT corruption potential. The FAT kernel maintainer says this is more or less expected and that the volume shouldn't be persistently mounted. The RFE contains a ~18 month (or better) tested work around, using mount options 'x-systemd.automount,noauto' to prevent it from being mounted unless needed. At the moment it doesn't autoumount so it can still get corrupted, but this is better than nothing.
The bug is an RFE so making it a blocker is, well, it's 50% RFE and 50% data corruption bug, and is an odd duck way of getting it fixed but there's no traction in a year, not even a comment.
The problem came up again today on the systemd list where Kay says "Right, the Linux FAT driver, or maybe just the way Linux handles the writeback to disk, is absolutely fragile. Corrupted FAT file systems are the norm and not the exception. We must mount it unconditionally, it will just break after a while." http://lists.freedesktop.org/archives/systemd-devel/2015-March/029334.html
Hence my desire to escalate.
On Wed, 2015-03-11 at 21:38 -0600, Chris Murphy wrote:
Low priority: I'm tempted to nominate this year old bug as a final blocker under the data corruption provision. And I'm wondering what people think of this.
I would vote -1 on it.
The bug is an RFE so making it a blocker is, well, it's 50% RFE and 50% data corruption bug, and is an odd duck way of getting it fixed but there's no traction in a year, not even a comment.
The release blocker system is for correctly identifying *release blocker* bugs, it's not a generic 'flag for attention' system. That was what we had before with the FXXTarget bugs, but no-one ever really paid much attention to them.
On Wed, Mar 11, 2015 at 9:56 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2015-03-11 at 21:38 -0600, Chris Murphy wrote:
Low priority: I'm tempted to nominate this year old bug as a final blocker under the data corruption provision. And I'm wondering what people think of this.
I would vote -1 on it.
The bug is an RFE so making it a blocker is, well, it's 50% RFE and 50% data corruption bug, and is an odd duck way of getting it fixed but there's no traction in a year, not even a comment.
The release blocker system is for correctly identifying *release blocker* bugs, it's not a generic 'flag for attention' system.
Which is why I originally filed it as an RFE. But since then it's become much more clearly a consistent corruption problem and as such is sliding more toward design flaw then feature request. I mean, no one ever says "hey feature request, let's not corrupt bootloader partitions."
That was what we had before with the FXXTarget bugs, but no-one ever really paid much attention to them.
Well the out in the data corruption criteria is "document it", so even if it doesn't get fixed there's more awareness...