This is 'mount' output:

> [root@virt-561 ~]# mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=4096k,nr_inodes=1048576,mode=755,inode64)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel,size=2020956k,nr_inodes=505239,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,size=808384k,nr_inodes=819200,mode=755,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime,seclabel)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
/dev/mapper/rhel_virt--561-root on / type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,nosuid,noexec,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=36,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=14041)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime,seclabel)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime,seclabel)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime,seclabel)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
none on /run/credentials/systemd-sysusers.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
/dev/vda1 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=404120k,nr_inodes=101030,mode=700,inode64)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,nosuid,nodev,noexec,relatime,seclabel)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)

Not exactly sure (yet) why it is happening, but removing `Alias=` from booth@.service helps. This is (without any problems) reproducible also in Fedora.

Not sure if it is problem or expected feature of systemd, but it's not caused by any change in booth package itself so it's definitively something in systemd/... so reassigning to systemd.

Service booth@.service:
```
#  This file is part of Booth.

[Unit]
Description=Booth - Ticket Manager for Pacemaker Clusters
Documentation=man:boothd(8)
After=network-online.target
ConditionFileNotEmpty=/etc/booth/%i.conf
Conflicts=pacemaker.service

[Install]
Alias=boothd
WantedBy=multi-user.target

[Service]
Type=simple
NotifyAccess=main
ExecStart=/usr/sbin/boothd daemon -S -c %i
```

When Alias is removed, everything works. No matter what Alias is used, when Alias= exists failure "Invalid cross-device link" is reported by systemctl enable booth@ANYTHING. Is it known problem? Is it expected? It's easy to workaround on booth side (just remove Alias), but it used to work in previous RHEL versions.

To me, it sounds like it was a bug in 9.0. The Alias stanza does not make any sense. Your unit file is a template, so it requires an argument. But you are creating an alias that does not require one. So systemd will not know what to do when a user says systemctl start boothd. So you should really drop this from the unit file.

(In reply to Lukáš Nykrýn from comment #4)
> To me, it sounds like it was a bug in 9.0. The Alias stanza does not make
> any sense. Your unit file is a template, so it requires an argument. But you
> are creating an alias that does not require one. So systemd will not know
> what to do when a user says systemctl start boothd. So you should really
> drop this from the unit file.

Ok. It used to work in RHEL 7 and RHEL 8 so my question is - is the systemd "fix" going to land in RHEL 7/8 (= we need to workaround RHEL 7/8 unit-file because of "fix" in systemd?). Are you sure it is really correct behavior to display "Invalid cross-device link" error message instead of something like "Alias directive is not supported in template unit file" - maybe something to improve?

There are actually two problems with the Alias stanza. One has already been mentioned by Lukáš in comment 4. The other one--which I think is the main issue here--is that the name is missing suffix. Unit names must always be fully spelled in unit files; the shortcut with .service being the default only works on systemctl's command line. IOW, if this has ever worked as expected, it's been by a happy coincidence, not by intent. The alias should be specified like this:

Alias=boothd@%i.service

(In reply to Jan Friesse from comment #5)
> Ok. It used to work in RHEL 7 and RHEL 8 so my question is - is the systemd
> "fix" going to land in RHEL 7/8 (= we need to workaround RHEL 7/8 unit-file
> because of "fix" in systemd?). Are you sure it is really correct behavior to
> display "Invalid cross-device link" error message instead of something like
> "Alias directive is not supported in template unit file" - maybe something
> to improve?

Already done, see https://github.com/systemd/systemd/pull/24728 .

@dtardon Honestly I don't think alias itself ever worked AND it's not what the bug is about. The bug is about sudden change in systemd which made unit, which was working fine (eventho it may be incorrect) during RHEL 7/8/9.0, non-working and producing totally non-understandable error. Honestly RHEL is about compatibility so I would expect for RHEL fix will just produce warning - not error.

But back to main question - Do you expect the "fix" which made "incorrect" unit produce the error message going to get into RHEL 7? RHEL 8? If so, which versions do you expect it will happen? I need to know it to find out to which versions of RHEL we have to make release/Z-Stream of fixed unit.

(In reply to Jan Friesse from comment #9)
> But back to main question - Do you expect the "fix" which made "incorrect"
> unit produce the error message going to get into RHEL 7? RHEL 8?

Certainly not.

I have verified that enabling systemd unit booth@booth is possible with fixed booth-core-1.0-251.5.bfb2f92.git.el9_1.x86_64



> [root@virt-490 ~]# rpm -qa | grep booth
booth-core-1.0-251.5.bfb2f92.git.el9_1.x86_64
booth-arbitrator-1.0-251.5.bfb2f92.git.el9_1.noarch

> [root@virt-490 ~]# pcs booth enable
booth@booth enabled

> [root@virt-490 ~]# systemctl enable booth@booth

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (booth bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2157