1) systemd-generators are typically used to convert configuration files in units. But, systemd-gpt-auto-generator has NO config. 2) As it says in a description of generators, "User configuration should override vendor configuration. This (mostly) means that stuff from /etc should override stuff from /usr." http://www.freedesktop.org/wiki/Software/systemd/Generators/ However, the systemd-gpt-auto-generator is provided by the vendor and can not be overridden or disabled by user. In addition, the generated units names contain non-permanent device names, like dev-sda1.swap, and therefore can't be reliably masked by user. In other words, the systemd-gpt-auto-generator makes GPT, in some circumstances, a higher priority than the explicitly given configuration in fstab: If GPT contain two swap partitions, with DEFAULT, non-changed "swap" ID, it will automatically connect both swaps, even if the fstab (or directly in the native units) explicitly stated to use ONLY ONE of them. Possible solutions: 1) Make systemd-gpt-auto-generator configurable by user, to filter selected types of partitions, or ability to swich off GPT reading in main systemd config. 2) Make way to mask unwanted system-generators, like units or udev-rules.
Agreed, generators should be maskable.
It is up to the user how they want their SWAP managed. I have just discovered this nasty flaw and want it removed. I have a separate /boot partition that loads different installations and now I find that this bug has been deliberately introduced. When things like this are put into systemd it is no wonder that people hate it so much. It most certainly does not allow the fstab to be used. Anything that is added to systemd should be able to be disabled by systemctl or it should not be added at all.
Generators are made maskable in commit http://cgit.freedesktop.org/systemd/systemd/commit/?id=e801700e9a. Some documentation updates are in order, but generally ln -s /dev/null /etc/systemd/system-generators/<name> does the trick.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.