Create multiple boot states

Kryton7 · 2017-11-30 23:05:06

How can you boot Arch linux to be in different states, such as a low power mode wireless for ssh or GUI for direct use. I believe that it would involve using the bootloader, and if so, be directed to the page needed to understand what to do. I do not want to have two seperate partitions for the solution, though it works.

Wanted:
Grub 2.02
SSH -> systemctl start sshd
GUi -> systemctl start xinit

loqs · 2017-11-30 23:17:17

Welcome to the arch linux forums Kryton7. Boot_loaders covers the different boot loaders provided by arch as you did not specify which one your system uses.
See Systemd#Change_default_target_to_boot_into then you could set a different target for one entry. `man systemd.special` covers the provided default taregts.
Edit
If you need further help please clarify if the existing targets or sufficient for your needs, if not what additional targets you think you may need.
Also is one set of services (the lower power set ) a subset of the other (GUI for direct use)?

Last edited by loqs (2017-12-01 00:19:29)

Kryton7 · 2017-12-01 15:06:48

loqs wrote:

Welcome to the arch linux forums Kryton7. Boot_loaders covers the different boot loaders provided by arch as you did not specify which one your system uses.
See Systemd#Change_default_target_to_boot_into then you could set a different target for one entry. `man systemd.special` covers the provided default taregts.
Edit
If you need further help please clarify if the existing targets or sufficient for your needs, if not what additional targets you think you may need.
Also is one set of services (the lower power set ) a subset of the other (GUI for direct use)?

grub2:2.02-3
Linux ArchLinux 4.13.12-1-ARCH x86_64 GNU/Linux
systemd 235.38-2, systemd-sysvcompat 235.38-2, libsystemd 235.38-2

The targets are fine for working with GUI, however with the lower power mode things such as graphical.target, sys-devices-**.device (** being a desired device). LP would be a subset reduced version of GUI, so if I need run an xserver due to a given problem, I could just run a bash script that would load components (I can do the bash part).

Changing default targets would be valid, but then I would like to load additional modules depending on the selection of boot in grub. Changing the /etc/systemd/system would then seem like the next step, but I would not know how to do that before /etc/fstab is loaded.

loqs · 2017-12-01 17:16:32

Kryton7 wrote:

Changing default targets would be valid, but then I would like to load additional modules depending on the selection of boot in grub. Changing the /etc/systemd/system would then seem like the next step, but I would not know how to do that before /etc/fstab is loaded.

By modules do you mean kernel modules or systemd services or something else?
If you mean systemd services you would just ensure they have dependencies on the relevant targets sshd.service for example will by default install itself as WantedBy=multi-user.target.
You do not need to do this at boot time systemd will order the dependencies and services to be started to reach the target specified.
graphical.target depends on multi-user.target but the reverse is not true so as long as the low power services are assigned to multi-user.target and the others to graphical.target you have your division.

Kryton7 · 2017-12-01 19:55:53

So then, if I create my own target, such as LP.target which have dependentcies. I could use grub's systemd.unit command to run a specific *.target which then loads all systemd dependantcies that I want. Am I correct?

loqs · 2017-12-01 20:07:56

Yes. Slight clarification grub will pass systemd.unit to the kernel which will not recognize it, it will pass it to the initrd which if it is the tradidional shell script will not recognize it,
it will will then be passed to systemd which will attempt to build a set of dependencies to reach that target. I would stay away from custom targets until you have proven
that you can not achieve the result using for instance multi-user.target and graphical.target.

Trilby · 2017-12-01 20:11:15

loqs wrote:

I would stay away from custom targets until you have proven that you can not achieve the result using for instance multi-user.target and graphical.target.

Agreed. And I think the only possible proof of that would be you coming back and saying "I need 3 options". If you only need 2, mutli-user and graphical are your 2.

If you think multi-user.target has some services enabled that you'd not want enabled in your ideal target, then just disable them.

Kryton7 · 2017-12-01 20:15:11

Thank you for the information. I'll run a virtaul enviroment to test the principals. I'll come back with questions if it doesn't work.

cfr · 2017-12-01 23:42:31

There are also the 7 runlevel targets, to which the standard targets are mapped. So, I think even if you needed more than 2, you wouldn't necessarily need a custom target. Those not aliased by the traditional target names are not much used, though, so sticking to the two main ones, if possible, makes sense.

Arch Linux

#1 2017-11-30 23:05:06

Create multiple boot states

#2 2017-11-30 23:17:17

Re: Create multiple boot states

#3 2017-12-01 15:06:48

Re: Create multiple boot states

#4 2017-12-01 17:16:32

Re: Create multiple boot states

#5 2017-12-01 19:55:53

Re: Create multiple boot states

#6 2017-12-01 20:07:56

Re: Create multiple boot states

#7 2017-12-01 20:11:15

Re: Create multiple boot states

#8 2017-12-01 20:15:11

Re: Create multiple boot states

#9 2017-12-01 23:42:31

Re: Create multiple boot states

Board footer