You are not logged in.
Pages: 1
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
Offline
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)
Offline
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.
Offline
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.
Offline
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?
Offline
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.
Offline
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.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
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.
Offline
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.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Pages: 1