Re: [arch-general] Systemd boot
On Sun Nov 29, 2020 at 1:14 PM CET, Lone_Wolf wrote:
> It wasn't clear to me (and still is not) what initramfs environment your
> questions were about.
>
>
> Do you want answers based on systemd manpages OR on a systemd initramfs
> as setup by mkinitcpio on archlinux ?
As I conjecture below, I don't think there is any difference between the
two.
>
> In folder /usr/lib/initcpio/install/ you'll find the systemd ,
> sd-encrypt , sd-lvm2 , sd-shutdown and sd-vconsole hook scripts .
>
> Look at their contents and notice they add specific services and
> targets.
>
> Basic.target is NOT one of them, which suggests that it doesn't matter
> in the initramfs stage of a systemd initramfs boot on archlinux.
This is /not/ correct. Please verify your information more carefully
before asserting on a public mailing list as to avoid creating confusion
for future readers who may stumble upon the archives.
basic.target is part of Arch's (and most other distro's) systemd initrd,
as you will find /easily/ out by examining the output of `journalctl -b
-g "Basic System"`.
Although as you correctly observe, it is not explicitly pulled in, so
let's take a look at how the systemd install hook works:
add_systemd_unit() {
# Add a systemd unit file to the initcpio image. Hard dependencies
# on binaries and other unit files will be discovered and added.
# $1: path to rules file (or name of rules file)
(slightly reformatted to better fit the email line limit)
I.e. (way) more units are pulled in w.r.t. the ones which are explicitly
added.
basic.target, in particular, gets pulled in as it is an hard dependency
(Required-by) initrd.target. You can verify this by extracting your
initrd and observing the hard dependency in
/lib/systemd/system/initrd.target (which is explicitly pulled in from
the systemd install hook).
You can also find this out on a running system with the following
command:
sudo systemctl list-dependencies --reverse basic.target
As far as I can tell, Arch's systemd boot process is pretty much the
same as the standard one. Please do point out any real, proven
differences there might be between Arch's systemd boot process and
what's described in bootup(7), if you can identify any. I would be
definitely interesting in knowing, as I'm developing a new software
package which might be sensible to those.
Until then, I will work under the assumption that there's no such
difference - as I cannot identify any - so my original questions still
stand.
For reference, I found the answer of the final question I posed in my
original email. An useful approach in the case of the example is to add
a drop-in to the templates of interest, to which you can add a (soft or
hard, as needed) dependecy to your templates, propagating the parameter
as needed. E.g.:
/etc/systemd/systemd/systemd-cryptsetup@.service/10-drop-in.conf:
[Unit]
Wants=whatever-dependency@%i.service
After=whatever-dependency@%i.service
systemd-cryptsetup-generator will (if configured correctly) only
generate the units for the volumes which still need activation, enabling
more granularity in key deployment.
Riccardo
Re: [arch-general] Systemd boot
On Sat Nov 28, 2020 at 1:58 PM CET, Lone_Wolf wrote: > Archlinux has its own boot process, described at [1] > > Check the initramfs section and you'll see a reference to mkinitcpio [2] > . > > On the mkinitcpio page look at the Common Hooks section. > > Basically there are 2 systems that archlinux can use in initramfs : > busybox and systemd . > > > Check the hooks in your mkinitcpio.conf : are you using the systemd hook > or any of the sd-* hooks ? > > If yes, mkinitpio sd-encrypt hook is what handles your encrypted drives. > see [3] for details > > If no, busybox encrypt hook is responsible, see [4]. I'm informed on what the supported boot processed for Arch are, and I very well known which one I'm running, as I configured it. :) I'm grateful for your help, but you didn't really answer any of my questions, which are about some specifics of the systemd boot process that I'd like to better understand. Riccardo
[arch-general] Systemd boot
I2'm trying to fully make sense of the boot process with systemd. I've read various pages from the manual, including bootup(7). There are two points I don't fully understand. * Filesystem mounts during initrd The man page, under the initrd section, says: "systemd detects that it is run within an initrd [...]. The bootup process begins identical to the system manager bootup (see above) until it reaches basic.target. [...] Before any file systems are mounted, it must be determined whether the system will resume from hibernation or proceed with normal boot." In my mind, that part self-contradicts when both saying that 1) the bootup proceeds identical to the system manager bootup and 2) a determination on whether to mount file systems is made /after/ basic.target. This is because some file systems (including, in most cases, the root file systems) would have been mounted before local-fs.target, which is ordered before basic.target. So either the process is not really identical until basic.target, or I'm getting something wrong. * Instances I gather that the systemd which runs inside the initrd is a completely separate instance from the one which then runs in the booted system. Which implies - as discussed above - that the system initialization sequence from beginning to basic.target actually happens twice. Does this means than any initialization units which could potentially be run twice - once in the initrd and once in the booted system - should be instrumented to avoid running their logic twice (in the cases where that's not needed or even harmful)? Let's consider for example an hypothetical service with "WantedBy=cryptsetup-pre.target", which decrypts a keyfile using an hardware token. This keyfile is then consumed by systemd-cryptsetup-generator with keyfile-erase=on. What happens if the service is run twice, but the key is consumed only the first time? A decrypted keyfile remains in the system. What's the correct approach to avoid such a scenario? Riccardo
[arch-general] R: openvpn-client@ takes long time to start
Da: Giancarlo Razzolini Inviato: Venerdì, 14 Agosto, 2020 13:29 A: General Discussion about Arch Linux Cc: Riccardo Paolo Bestetti Oggetto: Re: [arch-general] openvpn-client@ takes long time to start Em agosto 14, 2020 3:58 Riccardo Paolo Bestetti via arch-general escreveu: >> After a reboot, the first openvpn-client@ instance I try to start takes >> almost exactly two minutes to start. The instances before that one start >> just fine in a few seconds. >> > Guess you meant: "The instances *after* ..." Yes I did. :) >> When that happens, I can see from journalctl that the client actually starts >> in the first few seconds after the systemctl command. But then, the command >> doesn't terminate for two more minutes (with no further journal entries). >> > Openvpn has quite good logging capabilities that you can put to use here. The output from OpenVPN indicates that the client is started within the first few seconds from when I give the `systemctl start openvpn-client@whatever` command (see previous email). The tun interface is created, opened, the routes are received and added to the routing table. All the usual stuff. Of course, I can also reach remote hosts through the VPN after that. The exact same thing (& output) happens if I try to start OpenVPN manually from the command line. Minus, of course, the two-minutes wait before the command returns. >> Has anyone seen this before? What could it be? >> > Without knowing more, my first guess is that you still don't have > connectivity when that first openvpn client starts. > 2 minutes matches exactly the 120 seconds default ping-restart parameter. So, > > what happens is, the client starts, you have > no connectivity then, after two minutes, ping-restart kicks in, and your > connection gets through. > So, get a network manager that can properly trigger network-online.target. > Or, if your network manager is triggering it, then > it means your network is not quite ready when it does. See above. I also forgot to specify it also happens when the system has been up for hours. It really can't be that the network is not ready. I don't think there's anything much that could be disturbing it. I'm using systemd-networkd for everything + iwd for wireless. Riccardo > Regards, > Giancarlo Razzolini
[arch-general] openvpn-client@ takes long time to start
After a reboot, the first openvpn-client@ instance I try to start takes almost exactly two minutes to start. The instances before that one start just fine in a few seconds. When that happens, I can see from journalctl that the client actually starts in the first few seconds after the systemctl command. But then, the command doesn't terminate for two more minutes (with no further journal entries). Has anyone seen this before? What could it be? Riccardo
[arch-general] mkinitcpio hook for custom root decryption with systemd boot
I have root encryption set up on my system and I currently boot with the sd-encrypt and sd-lvm hooks. I would like to change my current crypto setup in a way that would require more step to unlock the root than just typing in a passphares. For this reason, sd-encrypt clearly cannot serve my use case. For this reason, I would like to write a custom hook to mount the root volume. Now, systemd boot doesn't have a concept of runtime hooks. Thus, I need to make a systemd unit that gets pulled in by cryptsetup.target in the place of systemd-cryptsetup@.service. (Basically, I need to replace the whole systemd-cryptsetup-generator and systemd-cryptsetup logic.) However, I really have no idea on how to achieve this. Should I write a custom mkinitcpio hook which completely bypasses sd-crypt/cryptsetup.target and instead starts a different unit with my own decryption logic? Or is there a way to hook into cryptsetup.target and instruct it to pull in my logic instead of systemd-cryptsetup*? Of course, the other possibility is to just stop using a systemd boot and instead setting up a busybox early userspace. Then it's just a matter of writing a shell script. However, since I'm already using systemd for everything - from the bootloader to userspace - I don't think it makes much sense to do that. Any help/guidance/suggestion/criticism is highly appreciated. Riccardo Paolo Bestetti
[arch-general] OpenVPN systemd unit not prompting for password
I have a private key with a password. When I start OpenVPN with the openvpn command, all works fine. When I start it with the systemd unit (e.g. systemctl start openvpn-client@conf_file), a systemd-ask-password process is spawned from the unit but the prompt is not shown. Interestingly, the prompt is shown the I stop the unit. Riccardo Paolo Bestetti
[arch-general] My font rendering has changed
Since a few days ago, font rendering inside my desktop environment (SwayWM) seems to have changed. E.g. title bars are now rendered using a generic monospaced font instead of the usual one, and Termite does not seem to be able to load the Fira Code font and falls back to its default font. bemenu is also rendering differently and with a different font. I cannot find anything obvious in /var/log/pacman.log. I.e. I have done a full system upgrade lately but it doesn't seem to include anything that could have obviously caused this. Has anyone had anything similar? Where could I look to debug the issue? Best regards, Riccardo Paolo Bestetti
[arch-general] R: R: Eduroam madness with iwd
Christian,
That was it! Thank you for your help.
- Riccardo
Da: Christian Hesse
Inviato: Giovedì, 23 Gennaio, 2020 13:22
A: Riccardo Paolo Bestetti via arch-general
Cc: Riccardo Paolo Bestetti
Oggetto: Re: [arch-general] R: Eduroam madness with iwd
Riccardo Paolo Bestetti via arch-general on Thu,
2020/01/23 08:37:
> I'm going to have another chance at testing this on Monday. What else could
> I try?
Possibly missing something like this?
EAP-Identity=anonym...@unipmn.it
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}
[arch-general] R: Eduroam madness with iwd
Hi Christian,
Thank you for your response!
That's probably it for the systemd error. However, The connection issue
persists even when starting iwd manually, with the different error message.
I'm going to have another chance at testing this on Monday. What else could I
try?
-Riccardo
Da: Christian Hesse
Inviato: Mercoledì, 22 Gennaio, 2020 13:12
A: Riccardo Paolo Bestetti via arch-general
Cc: Riccardo Paolo Bestetti
Oggetto: Re: [arch-general] Eduroam madness with iwd
Riccardo Paolo Bestetti via arch-general on Wed,
2020/01/22 11:45:
> And the following error in the system journal:
> failed to load /home/random/.cat_installer/ca.pem
The certificate can not be loaded as iwd.service has ProtectHome=yes set.
Move it to a location where iwd can read it.
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}
[arch-general] Eduroam madness with iwd
Hi! I'm trying to configure iwd to connect to Eduroam. My home istitution requires EAP-TTLS authentication with PAP Phase 2. I have the following configuration file: [Security] EAP-Method=TTLS EAP-TTLS-CACert=/home/random/.cat_installer/ca.pem EAP-TTLS-ServerDomainMask=*.unipmn.it EAP-TTLS-Phase2-Method=Tunneled-PAP EAP-TTLS-Phase2-Identity=theUser EAP-TTLS-Phase2-Password=thePassword [Settings] AutoConnect=true When I try to connect with iwd started as a systemd unit, I get the following error in iwctl: Not configured. And the following error in the system journal: failed to load /home/random/.cat_installer/ca.pem (the certificate is valid and is in the required PEM format - I checked it with the openssl command and it also works with different network daemons) When I try to connect with iwd started manually with /usr/lib/iwd/iwd -d, I get the following error instead: Operation failed. And idw outputs: 4-Way handshake failed for ifindex: 3, reason: 23. I ran out of debugging ideas! Can anyone help? - Riccardo
