The actual PR is posted in: https://pagure.io/pungi-fedora/pull-request/257
This is only for: https://fedoraproject.org/wiki/Changes/WorkstationOstree
The primary reason to do this is that the blivet defaults break with ostree, since `/home` needs to be `/var/home` with ostree. https://bugzilla.redhat.com/show_bug.cgi?id=1382873
But bigger picture than that, having a split `/home` makes less sense using rpm-ostree, because the primary original rationale for introducing that split was to make upgrades easier by reinstalling but preserving `/home`. With rpm-ostree upgrades should be much more reliable and easier.
We also to use XFS (as opposed to the blivet ext4 default) for the same reason as Atomic/Server - it works better with overlay2 because it avoids inode limits.
And not using all of the disk makes it easier to do more advanced partitioning *post* installation. For example, in the past I've used dm-crypt for the OS and `/home`, but not for `/srv` where I put non-private data like my git repositories. (Although I recently switched back to dm-crypt for everything for simplicity).
Another good example of this is that `container-storage-setup` supports allocating a separate LV for `/var/lib/docker`, so container storage is isolated from the host.
Anaconda is making it easier to do arbitrary partitioning in the installer via blivet-gui, but I think doing it post-install is more flexible. One can use scripts as well (e.g. Ansible).
The flip side of course is that users are going to wonder why they only have `14G` of space...we should likely teach the installer to have a simple "use all of my disk" button, and also have one post-install (something like Nautilus launching `Disks` with awareness of LVM)?
Signed-off-by: Colin Walters walters@verbum.org --- fedora.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fedora.conf b/fedora.conf index a7d403b..edc3586 100644 --- a/fedora.conf +++ b/fedora.conf @@ -812,7 +812,7 @@ ostree_installer = [ "x86_64": { "repo": "Everything", "release": None, - "installpkgs": ["fedora-productimg-workstation"], + "installpkgs": ["fedora-productimg-atomic"], "rootfs_size": "8", "add_template": ["workstation-ostree-installer/lorax-configure-repo.tmpl", "workstation-ostree-installer/lorax-embed-repo.tmpl"],
Or perhaps another way to look at this is - with both Server and AtomicHost using the same partition defaults, if we changed Workstation (and not just WS-ostree) this way, then we could dedup all of them back inside the Anaconda defaults, and go back to speaking of the "Fedora" partitioning defaults.
But I'm just arguing right now for changing ws-ostree.
On Mon, 2017-06-19 at 15:32 -0400, Colin Walters wrote:
Or perhaps another way to look at this is - with both Server and AtomicHost using the same partition defaults, if we changed Workstation (and not just WS-ostree) this way, then we could dedup all of them back inside the Anaconda defaults, and go back to speaking of the "Fedora" partitioning defaults.
Why would that be a step forward ? Choosing suitable defaults is one of the main reason for having separate products, as opposed to just an amorphous 'Fedora'.
On Mon, Jun 19, 2017, at 03:43 PM, Matthias Clasen wrote:
Why would that be a step forward ? Choosing suitable defaults is one of the main reason for having separate products, as opposed to just an amorphous 'Fedora'.
I'd say we clearly need the ability, but we also need to choose wisely where to spend our deltas. Having switched from working on the desktop to the server side, I can say for sure there's a lot of crossover in both the obvious areas like the installer and networking, to the less obvious like having random tools and scripts work in both cases.
Anyways I'm not proposing changing the main Workstation because it'd be a huge change obviously.
But this does bring what's still branded in Fedora releng as "workstation-ostree" closer to Atomic Host, hence closer to https://fedoraproject.org/wiki/Workstation/AtomicWorkstation So more delta from Workstation, less from AH.
On Mon, Jun 19, 2017 at 03:22:31PM -0400, Colin Walters wrote:
But bigger picture than that, having a split `/home` makes less sense using rpm-ostree, because the primary original rationale for introducing that split was to make upgrades easier by reinstalling but preserving `/home`. With rpm-ostree upgrades should be much more reliable and easier.
I guess the cost here is that it makes it harder to decide that you wanted non-Atomic workstation after all. But as long as we're just changing the default, I don't have a strong opinion.
On Mon, Jun 19, 2017, at 07:25 PM, Matthew Miller wrote:
On Mon, Jun 19, 2017 at 03:22:31PM -0400, Colin Walters wrote:
But bigger picture than that, having a split `/home` makes less sense using rpm-ostree, because the primary original rationale for introducing that split was to make upgrades easier by reinstalling but preserving `/home`. With rpm-ostree upgrades should be much more reliable and easier.
I guess the cost here is that it makes it harder to decide that you wanted non-Atomic workstation after all. But as long as we're just changing the default, I don't have a strong opinion.
You mean if you wanted to reinstall and keep /home? Yeah, but the flip side is with a "not all space allocated" installation default, one can carve out space from the VG for a new install and copy /home. I don't think Anaconda has any specific UI for that, but you could even do it post install, just keep the existing partition and mount /home.
I'd say the current target audience is to some degree expected to have sufficient expertise for these types of things. At least I am certainly going to be investing in making sure that we smooth over sufficient issues that going back will hit fewer people.
But a good example of something that people will hit is https://github.com/projectatomic/rpm-ostree/issues/233 and I can certainly imagine that being a blocker. OTOH what the Chrome RPM is doing is horrific and it has enough hooks in /usr anyways that it'd just make more sense there. (Or really, as a flatpak but that's a whole other story)
I don't have any problem with switching to XFS or getting rid of the /home split. The former should be pretty invisible to users, and split home is more of a trap for users than a help.
But switching to leaving most of the disk unpartitioned seems wrong. With the move to overlay2 for Docker storage, everything you want to do with disk space is inside / - the OS image, your overlay RPMs, your docker storage, your home directory. Yes, early adopters of the Atomic Workstation can deal, but long term, we don't want Atomic Workstation to be for the adventurous - we want it to just work.
Yes, it's easier to grow partitions then shrink them, but I don't think that can excuse leaving users out of the box with a less-than-useful partitioning setup.
Owen
----- Original Message -----
The actual PR is posted in: https://pagure.io/pungi-fedora/pull-request/257
This is only for: https://fedoraproject.org/wiki/Changes/WorkstationOstree
The primary reason to do this is that the blivet defaults break with ostree, since `/home` needs to be `/var/home` with ostree. https://bugzilla.redhat.com/show_bug.cgi?id=1382873
But bigger picture than that, having a split `/home` makes less sense using rpm-ostree, because the primary original rationale for introducing that split was to make upgrades easier by reinstalling but preserving `/home`. With rpm-ostree upgrades should be much more reliable and easier.
We also to use XFS (as opposed to the blivet ext4 default) for the same reason as Atomic/Server - it works better with overlay2 because it avoids inode limits.
And not using all of the disk makes it easier to do more advanced partitioning *post* installation. For example, in the past I've used dm-crypt for the OS and `/home`, but not for `/srv` where I put non-private data like my git repositories. (Although I recently switched back to dm-crypt for everything for simplicity).
Another good example of this is that `container-storage-setup` supports allocating a separate LV for `/var/lib/docker`, so container storage is isolated from the host.
Anaconda is making it easier to do arbitrary partitioning in the installer via blivet-gui, but I think doing it post-install is more flexible. One can use scripts as well (e.g. Ansible).
The flip side of course is that users are going to wonder why they only have `14G` of space...we should likely teach the installer to have a simple "use all of my disk" button, and also have one post-install (something like Nautilus launching `Disks` with awareness of LVM)?
Signed-off-by: Colin Walters walters@verbum.org
fedora.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fedora.conf b/fedora.conf index a7d403b..edc3586 100644 --- a/fedora.conf +++ b/fedora.conf @@ -812,7 +812,7 @@ ostree_installer = [ "x86_64": { "repo": "Everything", "release": None,
"installpkgs": ["fedora-productimg-workstation"],
"installpkgs": ["fedora-productimg-atomic"], "rootfs_size": "8", "add_template": ["workstation-ostree-installer/lorax-configure-repo.tmpl", "workstation-ostree-installer/lorax-embed-repo.tmpl"],-- 2.9.4 _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
On Mon, Jul 03, 2017 at 04:57:46PM -0400, Owen Taylor wrote:
I don't have any problem with switching to XFS or getting rid of the /home split. The former should be pretty invisible to users, and split home is more of a trap for users than a help.
I was chatting with one of the Red Hat filesystem people, and he suggested that XFS would be his personal recommendation for all of Fedora, not just workstation.
Yes, it's easier to grow partitions then shrink them, but I don't think that can excuse leaving users out of the box with a less-than-useful partitioning setup.
Well, with XFS, it's _impossible_ to shrink them, so there's that.
On Mon, Jul 03, 2017 at 05:13:25PM -0400, Matthew Miller wrote:
I was chatting with one of the Red Hat filesystem people, and he suggested that XFS would be his personal recommendation for all of Fedora, not just workstation.
I mean, including Workstation, not just Server and Atomic. But also not just Workstation. :)
On Mon, Jul 3, 2017, at 04:57 PM, Owen Taylor wrote:
I don't have any problem with switching to XFS or getting rid of the /home split. The former should be pretty invisible to users, and split home is more of a trap for users than a help.
But switching to leaving most of the disk unpartitioned seems wrong. With the move to overlay2 for Docker storage, everything you want to do with disk space is inside / - the OS image, your overlay RPMs, your docker storage, your home directory. Yes, early adopters of the Atomic Workstation can deal, but long term, we don't want Atomic Workstation to be for the adventurous - we want it to just work.
I obviously agree, however https://bugzilla.redhat.com/show_bug.cgi?id=1382873 really needs to be worked around immediately. I could try to fix it but anything touching the anaconda+storage layers isn't going to make F26. So we either do this one liner or punt I'd say.
On Tue, Jul 4, 2017 at 5:02 AM, Colin Walters walters@verbum.org wrote:
On Mon, Jul 3, 2017, at 04:57 PM, Owen Taylor wrote:
I don't have any problem with switching to XFS or getting rid of the /home split. The former should be pretty invisible to users, and split home is more of a trap for users than a help.
But switching to leaving most of the disk unpartitioned seems wrong. With the move to overlay2 for Docker storage, everything you want to do with disk space is inside / - the OS image, your overlay RPMs, your docker storage, your home directory. Yes, early adopters of the Atomic Workstation can deal, but long term, we don't want Atomic Workstation to be for the adventurous - we want it to just work.
I obviously agree, however https://bugzilla.redhat.com/show_bug.cgi?id=1382873 really needs to be worked around immediately. I could try to fix it but anything touching the anaconda+storage layers isn't going to make F26. So we either do this one liner or punt I'd say.
I'm a +- 0 on the PR, at least the installation works, but the ensuing layout is suboptimal for workstation.
We just need to decouple creating official Workstation-ostree Fedora 26 installation media, because this bug isn't the only one that ought to get fixed for rolling out wider testing for Workstation-ostree. I don't know the releng rules on this, if there's a way to make it some kind of spin. I know there are some volunteers that are spinning up a new Workstation ISO every couple of weeks with new packages so something along those lines?
On Tue, Jul 4, 2017 at 11:33 AM, Chris Murphy lists@colorremedies.com wrote:
I obviously agree, however https://bugzilla.redhat.com/show_bug.cgi?id=1382873
Weird. I always hit that bug and end up at a dracut shell. But openQA doesn't hit it? Uhh, hmm. https://openqa.fedoraproject.org/tests/117137
The df output from the openQA test set of logs: https://openqa.fedoraproject.org/tests/117137/file/_collect_data-df.log
There's nothing mounted at /home.
desktop@lists.fedoraproject.org
-
Chris Murphy -
Colin Walters -
Matthew Miller -
Matthias Clasen -
Owen Taylor