Re: Discussion: what would not blocking on btrfs look like?
Kamil Paral <[email protected]> Mon, 26 Aug 2019 16:52:23 +0200
| Newsgroups | gmane.linux.redhat.anaconda.devel,gmane.linux.redhat.fedora.testers,gmane.linux.redhat.fedora.kernel |
|---|---|
| Message-ID | <CA+cBOTf=-eHFw8CYfy7Uk_Xvg25oy69GW9JCtZGiwoa82B1N0w@mail.gmail.com> |
--===============1216900925700954816== Content-Type: multipart/alternative; boundary="00000000000043494e0591064fcc" --00000000000043494e0591064fcc Content-Type: text/plain; charset="UTF-8" On Mon, Aug 26, 2019 at 2:42 PM Justin Forbes <[email protected]> wrote: > From my standpoint, ext4 and xfs are the primary supported root > filesystems. I don't think that anything else should be release > blocking. If this is the case, we can explicitly list the supported file systems in criteria. The list would need to be extended with at least vfat, which is used for ESP, though. If we go this route, it would be nice to communicate this somehow to the end user, directly in anaconda interface. Either by showing a warning when a "not officially supported" filesystem is selected, or by hiding those filesystems in dialogs when creating a new partition (with a documented override). Existing partitions still need to be handled somehow, so the warning bar might need to be implemented in any case (warn that the existing partition is unsupported by allow to use it, or warn that the existing partition can't be used unless the override is activated). --00000000000043494e0591064fcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= _attr">On Mon, Aug 26, 2019 at 2:42 PM Justin Forbes <<a href=3D"mailto:= [email protected]">[email protected]</a>> wrote:<br></div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px= solid rgb(204,204,204);padding-left:1ex">From my standpoint, ext4 and xfs = are the primary supported root<br> filesystems. I don't think that anything else should be release<br> blocking. </blockquote><div><br></div><div>If this is the case, we can expl= icitly list the supported file systems in criteria. The list would need to = be extended with at least vfat, which is used for ESP, though.</div><div><b= r></div><div>If we go this route, it would be nice to communicate this some= how to the end user, directly in anaconda interface. Either by showing a wa= rning when a "not officially supported" filesystem is selected, o= r by hiding those filesystems in dialogs when creating a new partition (wit= h a documented override). Existing partitions still need to be handled some= how, so the warning bar might need to be implemented in any case (warn that= the existing partition is unsupported by allow to use it, or warn that the= existing partition can't be used unless the override is activated).</d= iv></div></div> --00000000000043494e0591064fcc-- --===============1216900925700954816== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Anaconda-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/anaconda-devel-list --===============1216900925700954816==--