[systemd-devel] [EFI-Stub][ARM64] Cannot load unified-kernel.efi using systemd EFI stub
Hi system-devl team,
Nice to meet you.
I am having trouble to boot the unified-kernel image when using systemd's EFI
stub loader, I wanted to check in this community if I can get some help to fix
this problem.
Here are steps I followed:
I am using Debian package versions while checking this.
Systemd: 251~rc1
Bintutils(objcopy): 2.38
Kernel versio: 5.10
I built the kernel image for arm64:
kernel_image_file= linux_src/arch/arm64/boot/Image
Created unified kernel image using objcopy as below
(on arm64 machine)
```
objcopy \
--add-section .osrel="${os_release_file}" --change-section-vma
.osrel=0x2 \
--add-section .cmdline="${kernel_cmd_line_file}" --change-section-vma
.cmdline=0x3 \
--add-section .linux="${kernel_image_file}" --change-section-vma
.linux=0x200 \
--add-section .initrd="${initrd_image_file}" --change-section-vma
.initrd=0x300 \
/usr/lib/systemd/boot/efi/linuxaa64.efi.stub unified-kernel.efi ```
I tried to boot this unified-kernel image in EFI Shell environment and got the
below error ``` EFI shell> fs0:
FS0:\> unified-kernel.efi
call the kernel
EFI stub: Booting Linux Kernel...
EFI stub: Generating empty DTB
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path EFI stub:
Exiting boot services and installing virtual address map...
```
Looks like the kernel image file (Image) is loaded and went through kernel EFI
stub and then stuck, I didn’t any clue why this is stuck.
When I use uncompressed version of linux image (vmlinux) in objcopy, then it
got the error much earlier probably at EFI stub loader ``` EFI shell> fs0:
FS0:\> unified-kernel.efi
Command Error Status: Load Error
```
Can anyone suggest me how can I solve this?
Thanks,
Venkata.
Re: [systemd-devel] [SPAM] Re: Custom options and passing options via command line.
On Di, 10.05.22 18:29, Kamil Jońca (kjo...@op.pl) wrote:
> Lennart Poettering writes:
>
> > On Di, 10.05.22 17:59, Kamil Jońca (kjo...@op.pl) wrote:
> >
> >> Maybe I was not clear.
> >> I have ("internal") interfaces qemu1 and qemu2. and interface eth
> >> ("external")
> >> I wat to nat traffic from interface qemu1 via eth , but I do not want
> >> nat traffic from interface qemu2 via eth2/
> >>
> >> How to achieve this?
> >
> > hmm, eth? eth2? is the latter a typo?
> >
> > Assuming it is a typo: set IPMasquerade=yes only in the .network file
> > that matches qemu1, not the one matching qemu2.
> Wait.
> eth = interface which got (statically or by dhcp) address 192.168.1.1
> qemu1 = bridge interface with bunch of VMs, address 192.168.2.1 subnet /24
> qemu2 = bridge interface with bunch of VMs, address 192.168.3.1 subnet /24
>
> I want that outgoing via eth traffic from qemu1 was masquaraded to
> 192.168.1.1
> and also want that outgoing via eth traffic from qemu2 was not touched
> (ie. has have source addresses 192.168.3.0/24)
Yes. So for the two bridge interfaces, define two distinct .network
files, and set IPMasquerade=yes in one and leave it off in the other.
> >> Of course. Like most nontrivial things I want to do.
> >> That was my point.
> >
> > But why involve a callout at all if it's not dynamic?
> Why do you think it is not "dynamic"?
> Subnet for which I want to mask is given via ipsec (and I understand
> that this should be handled by ipsec scripts) or DHCP (how?)
Ah, well, OK so if the stuff is dynamic, but based on something else
than a network interface? then networkd is not the right place to
configure that.
Lennart
--
Lennart Poettering, Berlin
Re: [systemd-devel] systemd tries to terminate a process that seems to have exited
> The hint about non-empty cgroup + gap in PID sequence [1] suggest that > the parent and child are not the only two processes of the service. The gap in PIDs can be explained by a lot of processes starting at that moment. In that particular case: ``` May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service: About to execute /usr/local/bin/gnome-keyring-daemon --start --components pkcs11,secrets May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service: Forked /usr/local/bin/gnome-keyring-daemon as 310 ... May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-remote-desktop.service: About to execute /usr/libexec/gnome-remote-desktop-daemon May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-remote-desktop.service: Forked /usr/libexec/gnome-remote-desktop-daemon as 311 ... May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-session-monitor.service: About to execute /usr/libexec/gnome-session-ctl --monitor May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-session-monitor.service: Forked /usr/libexec/gnome-session-ctl as 312 ... May 09 17:52:47 cb6d1c84f84e systemd[106]: session-migration.service: About to execute /usr/bin/session-migration May 09 17:52:47 cb6d1c84f84e systemd[106]: session-migration.service: Forked /usr/bin/session-migration as 313 ``` About non-empty cgroup I'm not sure. The status is: ``` ● gnome-keyring.service - Start gnome-keyring for the Secrets Service, and PKCS #11 Loaded: loaded (/usr/lib/systemd/user/gnome-keyring.service; enabled; vendor preset: enabled) Active: deactivating (stop-sigterm) Process: 310 ExecStart=/usr/local/bin/gnome-keyring-daemon --start --components pkcs11,secrets (code=exited, status=0/SUCCESS) Main PID: 310 (code=exited, status=0/SUCCESS) CGroup: /docker/df654b46027c96861325528cba8f18aa65fb8c77986ffe7ce575a582334aff17/user.slice/user-1000.slice/user@1000.service/app.slice/gnome-keyring.service ``` Then changes to (when it times out): ``` × gnome-keyring.service - Start gnome-keyring for the Secrets Service, and PKCS #11 Loaded: loaded (/usr/lib/systemd/user/gnome-keyring.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Tue 2022-05-10 15:19:33 UTC; 315ms ago Process: 310 ExecStart=/usr/local/bin/gnome-keyring-daemon --start --components pkcs11,secrets (code=exited, status=0/SUCCESS) Main PID: 310 (code=exited, status=0/SUCCESS) ``` > [1] Can be parent's threads or concurrently spawned processes elsewhere in > the system. The processes that are related in one way or another... the gnome-keyring service which spawns one child (both exit): gnome-keyring-daemon --start --components pkcs11,secrets The org.freedesktop.secrets service (activated via dbus): gnome-keyring-daemon --start --foreground --components=secrets And the gnome-keyring-ssh service: gnome-keyring-daemon --start --components ssh Not a gnome-keyring expert, far from it. > That's very old. As far as most of the Debian project is concerned, > Debian 8 reached EOL in mid 2018. Yep, I'd like to know what's happening mainly out of curiosity (and maybe to learn something new). Because in my view it behaves really weird (like, "a process finishes, but it doesn't"). > To my knowledge Docker is not capable of running a proper > systemd-based userspace as a container. I.e. it does not implement > this: > https://systemd.io/CONTAINER_INTERFACE Well, I've managed to run GNOME in a docker container and connect to it over VNC: https://gist.github.com/x-yuri/dc6a9ce59ca823102903033da0143304 Although there's at least one major issue I haven't investigated yet. And there's also: https://hub.docker.com/r/jrei/systemd-ubuntu Which more or less worked for me under docker for another project. > As I understand, they are not interested in this, think this is out of > focus. Which is certainly their right. But if you want to run systemd > as container payload, then bettr use a different container manager, > like podman, lxc, systemd-spawn. They all are a lot more open to > supporting systemd as payload in a way that just works. Thanks for the suggestion, I'm considering them too. But I'd like to first find out what's happening here. > Docker is particularly borked when it comes to the way cgroups are set > up. And given that they are stuck on cgroupsv1 (or did that change?) i > see no perspective there. At least Docker 20.10.10 doesn't support it. > My educated guess: you are running in cgroupsv1 mode. cgroup empty > notifications do not work reliably in containers on cgroupsv1. Yep, in this case I'm using cgroupv1. Can this all be explained by "cgroup empty notifications do not work reliably in containers on cgroupsv1"? Adding `sleep 5` seems to resolve the issue, but I'm not sure if that's reliable. Let's put it this way, can the described behavior be explained like this? With cgroupv1 "empty cgroup" notifications in containers don't always reach systemd. As a result, if systemd doesn't receive an "empty
Re: [systemd-devel] [SPAM] Re: Custom options and passing options via command line.
Lennart Poettering writes:
> On Di, 10.05.22 17:59, Kamil Jońca (kjo...@op.pl) wrote:
>
>> Maybe I was not clear.
>> I have ("internal") interfaces qemu1 and qemu2. and interface eth
>> ("external")
>> I wat to nat traffic from interface qemu1 via eth , but I do not want
>> nat traffic from interface qemu2 via eth2/
>>
>> How to achieve this?
>
> hmm, eth? eth2? is the latter a typo?
>
> Assuming it is a typo: set IPMasquerade=yes only in the .network file
> that matches qemu1, not the one matching qemu2.
Wait.
eth = interface which got (statically or by dhcp) address 192.168.1.1
qemu1 = bridge interface with bunch of VMs, address 192.168.2.1 subnet /24
qemu2 = bridge interface with bunch of VMs, address 192.168.3.1 subnet /24
I want that outgoing via eth traffic from qemu1 was masquaraded to
192.168.1.1
and also want that outgoing via eth traffic from qemu2 was not touched
(ie. has have source addresses 192.168.3.0/24)
>
>> > If this does not deal in interfaces, but in IP addresses instead, no
>> > need to involve networkd. Just define the firewall outside of
>> > networkd?
>> Of course. Like most nontrivial things I want to do.
>> That was my point.
>
> But why involve a callout at all if it's not dynamic?
Why do you think it is not "dynamic"?
Subnet for which I want to mask is given via ipsec (and I understand
that this should be handled by ipsec scripts) or DHCP (how?)
KJ
--
http://wolnelektury.pl/wesprzyj/teraz/
Re: [systemd-devel] [SPAM] Re: Custom options and passing options via command line.
On Di, 10.05.22 17:59, Kamil Jońca (kjo...@op.pl) wrote:
> Maybe I was not clear.
> I have ("internal") interfaces qemu1 and qemu2. and interface eth ("external")
> I wat to nat traffic from interface qemu1 via eth , but I do not want
> nat traffic from interface qemu2 via eth2/
>
> How to achieve this?
hmm, eth? eth2? is the latter a typo?
Assuming it is a typo: set IPMasquerade=yes only in the .network file
that matches qemu1, not the one matching qemu2.
> > If this does not deal in interfaces, but in IP addresses instead, no
> > need to involve networkd. Just define the firewall outside of
> > networkd?
> Of course. Like most nontrivial things I want to do.
> That was my point.
But why involve a callout at all if it's not dynamic?
Lennart
--
Lennart Poettering, Berlin
Re: [systemd-devel] [SPAM] Re: Custom options and passing options via command line.
Lennart Poettering writes:
> On Mo, 09.05.22 20:00, Kamil Jońca (kjo...@op.pl) wrote:
>
>> Kamil Jońca writes:
>>
>>
>> > Let's see.
>> > from SYSTEMD.NETWORK(5)
>> > ...
>> > IPMasquerade=
>> >Configures IP masquerading for the network interface. If
>> >enabled, packets forwarded from the network interface will be
>> >appear as coming from the local host.
>> >
>> >
>> >
>> > I still do not know what mean "local host" here. I guess that this will
>> > be interface address. :)
>> >
>> > I still do not know if this is rather "snat" or rather "masquerade". How
>> > can I decide which to use. And what engine is used here.
>> >
>>
>> Another question:
>> 1. "partial nat"
>>3 interfaces qemu1 , qemu2, and eth
>>I want to nat treffic from qemu1 via eth but not qemu2
>>(NB this is the place, where I use mu custom option in
>>/etc/network/interfaces which means "NAT this traffic" )
>
> This sounds as if you just want to set IPMasquerade=yes on the
> .network file that matche's qemu1's interface, and that's it.
Maybe I was not clear.
I have ("internal") interfaces qemu1 and qemu2. and interface eth ("external")
I wat to nat traffic from interface qemu1 via eth , but I do not want
nat traffic from interface qemu2 via eth2/
How to achieve this?
>> 2. nat based on destination network.
>>
>> I want to nat only traffic to say, 192.168.10.0/24, leaving rest
>> untouched. (This is case when I have ipsec tunnel and I want to nat only
>> traffic to other endpoint)
>
> If this does not deal in interfaces, but in IP addresses instead, no
> need to involve networkd. Just define the firewall outside of
> networkd?
Of course. Like most nontrivial things I want to do.
That was my point.
KJ
--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Re: [systemd-devel] [SPAM] Re: Custom options and passing options via command line.
On Di, 10.05.22 17:46, Kamil Jońca (kjo...@op.pl) wrote: > Lennart Poettering writes: > > > On Di, 10.05.22 12:00, Kamil Jońca (kjo...@op.pl) wrote: > > > >> > The engine is decided at build time, i.e. can be either iptables or > >> > nftables. > >> > >> But there are two kind of "nat' in *tables suites: 1.masquerade or 2.snat. > > > > It uses DNAT or MASQUERADE. > > > >> Especially what wyould be equivalent of: > >> > >> --8<---cut here---start->8--- > >> iface qemu inet static > >> address 192.168.11.1 > >> netmask 255.255.255.0 > >> bridge_ports none > >> --8<---cut here---end--->8--- > >> This creates "bridge" with assigned IP, without any ports (and with > >> scripts it can create/drop some nftables rules ...) > > > > A .netdev file with Kind=bridge to create the bridge + a .network file > > that assigns an IP address to it? > > No. Does not work. interface is in "no-carrier" "configuring" state. ConfigureWithoutCarrier= Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] [SPAM] Re: Custom options and passing options via command line.
Lennart Poettering writes: > On Di, 10.05.22 12:00, Kamil Jońca (kjo...@op.pl) wrote: > >> > The engine is decided at build time, i.e. can be either iptables or >> > nftables. >> >> But there are two kind of "nat' in *tables suites: 1.masquerade or 2.snat. > > It uses DNAT or MASQUERADE. > >> Especially what wyould be equivalent of: >> >> --8<---cut here---start->8--- >> iface qemu inet static >> address 192.168.11.1 >> netmask 255.255.255.0 >> bridge_ports none >> --8<---cut here---end--->8--- >> This creates "bridge" with assigned IP, without any ports (and with >> scripts it can create/drop some nftables rules ...) > > A .netdev file with Kind=bridge to create the bridge + a .network file > that assigns an IP address to it? No. Does not work. interface is in "no-carrier" "configuring" state. > >> >> > Afaics RouteMetric= [DHCPv4] section already does all you need. just >> >> > give the iface whose default route you want to take precedence a lower >> >> > metric and you are done. >> >> >> >> How? By editing files? And what with other examples? >> > >> > I am not sure I follow? when do you intend to change the preference? >> >> When I manually up interface >> (ie. when, for example, issue comand networkctl up "interface name") > > We don#t support any explicit logic with that. But you can add a > drop-in for the .network file to /run/ and then reload before upping > the iface. So, that was my point. I will end with file editing and continuous daemon-reloading. Much less convenient. KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Re: [systemd-devel] systemd tries to terminate a process that seems to have exited
On Di, 10.05.22 08:44, Yuri Kanivetsky (yuri.kanivet...@gmail.com) wrote: > The one that produces the messages is 249.11 (that is running in a > docker container): > > https://packages.ubuntu.com/jammy/systemd > > The one running on the host is 215-17 (Debian 8). that's ancient... i figure this then also means you are stuck with cgroupv1. Which means cgroup empty notifications in containers typically don#t work. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd tries to terminate a process that seems to have exited
On Mo, 09.05.22 23:43, Yuri Kanivetsky (yuri.kanivet...@gmail.com) wrote: > Hi Andrei, > > Thanks for the suggestion. It becomes more verbose, but it still seems > like `systemd` fails to notice that `gnome-keyring` exited: > > May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service: > Passing 0 fds to service > May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service: > About to execute /usr/local/bin/gnome-keyring-daemon --start > --components pkcs11,secrets > May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service: > Forked /usr/local/bin/gnome-keyring-daemon as 310 > May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service: > Changed dead -> start > May 09 17:52:47 cb6d1c84f84e systemd[106]: Starting Start > gnome-keyring for the Secrets Service, and PKCS #11... > May 09 17:52:47 cb6d1c84f84e systemd[310]: Skipping PR_SET_MM, as > we don't have privileges. > May 09 17:52:47 cb6d1c84f84e systemd[310]: gnome-keyring.service: > Executing: /usr/local/bin/gnome-keyring-daemon --start --components > pkcs11,secrets My educated guess: you are running in cgroupsv1 mode. cgroup empty notifications do not work reliably in containers on cgroupsv1. Use cgroupsv2. (but i think docker doesn't support that) Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd tries to terminate a process that seems to have exited
On Do, 05.05.22 04:41, Yuri Kanivetsky (yuri.kanivet...@gmail.com) wrote: > Hi, > > This might be not a systemd issue. But the behavior is weird, and I'm not > sure. > > I'm trying to run GNOME in a docker container. And gnome-keyring > fails to start: To my knowledge Docker is not capable of running a proper systemd-based userspace as a container. I.e. it does not implement this: https://systemd.io/CONTAINER_INTERFACE As I understand, they are not interested in this, think this is out of focus. Which is certainly their right. But if you want to run systemd as container payload, then bettr use a different container manager, like podman, lxc, systemd-spawn. They all are a lot more open to supporting systemd as payload in a way that just works. Docker is particularly borked when it comes to the way cgroups are set up. And given that they are stuck on cgroupsv1 (or did that change?) i see no perspective there. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] [SPAM] Re: Custom options and passing options via command line.
On Mo, 09.05.22 20:00, Kamil Jońca (kjo...@op.pl) wrote: > Kamil Jońca writes: > > > > Let's see. > > from SYSTEMD.NETWORK(5) > > ... > > IPMasquerade= > >Configures IP masquerading for the network interface. If > >enabled, packets forwarded from the network interface will be > >appear as coming from the local host. > > > > > > > > I still do not know what mean "local host" here. I guess that this will > > be interface address. :) > > > > I still do not know if this is rather "snat" or rather "masquerade". How > > can I decide which to use. And what engine is used here. > > > > Another question: > 1. "partial nat" >3 interfaces qemu1 , qemu2, and eth >I want to nat treffic from qemu1 via eth but not qemu2 >(NB this is the place, where I use mu custom option in >/etc/network/interfaces which means "NAT this traffic" ) This sounds as if you just want to set IPMasquerade=yes on the .network file that matche's qemu1's interface, and that's it. > 2. nat based on destination network. > > I want to nat only traffic to say, 192.168.10.0/24, leaving rest > untouched. (This is case when I have ipsec tunnel and I want to nat only > traffic to other endpoint) If this does not deal in interfaces, but in IP addresses instead, no need to involve networkd. Just define the firewall outside of networkd? Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] [SPAM] Re: Custom options and passing options via command line.
On Di, 10.05.22 12:00, Kamil Jońca (kjo...@op.pl) wrote: > > The engine is decided at build time, i.e. can be either iptables or > > nftables. > > But there are two kind of "nat' in *tables suites: 1.masquerade or 2.snat. It uses DNAT or MASQUERADE. > Especially what wyould be equivalent of: > > --8<---cut here---start->8--- > iface qemu inet static > address 192.168.11.1 > netmask 255.255.255.0 > bridge_ports none > --8<---cut here---end--->8--- > This creates "bridge" with assigned IP, without any ports (and with > scripts it can create/drop some nftables rules ...) A .netdev file with Kind=bridge to create the bridge + a .network file that assigns an IP address to it? > >> > Afaics RouteMetric= [DHCPv4] section already does all you need. just > >> > give the iface whose default route you want to take precedence a lower > >> > metric and you are done. > >> > >> How? By editing files? And what with other examples? > > > > I am not sure I follow? when do you intend to change the preference? > > When I manually up interface > (ie. when, for example, issue comand networkctl up "interface name") We don#t support any explicit logic with that. But you can add a drop-in for the .network file to /run/ and then reload before upping the iface. networkd always wants a complete, declarative idea of what it is supposed to configure, so that it can adjust things to that. by doing callouts that modify state you lose that ability, since networkd never has a complete idea of what is supposed to be in effect, and once you reload config things will be very confusing. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Relationship between cgroup hierarchy and slice names
On Do, 05.05.22 19:12, Yeongjin Kwon (yeongjink...@gmail.com) wrote: > On Thu, May 5, 2022 at 11:17 AM Lennart Poettering > wrote: > > > > On Do, 05.05.22 10:44, Yeongjin Kwon (yeongjink...@gmail.com) wrote: > > > > > On Wed, May 4, 2022 at 4:03 AM Lennart Poettering > > > wrote: > > > > > > > > The slice names match 1:1 to the position in the cgroup tree, that's > > > > where they were designed. > > > > > > > > Basically our rule is: if the object unit types encapsulates > > > > already have a file system path as name then we don't allow you to > > > > make up a new name, but insist that the unit name is derived from that > > > > pre-existing file system path. > > > > > > I see, thank you for responding. > > > > > > Then would it be possible to somehow override the "Slice" property for > > > all units underneath the slice so that it points to another, custom > > > created slice? Maybe using some conditional overriding mechanism? > > > > You can override the slice for any non-slice unit that is backed by a > > cgroup via a dropin that overrides Slice=. > > > > But maybe I don#t grok your question. > > Sorry if I was being unclear. > > I want to relocate all non-slice units that are in a slice to a > different slice. I know I can do this by overriding Slice= > individually for each unit with a dropin, but that would be tedious > and prone to flaws. For example, if a package put a unit under the > slice that I wanted to move all units from, then I would have to > override that new unit as well, which I might forget to do. I could > use a post-install script, but that may not be the best solution > either. And so I was wondering if there was a way to automatically > override all units that are under the slice, without having to > override Slice= for each of them individually. Since I haven't seen > anything like this so far, I guess this is also a sort of feature > request. There's no such feature. But how would it even work? if you say "everything in foo.slice should now be in bar.slice". but once you say it, these units would be in bar.slice so the rule doesn't apply anymore... it's messy to use a property as matching parameter that is also the parameter you want to change, because then things cannot possibly be declarative/idempotent anymore... Note that systemd units allow hierarchal drop-ins. i.e. the drop-in directory "foo-.service.d/" is read for all units matching the glob pattern "foo-*.service". Thus, if you want to migrate a bunch of units at once, you could do so — as long as you enforce a naming scheme that makes all units that "belong together" use the same name prefix. In the past we had some discussion to have a global setting DefaultSlice=, which would allow changing which slice to default to for units that don't specify it. (i.e instead of system.slice). But I am not convinced this really makes too much sense... Anyway, I don't really grok the usecase... Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Relationship between cgroup hierarchy and slice names
Hello.
On Tue, May 03, 2022 at 08:16:48PM -0400, Yeongjin Kwon
wrote:
> I'm trying to override the parent slice of a certain slice unit so I can
> reorganize the cgroup hierarchy.
I'm wondering is the certain slice or its parent any of the systemd
implicit slices ({user,user-,system,machine}.slice,...)?
Or you just want to override a hierarchy defined by some 3rd party
units (perhaps with a purpose)?
Thanks,
Michal
Re: [systemd-devel] systemd tries to terminate a process that seems to have exited
On Tue, 10 May 2022 at 08:44:27 +0300, Yuri Kanivetsky wrote: > The one running on the host is 215-17 (Debian 8). That's very old. As far as most of the Debian project is concerned, Debian 8 reached EOL in mid 2018. There is a separate Debian LTS team which picks up security support when the main Debian security team drops a release, but they also stopped supporting Debian 8 in mid 2020. If you are using ELTS (a third-party commercial offering), I'd suggest talking to the ELTS maintainers, rather than upstream or Debian - particularly if you are also using a Debian-8-derived kernel. smcv
Re: [systemd-devel] [SPAM] Re: Custom options and passing options via command line.
Lennart Poettering writes: > On Mo, 09.05.22 19:13, Kamil Jońca (kjo...@fastmail.com) wrote: > >> >> 3. decide where to resolve names based on domain and existence of ipsec >> >> or openvpn tunnel. >> > >> > Sounds like a job for the resolved domain routing logic, which already >> > exists? >> >> Not quite. When I asked previously I got response, that resolved is >> based on interfaces. But ipsec tunnel does not need dedicated >> interface. > > but networkd-dispatcher stuff is also interface based, no? so it > wouldn't solve your problem either? In my previous post I wrote about *resolved*" - when I tested systemd-RESOLVED* could not fit my needs (and I am happy dnsmasq user then) > >> I still do not know what mean "local host" here. I guess that this will >> be interface address. :) > > Yes. > >> I still do not know if this is rather "snat" or rather "masquerade". How >> can I decide which to use. And what engine is used here. > > The engine is decided at build time, i.e. can be either iptables or > nftables. But there are two kind of "nat' in *tables suites: 1.masquerade or 2.snat. > >> I know that networkd cannot handle bridge without ports (quite >> convenient when you use it as dummy interface with qemu machines) > > It cannot? As far as I know - it cannot. Bridge without ports have no ip assigned and is in "configuring" state. Please correct me if I am wrong Especially what wyould be equivalent of: --8<---cut here---start->8--- iface qemu inet static address 192.168.11.1 netmask 255.255.255.0 bridge_ports none --8<---cut here---end--->8--- This creates "bridge" with assigned IP, without any ports (and with scripts it can create/drop some nftables rules ...) >> > Afaics RouteMetric= [DHCPv4] section already does all you need. just >> > give the iface whose default route you want to take precedence a lower >> > metric and you are done. >> >> How? By editing files? And what with other examples? > > I am not sure I follow? when do you intend to change the preference? When I manually up interface (ie. when, for example, issue comand networkctl up "interface name") >> > Note anyway that networkd assumes it manages an interface in its >> > entirety: if you muck with what it sets up it likely will override >> > your changes sooner or later, when some event happens... you have a >> >> I do not want interfere with interfaces "per se" I simply want to get >> some info from systemd and pass it to dnsmasq (for DNS) or nftables (for >> filtering) . That's it. > > You started out asking about default routes? Yes, but in https://lists.freedesktop.org/archives/systemd-devel/2022-May/047907.html I wrote: "[1] - but please treat this as an example only. This also can be additional domain to search. Or additional DNS to use, or ... something." KJ
Re: [systemd-devel] Custom options and passing options via command line.
On 08.05.2022 20:19, Kamil Jońca wrote: > I have question about custom options in network interface definitions > and passing it via command line. > In currend Debian tools > > (https://manpages.debian.org/buster/ifupdown/interfaces.5.en.html) > there is a possibility to define custom option and passing it to up/down > script (see ENVIRONMENT VARIABLES section) > Is it possible in *.network files? > > Moreover: can I pass option during interface up/down? > For example, in my if-up*/if-down* scripts I have code for replacing (or > not!) default route when needed.[1] > > Then I can execute something like: > > --8<---cut here---start->8--- > ifup wlan0 -o replacedefaultroute=on > --8<---cut here---end--->8--- > > how I can achieve this with networkctl (or other systemd tool)? > > KJ > [1] > in man systemd.network > I found > > [DHCPV4] > UseRoutes= > > but I am not sure if this is about default routes or only classless > static routes > Default route is UseGateway option which defaults to the value of UseRoutes option.
Re: [systemd-devel] [SPAM] Re: Custom options and passing options via command line.
On Mo, 09.05.22 19:13, Kamil Jońca (kjo...@fastmail.com) wrote: > >> 3. decide where to resolve names based on domain and existence of ipsec > >> or openvpn tunnel. > > > > Sounds like a job for the resolved domain routing logic, which already > > exists? > > Not quite. When I asked previously I got response, that resolved is > based on interfaces. But ipsec tunnel does not need dedicated > interface. but networkd-dispatcher stuff is also interface based, no? so it wouldn't solve your problem either? > I still do not know what mean "local host" here. I guess that this will > be interface address. :) Yes. > I still do not know if this is rather "snat" or rather "masquerade". How > can I decide which to use. And what engine is used here. The engine is decided at build time, i.e. can be either iptables or nftables. > I know that networkd cannot handle bridge without ports (quite > convenient when you use it as dummy interface with qemu machines) It cannot? > > Afaics RouteMetric= [DHCPv4] section already does all you need. just > > give the iface whose default route you want to take precedence a lower > > metric and you are done. > > How? By editing files? And what with other examples? I am not sure I follow? when do you intend to change the preference? > > Note anyway that networkd assumes it manages an interface in its > > entirety: if you muck with what it sets up it likely will override > > your changes sooner or later, when some event happens... you have a > > I do not want interfere with interfaces "per se" I simply want to get > some info from systemd and pass it to dnsmasq (for DNS) or nftables (for > filtering) . That's it. You started out asking about default routes? Lennart -- Lennart Poettering, Berlin
