In my opinion, Yast2’s services-manager module should allow to define custom target and makes it accessible from Grub2. Additionally, there should be option to make target password protected.
I am not sure I understand what you mean. Thus my remarks below may be complete beside your subject, in which case you might want to explain it in another way.
When I look (using 42.3) in what YaST offers me in YaST > System > Services Manager, it shows top-left Default System Target and a menu below where you can choose between several items (e.g. the default on my system: Graphical Interface). AFAIK this has always been the case, taking into account that before systemd it was called Default Run Level.
Thus I am a bit baffled when you ask for this (or am I misinterpreting you?)
I have no idea why Grub2 should have access to this. When systemd starts as first process after the start of the kernel, Grub2 has already stopped it’s work. So what access of Grub2 for doing what do you mean? Also Grub2 has only access to what is in the /boot directory and the Default Target, which is a symbolic link named /etc/systemd/system/default.target, is not available to Grub2 during it is running at boot.
I also do not understand what you mean with “make target password protected”. Changing of the Default System Target is of course password protected because it may only be done by root. But I do not understand what making a target (or only the default target?) password protected. When should that password being asked for? What should it protect for what reason?
I remember that systemd reads kernel parameter about target of boot (multiuser/emergency/rescuse/graphical/etc.).
Idea is to allow to create new boot target and order Yast2 to create Grub2’s entry, which will boot system to that target (by passing target name to kernel parameter).
Example:
I create target called “network”. Marks NetworkManager enabled in this target and order Yast2 to add boot entry to start system with that target.
Other use case:
I will create gaming target, make networkmanager service, udev and dbus service available in this target. I Add custom service called Steam, which will ran Wayland session with Steam and enable it. I will make this target visible in Grub2 menu as GameMode.
I now think I understand what you want.
- Create custom targets in systemd formed to your own needs.
- Create entries in the Grub 2 configuration to have them available in the boot menu.
- to have a YaST module that helps you in doing this.
@1 Personally I think this is not easy to obtain. The systemd targets, like the run levels before (and I think the word “level” explains a lot here) are hierarchical. It means that target Graphical includes target Multi User, which includes … Thus theoretical you could have a target that has Graphical and a few services more above Graphical, but only one. You might succeed in deviating from this, but a thorough study of systemd is required I assume.
@2 You can create more entries to boot into more targets then there are by default (I assume there is now one for the default target, often but not in all case Graphical) and one for emergency).
@3 I doubt there is enough people that terribly need this, thus apart from the problems in the lower level as described above, I think not much effort will be put in such a YaST module (except maybe by you).
But you could try to ask for the feature of course. But at least with the more expanded information and not with the cryptical two liner of your first post. Do not expect that anybody will understand immediately what you mean and what you want. You have apparently thought this over, but that does not mean that anybody else has any idea about what you are talking about.
I think you probably mis-understand what a target Unit is.
It’s not the ultimate objective of a system boot,
systemd Target units are effectively milestones or waypoints, significant points during a longer boot process when various flows must culminate successfully before the boot process can then proceed.
The opening line in the official definition
A unit configuration file whose name ends in “.target” encodes information about a target unit of systemd, which is used for grouping units and as well-known synchronization points during start-up.
The full definition which fully describes the systemd Target Unit
https://www.freedesktop.org/software/systemd/man/systemd.target.html
As for what you (@OP) are describing,
You may investigate what many OS have been doing for the past 10 years or so, specifying “roles” both during the system install and thereby a specific system configuration Examples are CentOS, Fedora and MSWindows Server. All of them use the concept of “roles” to optimize the construction and performance of a system to perform specified functionality.
I’m not clear that what you’re suggesting on a multi-purpose system like openSUSE would really work. Already, by adopting systemd, the boot process is highly parallelized (always with room for improvement), so I’m not sure you’ll be able to find any benefits with what you are proposing, of course that may only be my lack of imagination.
If you really think you are on to a really cool, new idea with real benefit,
I should think that you could cobble together a rough demo of sorts by chaining together specific unit files during bootup.
If it results in something really worthwhile, you could as you say make it available as a grub menu option, and if enough people agree with your idea, it could turn into a community and project of its own…
Wouldn’t that be something!
IMO,
TSU