[systemd-devel] WLANInterfaceType="mesh-point" not matching
I currently have wpa_supplicant setup to connect my WLE600VX to my 802.11S mesh network. It connects fine. However when I setup my systemd.network file as the following. [Match] Name=wlp6s0 WLANInterfaceType="mesh-point" It doesn't want to match even though wlp6s0 is currently connected to my mesh. If I setup an AP on the same radio and then use WLANInterfaceType="ap" It matches fine. I've also tried WLANInterfaceType=mesh-point WLANInterfaceType=mp WLANInterfaceType=meshpoint None are matching. Am I using the wrong match keyword or is there possibly a bug. If it makes any difference I'm currently using systemd 246-r2 on Gentoo. Thanks, Paul Cabot ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
Hi,
On 10/26/20 12:52 PM, Dave Martin wrote:
On Mon, Oct 26, 2020 at 04:57:55PM +, Szabolcs Nagy via Libc-alpha wrote:
The 10/26/2020 16:24, Dave Martin via Libc-alpha wrote:
Unrolling this discussion a bit, this problem comes from a few sources:
1) systemd is trying to implement a policy that doesn't fit SECCOMP
syscall filtering very well.
2) The program is trying to do something not expressible through the
syscall interface: really the intent is to set PROT_BTI on the page,
with no intent to set PROT_EXEC on any page that didn't already have it
set.
This limitation of mprotect() was known when I originally added PROT_BTI,
but at that time we weren't aware of a clear use case that would fail.
Would it now help to add something like:
int mchangeprot(void *addr, size_t len, int old_flags, int new_flags)
{
int ret = -EINVAL;
mmap_write_lock(current->mm);
if (all vmas in [addr .. addr + len) have
their mprotect flags set to old_flags) {
ret = mprotect(addr, len, new_flags);
}
mmap_write_unlock(current->mm);
return ret;
}
if more prot flags are introduced then the exact
match for old_flags may be restrictive and currently
there is no way to query these flags to figure out
how to toggle one prot flag in a future proof way,
so i don't think this solves the issue completely.
Ack -- I illustrated this model because it makes the seccomp filter's
job easy, but it does have limitations.
i think we might need a new api, given that aarch64
now has PROT_BTI and PROT_MTE while existing code
expects RWX only, but i don't know what api is best.
An alternative option would be a call that sets / clears chosen
flags and leaves others unchanged.
I tend to favor a set/clear API, but that could also just be done by
creating a new PROT_BTI_IF_X which enables BTI for areas already set to
_EXEC. That goes right by the seccomp filters too, and actually is
closer to what glibc wants to do anyway.
The trouble with that is that the MDWX policy then becomes hard to
implement again.
But policies might be best set via another route, such as a prctl,
rather than being implemented completely in a seccomp filter.
Cheers
---Dave
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Which udev action is run on boot for my device?
W dniu 26.10.2020 o 11:19, Lennart Poettering pisze: On So, 25.10.20 18:56, Marcin Kocur (marcin2...@gmail.com) wrote: W dniu 25.10.2020 o 18:36, Marcin Kocur pisze: Hello, as the topic states, I want to know which action(s) from "add", "remove", "change", "move", "online", "offline", "bind", and "unbind" were triggered on my device. Is there any way to check that? At the beginning of /usr/lib/udev/rules.d/49-sane.rules there is: ACTION!="add", GOTO="libsane_rules_end" Udevadm info doesn't show libsane_matched property for my scanner. If I trigger the device manually with action "change", the variable is still not there, as per the rule. But if I trigger it with "add", the variable is there and also uaccess rule gets executed. So the ultimate quesiton is: what kind of trigger was executed on my device on boot time? Okay, it seems that "bind" is the action executed. I just edit the ACTION rule and restarted my PC until I found it. The introduction of "bind" and "unbind" is some major kernel API fuck-up btw. It's the main reason why packages should check for !="remove" rather than =="add|change" or so. udev rules written for old kernels simple didn't have to take "bind" and "unbind" into account. The fact that kernel just added that willy-nilly breaks rules all over the place. (that said, sane's apparent use of =="add" was always broken, i.e. the omission of "change", so even without the kernel bind/unbind mess the sane rules already were broken) Also see the NEWS note on the upcoming systemd version 247: https://github.com/systemd/systemd/blob/master/NEWS#L5 Is this intended? Should I report bug to systemd or sane? The scanner is connected to my PC all the time. sane. Ask them to run their rules on ACTION!="remove", i.e. on all actions but "remove". And that includes add, bind, change, unbding and everything else that might be added one day. Lennart -- Lennart Poettering, Berlin Thanks Lennart and Pekka, I drawed SANE's maintainers attention to this: https://gitlab.com/sane-project/backends/-/issues/371 https://gitlab.com/sane-project/backends/-/merge_requests/541 -- Pozdrawiam / Greetings Marcin Kocur █ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd prerelease 247-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v247-rc1.tar.gz NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: * KERNEL API INCOMPATIBILITY: Linux 4.12 introduced two new uevents "bind" and "unbind" to the Linux device model. When this kernel change was made, systemd-udevd was only minimally updated to handle and propagate these new event types. The introduction of these new uevents (which are typically generated for USB devices and devices needing a firmware upload before being functional) resulted in a number of issues which we so far didn't address. We hoped the kernel maintainers would themselves address these issues in some form, but that did not happen. To handle them properly, many (if not most) udev rules files shipped in various packages need updating, and so do many programs that monitor or enumerate devices with libudev or sd-device, or otherwise process uevents. Please note that this incompatibility is not fault of systemd or udev, but caused by an incompatible kernel change that happened back in Linux 4.12, but is becoming more and more visible as the new uevents are generated by more kernel drivers. To minimize issues resulting from this kernel change (but not avoid them entirely) starting with systemd-udevd 247 the udev "tags" concept (which is a concept for marking and filtering devices during enumeration and monitoring) has been reworked: udev tags are now "sticky", meaning that once a tag is assigned to a device it will not be removed from the device again until the device itself is removed (i.e. unplugged). This makes sure that any application monitoring devices that match a specific tag is guaranteed to both see uevents where the device starts being relevant, and those where it stops being relevant (the latter now regularly happening due to the new "unbind" uevent type). The udev tags concept is hence now a concept tied to a *device* instead of a device *event* — unlike for example udev properties whose lifecycle (as before) is generally tied to a device event, meaning that the previously determined properties are forgotten whenever a new uevent is processed. With the newly redefined udev tags concept, sometimes it's necessary to determine which tags are the ones applied by the most recent uevent/database update, in order to discern them from those originating from earlier uevents/database updates of the same device. To accommodate for this a new automatic property CURRENT_TAGS has been added that works similar to the existing TAGS property but only lists tags set by the most recent uevent/database update. Similarly, the libudev/sd-device API has been updated with new functions to enumerate these 'current' tags, in addition to the existing APIs that now enumerate the 'sticky' ones. To properly handle "bind"/"unbind" on Linux 4.12 and newer it is essential that all udev rules files and applications are updated to handle the new events. Specifically: • All rule files that currently use a header guard similar to ACTION!="add|change",GOTO="xyz_end" should be updated to use ACTION=="remove",GOTO="xyz_end" instead, so that the properties/tags they add are also applied whenever "bind" (or "unbind") is seen. (This is most important for all physical device types — those for which "bind" and "unbind" are currently generated, for all other device types this change is still recommended but not as important — but certainly prepares for future kernel uevent type additions). • Similarly, all code monitoring devices that contains an 'if' branch discerning the "add" + "change" uevent actions from all other uevents actions (i.e. considering devices only relevant after "add" or "change", and irrelevant on all other events) should be reworked to instead negatively check for "remove" only (i.e. considering devices relevant after all event types, except for "remove", which invalidates the device). Note that this also means that devices should be considered relevant on "unbind", even though conceptually this — in some form — invalidates the device. Since the precise
[systemd-devel] homectl --auto-login=yes has no effect
Hello! Latest Fedora Rawhide here. I've exactly one user created with --auto-login=yes /etc/gdm/custom.conf is unchanged and as far as I know, no .conf file is created in other places. How is --auto-login supposed to work? Should I open an issue on github? Thanks and BR, Damian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd vs. iwd
What are the state of things and the plan for the future with respect to iwd and systemd-networkd? A couple of years ago, I put together a satisfactory solution for my project in OpenEmbedded/Yocto using systemd-networkd to manage the IP connections and wpa_supplicant to manage the underlying Wi-Fi connection. Now it seems that Yocto has dropped wpa_supplicant in favor of iwd, and the iwd folks seem to want it to manage DHCP and routing in addition to the basic Level 2 connectivity. It also seems like systemd-networkd can still do the stuff it was doing before and that I can just use iwd to manage the Level 2. Am I going to write myself into another dead end if I keep using systemd-networkd for the network management and only use iwd for Level 2? Thanks! -- Bruce A. Johnson Herndon, Virginia USA ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
On Mon, Oct 26, 2020 at 03:56:35PM +, Dave Martin wrote: > On Mon, Oct 26, 2020 at 02:52:46PM +, Catalin Marinas via Libc-alpha > wrote: > > Now, if the dynamic loader silently ignores the mprotect() failure on > > the main executable, is there much value in exposing a flag in the aux > > vectors? It saves a few (one?) mprotect() calls but I don't think it > > matters much. Anyway, I don't mind the flag. > I don't see a problem with the aforementioned patch [2] to pre-set BTI > on the pages of the main binary. Me either FWIW. signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
* Dave Martin via Libc-alpha:
> Would it now help to add something like:
>
> int mchangeprot(void *addr, size_t len, int old_flags, int new_flags)
> {
> int ret = -EINVAL;
> mmap_write_lock(current->mm);
> if (all vmas in [addr .. addr + len) have
> their mprotect flags set to old_flags) {
>
> ret = mprotect(addr, len, new_flags);
> }
>
> mmap_write_unlock(current->mm);
> return ret;
> }
I suggested something similar as well. Ideally, the interface would
subsume pkey_mprotect, though, and have a separate flags argument from
the protection flags. But then we run into argument list length limits.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
On 26.10.2020 18.24, Dave Martin wrote:
On Wed, Oct 21, 2020 at 10:44:46PM -0500, Jeremy Linton via Libc-alpha wrote:
Hi,
There is a problem with glibc+systemd on BTI enabled systems. Systemd
has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny
PROT_EXEC changes. Glibc enables BTI only on segments which are marked as
being BTI compatible by calling mprotect PROT_EXEC|PROT_BTI. That call is
caught by the seccomp filter, resulting in service failures.
So, at the moment one has to pick either denying PROT_EXEC changes, or BTI.
This is obviously not desirable.
Various changes have been suggested, replacing the mprotect with mmap calls
having PROT_BTI set on the original mapping, re-mmapping the segments,
implying PROT_EXEC on mprotect PROT_BTI calls when VM_EXEC is already set,
and various modification to seccomp to allow particular mprotect cases to
bypass the filters. In each case there seems to be an undesirable attribute
to the solution.
So, whats the best solution?
Unrolling this discussion a bit, this problem comes from a few sources:
1) systemd is trying to implement a policy that doesn't fit SECCOMP
syscall filtering very well.
2) The program is trying to do something not expressible through the
syscall interface: really the intent is to set PROT_BTI on the page,
with no intent to set PROT_EXEC on any page that didn't already have it
set.
This limitation of mprotect() was known when I originally added PROT_BTI,
but at that time we weren't aware of a clear use case that would fail.
Would it now help to add something like:
int mchangeprot(void *addr, size_t len, int old_flags, int new_flags)
{
int ret = -EINVAL;
mmap_write_lock(current->mm);
if (all vmas in [addr .. addr + len) have
their mprotect flags set to old_flags) {
ret = mprotect(addr, len, new_flags);
}
mmap_write_unlock(current->mm);
return ret;
}
libc would now be able to do
mchangeprot(addr, len, PROT_EXEC | PROT_READ,
PROT_EXEC | PROT_READ | PROT_BTI);
while systemd's MDWX filter would reject the call if
(new_flags & PROT_EXEC) &&
(!(old_flags & PROT_EXEC) || (new_flags & PROT_WRITE)
This won't magically fix current code, but something along these lines
might be better going forward.
Thoughts?
Looks good to me.
-Topi
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures
On 26.10.2020 16.52, Catalin Marinas wrote: On Sat, Oct 24, 2020 at 02:01:30PM +0300, Topi Miettinen wrote: On 23.10.2020 12.02, Catalin Marinas wrote: On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote: Regardless, it makes sense to me to have the kernel load the executable itself with BTI enabled by default. I prefer gaining Catalin's suggested patch[2]. :) [...] [2] https://lore.kernel.org/linux-arm-kernel/20201022093104.GB1229@gaia/ I think I first heard the idea at Mark R ;). It still needs glibc changes to avoid the mprotect(), or at least ignore the error. Since this is an ABI change and we don't know which kernels would have it backported, maybe better to still issue the mprotect() but ignore the failure. What about kernel adding an auxiliary vector as a flag to indicate that BTI is supported and recommended by the kernel? Then dynamic loader could use that to detect that a) the main executable is BTI protected and there's no need to mprotect() it and b) PROT_BTI flag should be added to all PROT_EXEC pages. We could add a bit to AT_FLAGS, it's always been 0 for Linux. Great! In absence of the vector, the dynamic loader might choose to skip doing PROT_BTI at all (since the main executable isn't protected anyway either, or maybe even the kernel is up-to-date but it knows that it's not recommended for some reason, or maybe the kernel is so ancient that it doesn't know about BTI). Optionally it could still read the flag from ELF later (for compatibility with old kernels) and then do the mprotect() dance, which may trip seccomp filters, possibly fatally. I think the safest is for the dynamic loader to issue an mprotect() and ignore the EPERM error. Not all user deployments have this seccomp filter, so they can still benefit, and user can't tell whether the kernel change has been backported. But the seccomp filter can be set to kill the process, so that's definitely not the safest way. I think safest is that when the AT_FLAGS bit is seen, ld.so doesn't do any mprotect() calls but instead when mapping the segments, mmap() flags are adjusted to include PROT_BTI, so mprotect() calls are not necessary. If there's no seccomp filter, there's no disadvantage for avoiding the useless mprotect() calls. I'd expect the backported kernel change to include both aux vector and also using PROT_BTI for the main executable. Then the logic would work with backported kernels as well. If there's no aux vector, all bets are off. The kernel could be old and unpatched, even so old that PROT_BTI is not known. Perhaps also in the future there may be new technologies which have replaced BTI and the kernel could want a previous generation ld.so not to try to use BTI, so this could be also indicated with the lack of aux vector. The dynamic loader could still attempt to mprotect() the pages, but that could be fatal. Getting to the point where the error can be ignored means that there's no seccomp filter, at least none set to kill. Perhaps the pain is only temporary, new or patched kernels should eventually replace the old versions. Now, if the dynamic loader silently ignores the mprotect() failure on the main executable, is there much value in exposing a flag in the aux vectors? It saves a few (one?) mprotect() calls but I don't think it matters much. Anyway, I don't mind the flag. Saving a few system calls is indeed not an issue, but not being able to use MDWX and PROT_BTI simultaneously was the original problem (service failures). -Topi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Crond session, pam_access and pam_systemd
Hello, [I was off for one week] On 16/10/2020 15:45, Mantas Mikulėnas wrote: If I remember correctly, it's so that the main process would still be able to have pid 1 as its parent, without introducing an intermediate step in the process tree. My understanding after thinking about it would rather be : using PAMName= means that the process the service will execture (let's call it the service process) is to be considerred as PAM-ified even if it's not, which means a PAM session will be created for it. As such a sd-executor like process has to do on its behalf the begining of the PAM calls (the service process may not do any of this call) . And since this executor is replaced (because of exec()) with the actual service process) there is no other choice than to fork/exec before that the sd-pam handler (and thus monitor the pam_session "from the outside") If I'm correct, this would be the reason more than the pid 1 direct parenthood you mentionned. Otherwise, in the standard services (not using PAMName=) case this would work only with the type=forking services, wouldn't it ? Thanks for your help -- Thomas HUMMEL ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Which udev action is run on boot for my device?
On Mo, 26.10.20 11:28, Pekka Paalanen (ppaala...@gmail.com) wrote: > > So the ultimate quesiton is: what kind of trigger was executed on my > > device on boot time? > > > > Hi, > > FWIW, I was totally baffled by a similar problem with a DRM device. My > rule was doing the same thing: match to "add" and skip otherwise. My > rule did not appear to take effect at boot. > > The problem was not that "add" was not emitted - it was and processed > with my rule. The problem was that the DRM driver then shortly after > emitted also "changed" (this is how DRM communicates monitor hotplug > events). Because my rule did not match "change", the udev property I > was adding was effectively *removed*. IOW, any monitor hotplug would > cause my udev setting to disappear. > > Therefore I concluded that if you want your rule to apply always (e.g. > set a property that you expect to always find on the device), do not > filter it with ACTION at all. New actions could be added any time, and > then your rule breaks. At most, maybe it is safe to skip if > ACTION=="remove", but I'm not sure about even that. That is the correct way: check for the one "negative" action type (i.e. "remove"), and run your rules on all the other action types, i.e. on all "positive" action types. (Where "positive" means: the device exists and is there, and (mostly) useable, and "negative" means: the device doesn#t exist anymore) Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Which udev action is run on boot for my device?
On So, 25.10.20 18:56, Marcin Kocur (marcin2...@gmail.com) wrote: > W dniu 25.10.2020 o 18:36, Marcin Kocur pisze: > > Hello, > > > > as the topic states, I want to know which action(s) from "add", > > "remove", "change", "move", "online", "offline", "bind", and "unbind" > > were triggered on my device. Is there any way to check that? > > > > At the beginning of /usr/lib/udev/rules.d/49-sane.rules there is: > > > > ACTION!="add", GOTO="libsane_rules_end" > > > > Udevadm info doesn't show libsane_matched property for my scanner. > > > > If I trigger the device manually with action "change", the variable is > > still not there, as per the rule. > > > > But if I trigger it with "add", the variable is there and also uaccess > > rule gets executed. > > > > So the ultimate quesiton is: what kind of trigger was executed on my > > device on boot time? > > > Okay, it seems that "bind" is the action executed. I just edit the ACTION > rule and restarted my PC until I found it. The introduction of "bind" and "unbind" is some major kernel API fuck-up btw. It's the main reason why packages should check for !="remove" rather than =="add|change" or so. udev rules written for old kernels simple didn't have to take "bind" and "unbind" into account. The fact that kernel just added that willy-nilly breaks rules all over the place. (that said, sane's apparent use of =="add" was always broken, i.e. the omission of "change", so even without the kernel bind/unbind mess the sane rules already were broken) Also see the NEWS note on the upcoming systemd version 247: https://github.com/systemd/systemd/blob/master/NEWS#L5 > Is this intended? Should I report bug to systemd or sane? The scanner is > connected to my PC all the time. sane. Ask them to run their rules on ACTION!="remove", i.e. on all actions but "remove". And that includes add, bind, change, unbding and everything else that might be added one day. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Which udev action is run on boot for my device?
On So, 25.10.20 18:36, Marcin Kocur (marcin2...@gmail.com) wrote: > Hello, > > as the topic states, I want to know which action(s) from "add", "remove", > "change", "move", "online", "offline", "bind", and "unbind" were triggered > on my device. Is there any way to check that? > > At the beginning of /usr/lib/udev/rules.d/49-sane.rules there is: > > ACTION!="add", GOTO="libsane_rules_end" That's a poort choice typically. People should use ACTION=="remove" checks for this instead. I.e. there's exactly one "negative" action type, and that's "remove". All others should be considered "positive", as the device is still around when they happen. > Udevadm info doesn't show libsane_matched property for my scanner. > > If I trigger the device manually with action "change", the variable is still > not there, as per the rule. Yeah, the rule is broken. udev rules should be written in a style that a "change" event can be triggered any time, and the devices keep their properties. Writing rules that only set props on "add" are simply broken. They set all props on any event but "remove", see above. Please report to the upstream of the package in question. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Which udev action is run on boot for my device?
On Sun, 25 Oct 2020 18:36:42 +0100 Marcin Kocur wrote: > Hello, > > as the topic states, I want to know which action(s) from "add", > "remove", "change", "move", "online", "offline", "bind", and "unbind" > were triggered on my device. Is there any way to check that? > > At the beginning of /usr/lib/udev/rules.d/49-sane.rules there is: > > ACTION!="add", GOTO="libsane_rules_end" > > Udevadm info doesn't show libsane_matched property for my scanner. > > If I trigger the device manually with action "change", the variable is > still not there, as per the rule. > > But if I trigger it with "add", the variable is there and also uaccess > rule gets executed. > > So the ultimate quesiton is: what kind of trigger was executed on my > device on boot time? > Hi, FWIW, I was totally baffled by a similar problem with a DRM device. My rule was doing the same thing: match to "add" and skip otherwise. My rule did not appear to take effect at boot. The problem was not that "add" was not emitted - it was and processed with my rule. The problem was that the DRM driver then shortly after emitted also "changed" (this is how DRM communicates monitor hotplug events). Because my rule did not match "change", the udev property I was adding was effectively *removed*. IOW, any monitor hotplug would cause my udev setting to disappear. Therefore I concluded that if you want your rule to apply always (e.g. set a property that you expect to always find on the device), do not filter it with ACTION at all. New actions could be added any time, and then your rule breaks. At most, maybe it is safe to skip if ACTION=="remove", but I'm not sure about even that. The way I figured this out was adding udev.log_priority=debug to the kernel command line and looking at the resulting flood in the system log. Thanks, pq pgpdifiZYTX1J.pgp Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: [EXT] Re: date/time set to epoch when using readonly rootfs
>>> Lennart Poettering schrieb am 23.10.2020 um 13:00
in
Nachricht <20201023110051.GA326204@gardel-login>:
> On Fr, 23.10.20 10:37, Belisko Marek (marek.beli...@gmail.com) wrote:
>
>> > > Sorry I mixed up things. Can you pls guide where can I find code which
>> > > set date/time from timestamp? Thanks
>> >
>> > This is the stuff PID 1 calls during earliest boot:
>> >
>> >
https://github.com/systemd/systemd/blob/master/src/shared/clock‑util.c#L147
>> Thanks a lot. I found an issue. The build system set config flag
>> ‑time‑epoch=0 (reason was to avoid performing fsck on every boot when
>> inavlid date/time is detected for boards which don't have rtc [0])
>> and this resulted in date 1.1.1970.
>
> All RH‑based distro have patched the time check out of e2fsck since a
> long time. In particular in RTC‑less systems it sounds like a very
> poor idea to leave that in. The right fix is certainly to remove this
> behaviour from fsck, and not to force an unnecessarily wrong time.
Hi!
I don't know, but: Can't the time-based check be disabled by tuning the fs
("-i0"), or is there a special condition for "time zero"?
Also: Doesn't mean "fsck" a "journal replay" (read: very fast) these days?
Regards,
Ulrich
>
> Lennart
>
> ‑‑
> Lennart Poettering, Berlin
> ___
> systemd‑devel mailing list
> systemd‑de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd‑devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
