This is a giant and hacky workaround for
ostreedev/ostree#3193

The better real fix is probably in either systemd or anaconda
(more realistically both) but let's paper over things here for now.

Having code to run as a generator will likely be useful in the
future anyways.

Signed-off-by: Colin Walters <[email protected]>

This is a giant and hacky workaround for
ostreedev/ostree#3193

The better real fix is probably in either systemd or anaconda
(more realistically both) but let's paper over things here for now.

Having code to run as a generator will likely be useful in the
future anyways.

Signed-off-by: Colin Walters <[email protected]>

This is a giant and hacky workaround for
ostreedev/ostree#3193

The better real fix is probably in either systemd or anaconda
(more realistically both) but let's paper over things here for now.

Having code to run as a generator will likely be useful in the
future anyways.

Signed-off-by: Colin Walters <[email protected]>

This is a giant and hacky workaround for
ostreedev/ostree#3193

The better real fix is probably in either systemd or anaconda
(more realistically both) but let's paper over things here for now.

Having code to run as a generator will likely be useful in the
future anyways.

Signed-off-by: Colin Walters <[email protected]>

…ferent is mounted

As reported in ostreedev/ostree#3193, when the system
has mounted a different file system on "/" than what is configured in
/etc/fstab, we still try to execute "mount -o remount /", and that fails because
the filesystem that is actually mounted doesn't know about the options relevant
for the filesystem listed in /etc/fstab. I don't think it's useful to try to
apply options from /etc/fstab if the file system type or device are different.
In fact, it could be dangerous or destructive. If the user mounted something
different than what the fstab specifies, no matter how exactly, we should leave
that mount point alone.

…ferent is mounted

As reported in ostreedev/ostree#3193, when the system
has mounted a different file system on "/" than what is configured in
/etc/fstab, we still try to execute "mount -o remount /", and that fails because
the filesystem that is actually mounted doesn't know about the options relevant
for the filesystem listed in /etc/fstab. I don't think it's useful to try to
apply options from /etc/fstab if the file system type or device are different.
In fact, it could be dangerous or destructive. If the user mounted something
different than what the fstab specifies, no matter by what means, we should leave
that mount point alone.

If the filesystem is (potentially) multi-device, we only require the file
system type to match.

…ferent is mounted

As reported in ostreedev/ostree#3193, when the system
has mounted a different file system on "/" than what is configured in
/etc/fstab, we still try to execute "mount -o remount /", and that fails because
the filesystem that is actually mounted doesn't know about the options relevant
for the filesystem listed in /etc/fstab. I don't think it's useful to try to
apply options from /etc/fstab if the file system type or device are different.
In fact, it could be dangerous or destructive. If the user mounted something
different than what the fstab specifies, no matter by what means, we should leave
that mount point alone.

If the filesystem is (potentially) multi-device, we only require the file
system type to match.

As reported in ostreedev/ostree#3193, when the system
has mounted a different file system on "/" than what is configured in
/etc/fstab, we still try to execute "mount -o remount /", and that fails because
the filesystem that is actually mounted doesn't know about the options relevant
for the filesystem listed in /etc/fstab.

Let's be nice to the user and give a hint if the filesystem specified in fstab
doesn't match what is actually mounted. We still want to use the specified
configuration for backwards compatibility. But the mismatch is a potential
problem, for example when the user forgot to update fstab after updating the
boot option or the other way around. By warning, we give the user the chance to
notice this, and for example avoid pasting the (non-working) config from fstab
into a future boot entry.

If the filesystem is (potentially) multi-device, we only require the file
system type to match.

For my system:
$ SYSTEMD_LOG_LEVEL=debug build/systemd-remount-fs
...
Note: file system type mounted at "/" doesn't match fstab (type btrfs vs. vfat).
Consider adjusting fstab.
Remounting /...
...

$ SYSTEMD_LOG_LEVEL=debug build/systemd-remount-fs
...
Mount device /dev/disk/by-uuid/a9194733-9c5d-4fc6-8342-6c50646a4f58 specified in fstab doesn't exist,
             /dev/mapper/luks-4481d273-e5d8-4caa-bea7-d8ac9107dae7 is mounted instead.
Consider adjusting fstab.
Remounting /...
Successfully forked off '(remount)' as PID 482420.
mount: /: can't find UUID=a9194733-9c5d-4fc6-8342-6c50646a4f58.
mount: (hint) your fstab has been modified, but systemd still uses
       the old version; use 'systemctl daemon-reload' to reload.
/usr/bin/mount for / exited with exit status 1.