This is a consolidated post, responding to multiple parties.
Pete Travis lists at
petetravis.com Tue May 5 15:45:11 UTC 2015
I've seen people get themselves into tricky partitioning layout
situations
- especially on non-GPT systems - and the flexibility of LVM made it
possible for them to install Fedora. Sometimes they did it to themselves,
sometimes it's from the OEM. I suspect with admittedly no hard data that
LVM as default transparently handled many, many situations where without
LVM, relatively complex manual partitioning would be required.
For any preexisting 3 primary partition layout, the remaining MBR partition
can become an extended partition, and Anaconda/GRUB can (and do) use only
logical partitions. For capturing non-contiguous partitions and presenting
them as one volume, either LVM or Btrfs would be needed.
People get themselves into tricky partitioning layouts because Linux
installers are explicitly designed let them do crazy things. This doesn't
happen on Windows, OS X or mobile devices. It's one size fits all, you get
what you get, no discussion.
Yet despite the complexity of the installer's custom partitioning, it can't
delete either LVM VG's or Btrfs volumes, instead this only happens once the
user manually deletes all LVs or subvolumes first; and it requires the user
manually create required partitions on UEFI. It's a task and knowledge not
required for BIOS hardware for all of Fedora's history, and for no benefit.
And yet it's not a bug. [6]
As far as I know this is still a bug, it basically breaks boot of any prior
OS using LVM because its LVs aren't made active during Fedora installation,
therefore boot entries aren't created for it.
Anaconda should run grub2-mkconfig when LVM devices are active
https://bugzilla.redhat.com/show_bug.cgi?id=825236
*Josh Boyer* jwboyer at
fedoraproject.org
<desktop%40lists.fedoraproject.org?Subject=Re:%20Re%3A%20LVM%20in%20default%20filesystem%20layout&In-Reply-To=%3CCA%2B5PVA66dJ-KXe7k9SWNSgxEM7%2B2Pe8eOhVZQDFJTkhWNog8cA%40mail.gmail.com%3E>*Tue
May 5 13:32:50 UTC 2015*
And it's a great example of why we don't immediately default
to using
something shiny and new just because it exists. Btrfs is neither
shiny or new at this point, and we look at it every release and
discuss it with upstream and it still isn't ready to be default.
More correctly these days, Fedora isn't ready for Btrfs. Even if Btrfs were
as stable as ext4 Fedora couldn't use it by default right now.
The installer still has problems dealing with it [1], and installer team
expects Btrfs development to be slim to none in the near future [2]. Grubby
still doesn't support /boot on Btrfs [3]. For any other file system those
would be blockers. Fedora release criteria considers Btrfs equal, without
exceptions, to other file systems, but in practice at blocker reviews
pretty much anything Btrfs gets a hand waive.
GNOME Disks doesn't support resize, snapshots, subvolume creation or
deletion, gnome-shell gets confused with multiple disk Btrfs when mounting
and umounting, and understanding volume size [4]. But openSUSE ships GNOME
with Btrfs by default, so obviously these bugs aren't show stoppers, but
still no bueno.
None of these are Btrfs kernel code or btrfs-progs related. The fact is,
Btrfs is not a priority on Fedora, maybe not even of tertiary importance to
either Fedora or Red Hat who have a pile of ext4, XFS, and LVM developers
but no Btrfs developers. So to properly pin the tail on this donkey, it's
at least as much Fedora's non-readiness and disinterest in Btrfs right now.
Other things to consider: ext4 on LVM is not well suited for eventual
conversion to Btrfs. It can be done, it should work, if it doesn't it's a
bug. But it just adds complexity for no good reason. Presently (and I'll
argue properly) the installer doesn't permit LVM + Btrfs. There's an open
question on backups and Btrfs volumes especially in the context of
snapshots. We could use a tool that leverages btrfs send/receive so
everything can be backed up, not just mounted subvolumes. The LVM and file
system question opens up a bunch of related things, and I think they all
need an integrated big picture approach rather than it just being a list of
LVM pros/cons being used to arrive at a decision.
*Stephen Gallagher* sgallagh at
redhat.com
<desktop%40lists.fedoraproject.org?Subject=Re:%20Re%3A%20LVM%20in%20default%20filesystem%20layout&In-Reply-To=%3C1000897174.11637103.1430859296013.JavaMail.zimbra%40redhat.com%3E>*Tue
May 5 20:54:56 UTC 2015*
This should probably be its own thread, but I'll note that the
current
state of encryption on Workstation is less than ideal (speaking as someone
using it). Offline updates with encrypted partitions means re-entering the
password twice; once to enter the offline-update mode and once to boot
again afterwards. This is a bigger inconvenience than it sounds.
Offline updates requiring two reboots is asinine. Encryption by default
just makes it more obvious. Windows likes to do these double reboots on
updates from time to time too, so it's not completely foreign. But for the
most part they quit the user session, do updates, and reboot once. That's
what happens on OS X also.
To do encryption by default, there needs to be a way for
gnome-control-center>users>change password to also reset the KEK in LUKS,
as well as to add keys when users are added. Right now, LUKS supports 8 key
slots, which may be a problem for encryption by default. Otherwise I
support the idea of encryption by default. [5]
Chris Murphy
[1]
Can't resize btrfs
https://bugzilla.redhat.com/show_bug.cgi?id=962143
Custom partitioning can't delete Btrfs volumes (manual full teardown of
each subvolume must be done by the user)
https://bugzilla.redhat.com/show_bug.cgi?id=1185117
[2]
https://bugzilla.redhat.com/show_bug.cgi?id=585525#c5
[3] This single bug has had numerous side effect bugs related to kernel
upgrades failing to boot, crashes due to the lack of an initramfs entry in
the grub.cfg, install failures. It goes back to 2012, is 102 messages long,
no sane person will click on this link.
https://bugzilla.redhat.com/show_bug.cgi?id=864198
[4]
https://bugzilla.gnome.org/show_bug.cgi?id=746769
https://bugzilla.gnome.org/show_bug.cgi?id=710156
https://bugzilla.gnome.org/show_bug.cgi?id=708786
[5] It's a drag there's no open source UEFI driver to enable FDE OPAL 2.0
support. Many SSDs (I think now all Samsung SSDs) come with OPAL support
and already always encrypt the drive, but it's always unlocked by default
so it appears to be unencrypted.
[6]
https://bugzilla.redhat.com/show_bug.cgi?id=1022316
--
Chris Murphy