Can anyone else reproduce this? I don't know if this is a Fedora 26
regression, or if it's been around since Fedora 25, but I can only
find old bugs about it. If it were not a very recent regression I'd
expect there'd be a more current bug report already.
The gist is that I don't see SMB shares in any open / save dialogs; I
have to navigate to
And now I can open and save things...
Except with flatpak programs, for which I opened a separate bug.
On Mon, Jul 3, 2017 at 2:57 PM, Owen Taylor <otaylor(a)redhat.com> 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 RMs, 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.
I'd say ideal scenario for Workstation-ostree is two partitions: one
big XFS volume, and one appropriately sized swap. /boot and /home are
directories. But due to an obscure bug  this practically means ext4
/boot, XFS for / and /home, and swap; or three partitions. I'd leave
LVM out of it because it doesn't really bring anything to the table,
The way this is done now for Server and Atomic Host makes sense for
those use cases. It doesn't make sense for Workstation-ostree. Right
now Workstation and Workstation-ostree make root fs 50G, and the rest
to /home. That needs revisiting for Workstation or Workstation-ostree,
it's just more necessary for Workstation-ostree because platform
libraries and flatpaks are bigger than traditional counterparts.
Partitions v quotas
It's better to use quotas as a limiter, rather than carving things up
with multiple partitions (or LVs). Quotas achieve the same goal, but
can be changed anytime and not having to worry if the user is going to
get wedged into an overfull root fs or home with wasted space on the
Of course the UIs for each filesystem's quota management are children
of satan, but that's a separate convo.
/home as separate partition
I'm skeptical that ostree installations are less fragile than
conventional installs, and obviate separate /home file systems, until
Joe User is doing weird and crazy shiat with it. Anaconda enforces a
reformat for ext4 and XFS root fs. So if /home is a directory, and a
reinstall becomes necessary, it means /home isn't salvageable, it'll
have to be restored from backups.
Anaconda exempts reformat on Btrfs, instead enforcing the creation of
a new subvolume for the root filesystem. Also separate root and home
come in handy on Btrfs for snapshotting them separately, and using
btrfs send/receive (directly or with btrbk) for home only backup and
Btrfs has online only, atomic grow and shrink, and uses the same
allocation code path for normal reads/writes and balancing, i.e. it's
highly exercised code and integral to its design. XFS can't shrink,
and ext4 only has offline shrink and while ostensibly safe (or else
it's a big bug) it comes with its own risks and inefficiencies in the
 Due to a combination of long delayed allocation on XFS flushing
journal contents to fs metadata, and Plymouth making itself kill
exempt, and systemd being unable to remount-ro, or umount the volume;
when /boot is a dir on rootfs it's possible for bootloader
configuration file changes to only hit the journal and not file system
metadata at reboot time. And the bootloaders do not know how to read a
dirty journal, so they don't see the updated bootloader file at all,
it's missing, so reboot from updates can fail entirely. If you merely
boot some other installation or live media and mount this root fs, the
kernel reads the dirty journal and flushes its contents to fs
metadata, and now everything is fine and the system will boot
normally, xfs_repair isn't even needed. Merely a mount and umount.
Technically all file systems are susceptible to this problem when
/boot is a directory and thus remount-ro fails and umount doesn't
happen. But only XFS seems to manifest with a problem. ext4 and Btrfs
must just flush to disk faster (or something).
I've just submitted a change proposal for creating Flatpaks out of Fedora package content:
This is submitted as a F27 change proposal, but it's expected that it will be multiple releases before everything in the final shape. My hope for Fedora 27 is that by the fall packagers will be able to start experimenting with making Flatpaks out of their graphical applications and there will be a small set of applications for users to install.
There is more extensive documentation about the technical plan at:
Flatpaks require rebuilding applications and bundled dependencies to be located with a prefix of /app rather than /usr. We're using the infrastructure created for modules to rebuild packages, and it has worked out very smoothly so far. There are prototype runtime and application modules at:
Building Flatpaks out of Packages
After building the packages, they need to be combined into a Flatpak runtime or application. There is a python script to do this locally in https://pagure.io/flaptak-module-tools, but the goal is do this within the same build pipeline as is used for containers, and I've started prototyping out changes to atomic-reactor.
One element that is needed to built Flatpaks or containers against modules is published composes of modules. This will be provided by the "On Demand Compose Service". Development on this by the modularity team started recently, but seems to be going well.
The goal is to distribute Flaptaks from registry.fedoraproject.org. This requires passing two hurdles:
* Flatpaks are OCI Images, not docker containers, and we don't have OCI Image support in registry.fedoraproject.org (which is an instance of https://github.com/docker/distribution/) There is conceptual agreement to add this upstream, and a pull request that is blocked on finalizing the OCI Image specification.
* For GNOME Software to provide a nice installation interface from the registry rather than an OSTree repository, we need to have a) an index of all flatpaks/containers in the registry b) appstream data for the containers in the registry. The cockpit team has similar requirements for their container installation interface, and we'll collaborate with them in coming up with a solution.
This work is still at the research and discussion phase.
There is work currently underway to add support to Bodhi for filing updates for containers rather than for packages should carry directly across to Flatpaks. This may be sufficient for F27. However, eventually it seems like we need to have automation, where updates of packages automatically cause updates of containers/flatpaks for those packages. This workflow still needs to be planned out in detail.