On Sat, 26.09.15 00:47, Paul D. DeRocco (pdero...@ix.netcom.com) wrote: > I have a Yocto-built x86 system, running off a USB flash drive that has > two partitions on it. /dev/sda1 is a small FAT file system that I use for > persistent data storage, and isn't bootable. /dev/sda2 is the root file > system, which boots via Syslinux. I use a mount unit to mount /dev/sda1 on > /media/chroma. However, it finds that /dev/sda1 is already mounted on > /media/sda1. It goes ahead and mounts it anyway, with a warning, but my > mount options (noatime,tz=UTC) are ignored. > > I tried putting the /media/chroma mount in fstab. Now it fails entirely, > perhaps because systemd-fstab-generator won't create a mount unit for > something that's already mounted somewhere else. > > But what I can't figure out is what the heck is mounting /dev/sda1 on > /media/sda1 in the first place. None of the generators in > /lib/systemd/system-generators seem to be to blame, according to their > docs. How do I make it not do that, so that I can mount it with my own > options, either in fstab or with an explicit mount unit? The version of > the system I did a couple of years ago, with an earlier Yocto, an earlier > systemd, and an earlier kernel, didn't have this behavior. > > And while we're at it, is there a way to control what mount options it > uses for the root? I'd like to use noatime, so that it doesn't abuse my > flash drive needlessly.
None of systemd's components will mount anything to /media, unless explicitly configured for that via /etc/fstab or so. /media is traditionally the place to mount removable media, but it's a pretty bad place for that, since it is vulnerable to DoS attacks by different users. As such, even if we had a logic to handle removable media (which we don't), we'd certainly not mount it there... I think some distros (Ubuntu? Debian?) patch udisks to mount removable media to /media, because they ignore the DoS vulnerability that is using a shared namespace for such mounts. Maybe you have udisks installed from one of those distros? Either way, systemd is not responsible. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel