* [PATCH] rng-tools: add systemd-udev-settle wants to service @ 2021-09-17 8:08 Claudius Heine 2022-02-02 12:38 ` [OE-core] " Kyle Russell 0 siblings, 1 reply; 29+ messages in thread From: Claudius Heine @ 2021-09-17 8:08 UTC (permalink / raw) To: openembedded-core Cc: Marek Vasut, Alex Kiernan, Alexander Kanavin, Alban Bedel, Claudius Heine rngd needs to start after `systemd-udev-settle` in order for the kernel modules of the random source hardware to be loaded before it is started. However, since the `rngd.service` does not require or want `systemd-udev-settle.service` it might not be scheduled for start and the `After=systemd-udev-settle.service` there has no effect. Adding `Wants=systemd-udev-settle.service` provides a weak requirement to it, so that the `rngd` is started after it, if possible. Signed-off-by: Claudius Heine <ch@denx.de> --- Hi, this is a fix, which should probably be backported to the maintained releases. regards, Claudius meta/recipes-support/rng-tools/rng-tools/rngd.service | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service b/meta/recipes-support/rng-tools/rng-tools/rngd.service index 0559b97991..568686e80e 100644 --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service @@ -3,6 +3,7 @@ Description=Hardware RNG Entropy Gatherer Daemon DefaultDependencies=no After=systemd-udev-settle.service Before=sysinit.target shutdown.target +Wants=systemd-udev-settle.service Conflicts=shutdown.target [Service] -- 2.33.0 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service 2021-09-17 8:08 [PATCH] rng-tools: add systemd-udev-settle wants to service Claudius Heine @ 2022-02-02 12:38 ` Kyle Russell 2022-02-02 13:08 ` Claudius Heine 0 siblings, 1 reply; 29+ messages in thread From: Kyle Russell @ 2022-02-02 12:38 UTC (permalink / raw) To: Claudius Heine Cc: OE-core, Marek Vasut, Alex Kiernan, Alexander Kanavin, Alban Bedel, Wes Lindauer [-- Attachment #1: Type: text/plain, Size: 2075 bytes --] Is this the correct approach? Even the systemd-udev-settle.service man pages recommends not using its service. Were the kernel modules really not loaded when rngd started? Or is the original problem just a matter of waiting for sufficient entropy? On Fri, Sep 17, 2021 at 4:08 AM Claudius Heine <ch@denx.de> wrote: > rngd needs to start after `systemd-udev-settle` in order for the kernel > modules of the random source hardware to be loaded before it is started. > > However, since the `rngd.service` does not require or want > `systemd-udev-settle.service` it might not be scheduled for start and > the `After=systemd-udev-settle.service` there has no effect. > > Adding `Wants=systemd-udev-settle.service` provides a weak requirement > to it, so that the `rngd` is started after it, if possible. > > Signed-off-by: Claudius Heine <ch@denx.de> > --- > > Hi, > > this is a fix, which should probably be backported to the maintained > releases. > > regards, > Claudius > > meta/recipes-support/rng-tools/rng-tools/rngd.service | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service > b/meta/recipes-support/rng-tools/rng-tools/rngd.service > index 0559b97991..568686e80e 100644 > --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service > +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service > @@ -3,6 +3,7 @@ Description=Hardware RNG Entropy Gatherer Daemon > DefaultDependencies=no > After=systemd-udev-settle.service > Before=sysinit.target shutdown.target > +Wants=systemd-udev-settle.service > Conflicts=shutdown.target > > [Service] > -- > 2.33.0 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#156129): > https://lists.openembedded.org/g/openembedded-core/message/156129 > Mute This Topic: https://lists.openembedded.org/mt/85671578/4454381 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > bkylerussell@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > > [-- Attachment #2: Type: text/html, Size: 3013 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service 2022-02-02 12:38 ` [OE-core] " Kyle Russell @ 2022-02-02 13:08 ` Claudius Heine 2022-02-02 16:26 ` Kyle Russell 0 siblings, 1 reply; 29+ messages in thread From: Claudius Heine @ 2022-02-02 13:08 UTC (permalink / raw) To: Kyle Russell Cc: OE-core, Marek Vasut, Alex Kiernan, Alexander Kanavin, Alban Bedel, Wes Lindauer Hi Kyle, On 2022-02-02 13:38, Kyle Russell wrote: > Is this the correct approach? Even the systemd-udev-settle.service man > pages recommends not using its service. Were the kernel modules really > not loaded when rngd started? Or is the original problem just a matter > of waiting for sufficient entropy? IIRC, the rngd could not find any random source device node (/dev/hwrng in that case), so the service failed to start. The patch you are commenting on only adds `Wants` weak dependency to make sure `systemd-udev-settle.service` is pulled in to the job queue, the `After` ordering rule was already there. So changing this service file to be triggered by a udev event or maybe wrap it in a script, which makes sure the right modules are loaded and device nodes are available, could be an improvement, but it would be out of scope of this patch IMO. regards, Claudius > > On Fri, Sep 17, 2021 at 4:08 AM Claudius Heine <ch@denx.de > <mailto:ch@denx.de>> wrote: > > rngd needs to start after `systemd-udev-settle` in order for the kernel > modules of the random source hardware to be loaded before it is started. > > However, since the `rngd.service` does not require or want > `systemd-udev-settle.service` it might not be scheduled for start and > the `After=systemd-udev-settle.service` there has no effect. > > Adding `Wants=systemd-udev-settle.service` provides a weak requirement > to it, so that the `rngd` is started after it, if possible. > > Signed-off-by: Claudius Heine <ch@denx.de <mailto:ch@denx.de>> > --- > > Hi, > > this is a fix, which should probably be backported to the maintained > releases. > > regards, > Claudius > > meta/recipes-support/rng-tools/rng-tools/rngd.service | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service > b/meta/recipes-support/rng-tools/rng-tools/rngd.service > index 0559b97991..568686e80e 100644 > --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service > +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service > @@ -3,6 +3,7 @@ Description=Hardware RNG Entropy Gatherer Daemon > DefaultDependencies=no > After=systemd-udev-settle.service > Before=sysinit.target shutdown.target > +Wants=systemd-udev-settle.service > Conflicts=shutdown.target > > [Service] > -- > 2.33.0 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#156129): > https://lists.openembedded.org/g/openembedded-core/message/156129 > <https://lists.openembedded.org/g/openembedded-core/message/156129> > Mute This Topic: https://lists.openembedded.org/mt/85671578/4454381 > <https://lists.openembedded.org/mt/85671578/4454381> > Group Owner: openembedded-core+owner@lists.openembedded.org > <mailto:openembedded-core%2Bowner@lists.openembedded.org> > Unsubscribe: > https://lists.openembedded.org/g/openembedded-core/unsub > <https://lists.openembedded.org/g/openembedded-core/unsub> > [bkylerussell@gmail.com <mailto:bkylerussell@gmail.com>] > -=-=-=-=-=-=-=-=-=-=-=- > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service 2022-02-02 13:08 ` Claudius Heine @ 2022-02-02 16:26 ` Kyle Russell 2022-02-03 8:35 ` Claudius Heine 0 siblings, 1 reply; 29+ messages in thread From: Kyle Russell @ 2022-02-02 16:26 UTC (permalink / raw) To: Claudius Heine Cc: OE-core, Marek Vasut, Alex Kiernan, Alexander Kanavin, Alban Bedel, Wes Lindauer [-- Attachment #1: Type: text/plain, Size: 4206 bytes --] Thanks, Claudius. On Wed, Feb 2, 2022 at 8:08 AM Claudius Heine <ch@denx.de> wrote: > Hi Kyle, > > On 2022-02-02 13:38, Kyle Russell wrote: > > Is this the correct approach? Even the systemd-udev-settle.service man > > pages recommends not using its service. Were the kernel modules really > > not loaded when rngd started? Or is the original problem just a matter > > of waiting for sufficient entropy? > > IIRC, the rngd could not find any random source device node (/dev/hwrng > in that case), so the service failed to start. > If /dev/hwrng didn't exist, this feels like the original problem was a misconfigured kernel or module that wasn't being loaded properly. > The patch you are commenting on only adds `Wants` weak dependency to > make sure `systemd-udev-settle.service` is pulled in to the job queue, > the `After` ordering rule was already there. > Correct. Just because an `After` exists does not mean the service gets pulled into the job queue, so prior to this change no other service was causing the deprecated systemd-udev-settle.service to be run during boot. But now, every device including openssh (which has a default PACKAGECONFIG option for rng-tools) now depends on this deprecated service, which may cause unexpected boot delays. > So changing this service file to be triggered by a udev event or maybe > wrap it in a script, which makes sure the right modules are loaded and > device nodes are available, could be an improvement, but it would be out > of scope of this patch IMO. > I'm more curious whether this change should be reverted from upstream. It seems like a drop-in file could have been applied to your distro instead of adding a dependency on a deprecated service for all openssh users. Kyle > > > > On Fri, Sep 17, 2021 at 4:08 AM Claudius Heine <ch@denx.de > > <mailto:ch@denx.de>> wrote: > > > > rngd needs to start after `systemd-udev-settle` in order for the > kernel > > modules of the random source hardware to be loaded before it is > started. > > > > However, since the `rngd.service` does not require or want > > `systemd-udev-settle.service` it might not be scheduled for start and > > the `After=systemd-udev-settle.service` there has no effect. > > > > Adding `Wants=systemd-udev-settle.service` provides a weak > requirement > > to it, so that the `rngd` is started after it, if possible. > > > > Signed-off-by: Claudius Heine <ch@denx.de <mailto:ch@denx.de>> > > --- > > > > Hi, > > > > this is a fix, which should probably be backported to the maintained > > releases. > > > > regards, > > Claudius > > > > meta/recipes-support/rng-tools/rng-tools/rngd.service | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service > > b/meta/recipes-support/rng-tools/rng-tools/rngd.service > > index 0559b97991..568686e80e 100644 > > --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service > > +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service > > @@ -3,6 +3,7 @@ Description=Hardware RNG Entropy Gatherer Daemon > > DefaultDependencies=no > > After=systemd-udev-settle.service > > Before=sysinit.target shutdown.target > > +Wants=systemd-udev-settle.service > > Conflicts=shutdown.target > > > > [Service] > > -- > > 2.33.0 > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > > Links: You receive all messages sent to this group. > > View/Reply Online (#156129): > > https://lists.openembedded.org/g/openembedded-core/message/156129 > > <https://lists.openembedded.org/g/openembedded-core/message/156129> > > Mute This Topic: https://lists.openembedded.org/mt/85671578/4454381 > > <https://lists.openembedded.org/mt/85671578/4454381> > > Group Owner: openembedded-core+owner@lists.openembedded.org > > <mailto:openembedded-core%2Bowner@lists.openembedded.org> > > Unsubscribe: > > https://lists.openembedded.org/g/openembedded-core/unsub > > <https://lists.openembedded.org/g/openembedded-core/unsub> > > [bkylerussell@gmail.com <mailto:bkylerussell@gmail.com>] > > -=-=-=-=-=-=-=-=-=-=-=- > > > [-- Attachment #2: Type: text/html, Size: 6884 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service 2022-02-02 16:26 ` Kyle Russell @ 2022-02-03 8:35 ` Claudius Heine 2022-02-03 14:12 ` Kyle Russell 0 siblings, 1 reply; 29+ messages in thread From: Claudius Heine @ 2022-02-03 8:35 UTC (permalink / raw) To: Kyle Russell Cc: OE-core, Marek Vasut, Alex Kiernan, Alexander Kanavin, Alban Bedel, Wes Lindauer On 2022-02-02 17:26, Kyle Russell wrote: > Thanks, Claudius. > > On Wed, Feb 2, 2022 at 8:08 AM Claudius Heine <ch@denx.de > <mailto:ch@denx.de>> wrote: > > Hi Kyle, > > On 2022-02-02 13:38, Kyle Russell wrote: > > Is this the correct approach? Even the > systemd-udev-settle.service man > > pages recommends not using its service. Were the kernel modules > really > > not loaded when rngd started? Or is the original problem just a > matter > > of waiting for sufficient entropy? > > IIRC, the rngd could not find any random source device node (/dev/hwrng > in that case), so the service failed to start. > > > If /dev/hwrng didn't exist, this feels like the original problem was a > misconfigured > kernel or module that wasn't being loaded properly. Yes, however it is a timing issue. The module was loaded properly at bootup, however at the time rngd was started the module was not loaded yet and thus the service fails to start. If it would be delayed until the module is loaded everything would be fine. It does not happen if the module is compiled into the kernel or if a initramfs is used which loads the module (I think). I our case it happend with the caam module as an external module loaded on boot from the real root file system. > The patch you are commenting on only adds `Wants` weak dependency to > make sure `systemd-udev-settle.service` is pulled in to the job queue, > the `After` ordering rule was already there. > > > Correct. Just because an `After` exists does not mean the service gets > pulled into > the job queue, so prior to this change no other service was causing the > deprecated > systemd-udev-settle.service to be run during boot. But now, every > device including > openssh (which has a default PACKAGECONFIG option for rng-tools) now depends > on this deprecated service, which may cause unexpected boot delays. > > So changing this service file to be triggered by a udev event or maybe > wrap it in a script, which makes sure the right modules are loaded and > device nodes are available, could be an improvement, but it would be > out > of scope of this patch IMO. > > > I'm more curious whether this change should be reverted from upstream. > It seems > like a drop-in file could have been applied to your distro instead of > adding a dependency > on a deprecated service for all openssh users. This patch just adds a missing entry into the service file. If you have solved the described issue in some way and can revert this patch and remove the `Wants=systemd-udev-settle.service` then you can also remove the `After=systemd-udev-settle.service` at the same time and at that point you can just remove both of those entries directly in the patch that solved the timing issue. I agree that `systemd-udev-settle.service` should probably not be used anymore, however that file already used it in a non-functional way and all this patch did was make it fulfill its intended function. In retrospect I probably should have tried to find a way to remove the usage of `systemd-udev-settle.service` completely, when I looked into the issue, however all this patch in essence does is revive dead code, which was already in place. Also I think at that time I couldn't find a more precise instrument in systemds massive toolbox to delay the start of rngd and services that should be started in succession until the just the hardware random generator device is ready and `After=systemd-udev-settle.service` was already there. I guess some `ExecStartPre=` script which delays the start until the conditions are met could be implemented, but that seems a bit hackish. regards, Claudius ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service 2022-02-03 8:35 ` Claudius Heine @ 2022-02-03 14:12 ` Kyle Russell 2022-07-21 15:17 ` Drew Moseley 0 siblings, 1 reply; 29+ messages in thread From: Kyle Russell @ 2022-02-03 14:12 UTC (permalink / raw) To: Claudius Heine Cc: OE-core, Marek Vasut, Alex Kiernan, Alexander Kanavin, Alban Bedel, Wes Lindauer [-- Attachment #1: Type: text/plain, Size: 4413 bytes --] Thanks, Claudius. I really appreciate your responses. I'm not trying to be pedantic. Since I don't have your test setup, I was just trying to make sure I understood the context of the problem as I figure out how to deal with issues this is causing in our setup. I was also hoping one of the recipe maintainers of either systemd or rng-tools would comment on systemd-udev-settle. I'll take a look at the caam module to see if I can understand how it works. On Thu, Feb 3, 2022 at 3:35 AM Claudius Heine <ch@denx.de> wrote: > On 2022-02-02 17:26, Kyle Russell wrote: > > Thanks, Claudius. > > > > On Wed, Feb 2, 2022 at 8:08 AM Claudius Heine <ch@denx.de > > <mailto:ch@denx.de>> wrote: > > > > Hi Kyle, > > > > On 2022-02-02 13:38, Kyle Russell wrote: > > > Is this the correct approach? Even the > > systemd-udev-settle.service man > > > pages recommends not using its service. Were the kernel modules > > really > > > not loaded when rngd started? Or is the original problem just a > > matter > > > of waiting for sufficient entropy? > > > > IIRC, the rngd could not find any random source device node > (/dev/hwrng > > in that case), so the service failed to start. > > > > > > If /dev/hwrng didn't exist, this feels like the original problem was a > > misconfigured > > kernel or module that wasn't being loaded properly. > > Yes, however it is a timing issue. The module was loaded properly at > bootup, however at the time rngd was started the module was not loaded > yet and thus the service fails to start. If it would be delayed until > the module is loaded everything would be fine. > > It does not happen if the module is compiled into the kernel or if a > initramfs is used which loads the module (I think). I our case it > happend with the caam module as an external module loaded on boot from > the real root file system. > > > The patch you are commenting on only adds `Wants` weak dependency to > > make sure `systemd-udev-settle.service` is pulled in to the job > queue, > > the `After` ordering rule was already there. > > > > > > Correct. Just because an `After` exists does not mean the service gets > > pulled into > > the job queue, so prior to this change no other service was causing the > > deprecated > > systemd-udev-settle.service to be run during boot. But now, every > > device including > > openssh (which has a default PACKAGECONFIG option for rng-tools) now > depends > > on this deprecated service, which may cause unexpected boot delays. > > > > So changing this service file to be triggered by a udev event or > maybe > > wrap it in a script, which makes sure the right modules are loaded > and > > device nodes are available, could be an improvement, but it would be > > out > > of scope of this patch IMO. > > > > > > I'm more curious whether this change should be reverted from upstream. > > It seems > > like a drop-in file could have been applied to your distro instead of > > adding a dependency > > on a deprecated service for all openssh users. > > This patch just adds a missing entry into the service file. If you have > solved the described issue in some way and can revert this patch and > remove the `Wants=systemd-udev-settle.service` then you can also remove > the `After=systemd-udev-settle.service` at the same time and at that > point you can just remove both of those entries directly in the patch > that solved the timing issue. > > I agree that `systemd-udev-settle.service` should probably not be used > anymore, however that file already used it in a non-functional way and > all this patch did was make it fulfill its intended function. > > In retrospect I probably should have tried to find a way to remove the > usage of `systemd-udev-settle.service` completely, when I looked into > the issue, however all this patch in essence does is revive dead code, > which was already in place. > > Also I think at that time I couldn't find a more precise instrument in > systemds massive toolbox to delay the start of rngd and services that > should be started in succession until the just the hardware random > generator device is ready and `After=systemd-udev-settle.service` was > already there. I guess some `ExecStartPre=` script which delays the > start until the conditions are met could be implemented, but that seems > a bit hackish. > > regards, > Claudius > [-- Attachment #2: Type: text/html, Size: 5393 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service 2022-02-03 14:12 ` Kyle Russell @ 2022-07-21 15:17 ` Drew Moseley 2022-07-21 15:29 ` Khem Raj 0 siblings, 1 reply; 29+ messages in thread From: Drew Moseley @ 2022-07-21 15:17 UTC (permalink / raw) To: Kyle Russell, Claudius Heine Cc: OE-core, Marek Vasut, Alex Kiernan, Alexander Kanavin, Alban Bedel, Wes Lindauer [-- Attachment #1: Type: text/plain, Size: 5376 bytes --] On 2/3/22 9:12 AM, Kyle Russell wrote: > Thanks, Claudius. I really appreciate your responses. I'm not trying > to be pedantic. Since I don't have your test setup, I was just trying > to make sure I understood the context of the problem as I figure out > how to deal with issues this is causing in our setup. > > I was also hoping one of the recipe maintainers of either systemd or > rng-tools would comment on systemd-udev-settle. > > I'll take a look at the caam module to see if I can understand how it > works. > > On Thu, Feb 3, 2022 at 3:35 AM Claudius Heine <ch@denx.de> wrote: > > On 2022-02-02 17:26, Kyle Russell wrote: > > Thanks, Claudius. > > > > On Wed, Feb 2, 2022 at 8:08 AM Claudius Heine <ch@denx.de > > <mailto:ch@denx.de>> wrote: > > > > Hi Kyle, > > > > On 2022-02-02 13:38, Kyle Russell wrote: > > > Is this the correct approach? Even the > > systemd-udev-settle.service man > > > pages recommends not using its service. Were the kernel > modules > > really > > > not loaded when rngd started? Or is the original problem > just a > > matter > > > of waiting for sufficient entropy? > > > > IIRC, the rngd could not find any random source device node > (/dev/hwrng > > in that case), so the service failed to start. > > > > > > If /dev/hwrng didn't exist, this feels like the original problem > was a > > misconfigured > > kernel or module that wasn't being loaded properly. > > Yes, however it is a timing issue. The module was loaded properly at > bootup, however at the time rngd was started the module was not > loaded > yet and thus the service fails to start. If it would be delayed until > the module is loaded everything would be fine. > > It does not happen if the module is compiled into the kernel or if a > initramfs is used which loads the module (I think). I our case it > happend with the caam module as an external module loaded on boot > from > the real root file system. > > > The patch you are commenting on only adds `Wants` weak > dependency to > > make sure `systemd-udev-settle.service` is pulled in to the > job queue, > > the `After` ordering rule was already there. > > > > > > Correct. Just because an `After` exists does not mean the > service gets > > pulled into > > the job queue, so prior to this change no other service was > causing the > > deprecated > > systemd-udev-settle.service to be run during boot. But now, every > > device including > > openssh (which has a default PACKAGECONFIG option for rng-tools) > now depends > > on this deprecated service, which may cause unexpected boot delays. > > > > So changing this service file to be triggered by a udev > event or maybe > > wrap it in a script, which makes sure the right modules are > loaded and > > device nodes are available, could be an improvement, but it > would be > > out > > of scope of this patch IMO. > > > > > > I'm more curious whether this change should be reverted from > upstream. > > It seems > > like a drop-in file could have been applied to your distro > instead of > > adding a dependency > > on a deprecated service for all openssh users. > > This patch just adds a missing entry into the service file. If you > have > solved the described issue in some way and can revert this patch and > remove the `Wants=systemd-udev-settle.service` then you can also > remove > the `After=systemd-udev-settle.service` at the same time and at that > point you can just remove both of those entries directly in the patch > that solved the timing issue. > > I agree that `systemd-udev-settle.service` should probably not be > used > anymore, however that file already used it in a non-functional way > and > all this patch did was make it fulfill its intended function. > > In retrospect I probably should have tried to find a way to remove > the > usage of `systemd-udev-settle.service` completely, when I looked into > the issue, however all this patch in essence does is revive dead > code, > which was already in place. > > Also I think at that time I couldn't find a more precise > instrument in > systemds massive toolbox to delay the start of rngd and services that > should be started in succession until the just the hardware random > generator device is ready and `After=systemd-udev-settle.service` was > already there. I guess some `ExecStartPre=` script which delays the > start until the conditions are met could be implemented, but that > seems > a bit hackish. > > regards, > Claudius > We are getting report from our users that adding this "Wants" causes extremely slow boots on systems where it did not happen before this change. Has anyone looked further into this and whether this change is truly necessary? We have it reverted locally to work around the specific issue but I wonder if there is a deeper issue here. Drew -- mailto:drew@moseleynet.net [-- Attachment #2: Type: text/html, Size: 7937 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service 2022-07-21 15:17 ` Drew Moseley @ 2022-07-21 15:29 ` Khem Raj 2022-07-22 20:42 ` Drew Moseley 2022-07-23 7:03 ` Claudius Heine 0 siblings, 2 replies; 29+ messages in thread From: Khem Raj @ 2022-07-21 15:29 UTC (permalink / raw) To: drew, Kyle Russell, Claudius Heine Cc: OE-core, Marek Vasut, Alex Kiernan, Alexander Kanavin, Alban Bedel, Wes Lindauer On 7/21/22 11:17 AM, Drew Moseley wrote: > On 2/3/22 9:12 AM, Kyle Russell wrote: > >> Thanks, Claudius. I really appreciate your responses. I'm not trying >> to be pedantic. Since I don't have your test setup, I was just trying >> to make sure I understood the context of the problem as I figure out >> how to deal with issues this is causing in our setup. >> >> I was also hoping one of the recipe maintainers of either systemd or >> rng-tools would comment on systemd-udev-settle. >> >> I'll take a look at the caam module to see if I can understand how it >> works. >> >> On Thu, Feb 3, 2022 at 3:35 AM Claudius Heine <ch@denx.de> wrote: >> >> On 2022-02-02 17:26, Kyle Russell wrote: >> > Thanks, Claudius. >> > >> > On Wed, Feb 2, 2022 at 8:08 AM Claudius Heine <ch@denx.de >> > <mailto:ch@denx.de>> wrote: >> > >> > Hi Kyle, >> > >> > On 2022-02-02 13:38, Kyle Russell wrote: >> > > Is this the correct approach? Even the >> > systemd-udev-settle.service man >> > > pages recommends not using its service. Were the kernel >> modules >> > really >> > > not loaded when rngd started? Or is the original problem >> just a >> > matter >> > > of waiting for sufficient entropy? >> > >> > IIRC, the rngd could not find any random source device node >> (/dev/hwrng >> > in that case), so the service failed to start. >> > >> > >> > If /dev/hwrng didn't exist, this feels like the original problem >> was a >> > misconfigured >> > kernel or module that wasn't being loaded properly. >> >> Yes, however it is a timing issue. The module was loaded properly at >> bootup, however at the time rngd was started the module was not >> loaded >> yet and thus the service fails to start. If it would be delayed until >> the module is loaded everything would be fine. >> >> It does not happen if the module is compiled into the kernel or if a >> initramfs is used which loads the module (I think). I our case it >> happend with the caam module as an external module loaded on boot >> from >> the real root file system. >> >> > The patch you are commenting on only adds `Wants` weak >> dependency to >> > make sure `systemd-udev-settle.service` is pulled in to the >> job queue, >> > the `After` ordering rule was already there. >> > >> > >> > Correct. Just because an `After` exists does not mean the >> service gets >> > pulled into >> > the job queue, so prior to this change no other service was >> causing the >> > deprecated >> > systemd-udev-settle.service to be run during boot. But now, every >> > device including >> > openssh (which has a default PACKAGECONFIG option for rng-tools) >> now depends >> > on this deprecated service, which may cause unexpected boot delays. >> > >> > So changing this service file to be triggered by a udev >> event or maybe >> > wrap it in a script, which makes sure the right modules are >> loaded and >> > device nodes are available, could be an improvement, but it >> would be >> > out >> > of scope of this patch IMO. >> > >> > >> > I'm more curious whether this change should be reverted from >> upstream. >> > It seems >> > like a drop-in file could have been applied to your distro >> instead of >> > adding a dependency >> > on a deprecated service for all openssh users. >> >> This patch just adds a missing entry into the service file. If you >> have >> solved the described issue in some way and can revert this patch and >> remove the `Wants=systemd-udev-settle.service` then you can also >> remove >> the `After=systemd-udev-settle.service` at the same time and at that >> point you can just remove both of those entries directly in the patch >> that solved the timing issue. >> >> I agree that `systemd-udev-settle.service` should probably not be >> used >> anymore, however that file already used it in a non-functional way >> and >> all this patch did was make it fulfill its intended function. >> >> In retrospect I probably should have tried to find a way to remove >> the >> usage of `systemd-udev-settle.service` completely, when I looked into >> the issue, however all this patch in essence does is revive dead >> code, >> which was already in place. >> >> Also I think at that time I couldn't find a more precise >> instrument in >> systemds massive toolbox to delay the start of rngd and services that >> should be started in succession until the just the hardware random >> generator device is ready and `After=systemd-udev-settle.service` was >> already there. I guess some `ExecStartPre=` script which delays the >> start until the conditions are met could be implemented, but that >> seems >> a bit hackish. >> >> regards, >> Claudius >> > > We are getting report from our users that adding this "Wants" causes > extremely slow boots on systems where it did not happen before this > change. Has anyone looked further into this and whether this change is > truly necessary? > > We have it reverted locally to work around the specific issue but I > wonder if there is a deeper issue here. It seems the issue was that module load was racing with rngd in that case perhaps adding After=systemd-modules-load.service might have been another choice to solve it. Using systemd-udev-settle.service is a bit heavy handed as it will wait for full h/w discovery which could vary from system to system. > > Drew > > -- > mailto:drew@moseleynet.net > > > > > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] rng-tools: add systemd-udev-settle wants to service 2022-07-21 15:29 ` Khem Raj @ 2022-07-22 20:42 ` Drew Moseley 2022-07-23 0:30 ` [OE-core] " Khem Raj 2022-07-23 7:03 ` Claudius Heine 1 sibling, 1 reply; 29+ messages in thread From: Drew Moseley @ 2022-07-22 20:42 UTC (permalink / raw) To: openembedded-core [-- Attachment #1: Type: text/plain, Size: 161 bytes --] So should I submit a patch with that change? I don't know how to reproduce the original issue so I won't have any way to prove if this is a viable fix. Drew [-- Attachment #2: Type: text/html, Size: 169 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service 2022-07-22 20:42 ` Drew Moseley @ 2022-07-23 0:30 ` Khem Raj 0 siblings, 0 replies; 29+ messages in thread From: Khem Raj @ 2022-07-23 0:30 UTC (permalink / raw) To: Drew Moseley, Claudius Heine Cc: Patches and discussions about the oe-core layer On Fri, Jul 22, 2022 at 4:42 PM Drew Moseley <drew.moseley@gmail.com> wrote: > > So should I submit a patch with that change? I don't know how to reproduce the original issue so I won't have any way to prove if this is a viable fix. > Does this fix the problem you see ? if it does then perhaps Claudius can help trying it for the original issue and help validate further. > Drew > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#168425): https://lists.openembedded.org/g/openembedded-core/message/168425 > Mute This Topic: https://lists.openembedded.org/mt/85671578/1997914 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core] [PATCH] rng-tools: add systemd-udev-settle wants to service 2022-07-21 15:29 ` Khem Raj 2022-07-22 20:42 ` Drew Moseley @ 2022-07-23 7:03 ` Claudius Heine 2022-07-26 13:17 ` [OE-core][PATCH] rng-tools: Replace obsolete "wants systemd-udev-settle" drew.moseley 1 sibling, 1 reply; 29+ messages in thread From: Claudius Heine @ 2022-07-23 7:03 UTC (permalink / raw) To: Khem Raj, drew, Kyle Russell Cc: OE-core, Marek Vasut, Alex Kiernan, Alexander Kanavin, Alban Bedel, Wes Lindauer Hi Khem, On 2022-07-21 17:29, Khem Raj wrote: > > > On 7/21/22 11:17 AM, Drew Moseley wrote: >> On 2/3/22 9:12 AM, Kyle Russell wrote: >> >>> Thanks, Claudius. I really appreciate your responses. I'm not >>> trying to be pedantic. Since I don't have your test setup, I was >>> just trying to make sure I understood the context of the problem as I >>> figure out how to deal with issues this is causing in our setup. >>> >>> I was also hoping one of the recipe maintainers of either systemd or >>> rng-tools would comment on systemd-udev-settle. >>> >>> I'll take a look at the caam module to see if I can understand how it >>> works. >>> >>> On Thu, Feb 3, 2022 at 3:35 AM Claudius Heine <ch@denx.de> wrote: >>> >>> On 2022-02-02 17:26, Kyle Russell wrote: >>> > Thanks, Claudius. >>> > >>> > On Wed, Feb 2, 2022 at 8:08 AM Claudius Heine <ch@denx.de >>> > <mailto:ch@denx.de>> wrote: >>> > >>> > Hi Kyle, >>> > >>> > On 2022-02-02 13:38, Kyle Russell wrote: >>> > > Is this the correct approach? Even the >>> > systemd-udev-settle.service man >>> > > pages recommends not using its service. Were the kernel >>> modules >>> > really >>> > > not loaded when rngd started? Or is the original problem >>> just a >>> > matter >>> > > of waiting for sufficient entropy? >>> > >>> > IIRC, the rngd could not find any random source device node >>> (/dev/hwrng >>> > in that case), so the service failed to start. >>> > >>> > >>> > If /dev/hwrng didn't exist, this feels like the original problem >>> was a >>> > misconfigured >>> > kernel or module that wasn't being loaded properly. >>> >>> Yes, however it is a timing issue. The module was loaded properly at >>> bootup, however at the time rngd was started the module was not >>> loaded >>> yet and thus the service fails to start. If it would be delayed >>> until >>> the module is loaded everything would be fine. >>> >>> It does not happen if the module is compiled into the kernel or if a >>> initramfs is used which loads the module (I think). I our case it >>> happend with the caam module as an external module loaded on boot >>> from >>> the real root file system. >>> >>> > The patch you are commenting on only adds `Wants` weak >>> dependency to >>> > make sure `systemd-udev-settle.service` is pulled in to the >>> job queue, >>> > the `After` ordering rule was already there. >>> > >>> > >>> > Correct. Just because an `After` exists does not mean the >>> service gets >>> > pulled into >>> > the job queue, so prior to this change no other service was >>> causing the >>> > deprecated >>> > systemd-udev-settle.service to be run during boot. But now, every >>> > device including >>> > openssh (which has a default PACKAGECONFIG option for rng-tools) >>> now depends >>> > on this deprecated service, which may cause unexpected boot >>> delays. >>> > >>> > So changing this service file to be triggered by a udev >>> event or maybe >>> > wrap it in a script, which makes sure the right modules are >>> loaded and >>> > device nodes are available, could be an improvement, but it >>> would be >>> > out >>> > of scope of this patch IMO. >>> > >>> > >>> > I'm more curious whether this change should be reverted from >>> upstream. >>> > It seems >>> > like a drop-in file could have been applied to your distro >>> instead of >>> > adding a dependency >>> > on a deprecated service for all openssh users. >>> >>> This patch just adds a missing entry into the service file. If you >>> have >>> solved the described issue in some way and can revert this patch and >>> remove the `Wants=systemd-udev-settle.service` then you can also >>> remove >>> the `After=systemd-udev-settle.service` at the same time and at that >>> point you can just remove both of those entries directly in the >>> patch >>> that solved the timing issue. >>> >>> I agree that `systemd-udev-settle.service` should probably not be >>> used >>> anymore, however that file already used it in a non-functional way >>> and >>> all this patch did was make it fulfill its intended function. >>> >>> In retrospect I probably should have tried to find a way to remove >>> the >>> usage of `systemd-udev-settle.service` completely, when I looked >>> into >>> the issue, however all this patch in essence does is revive dead >>> code, >>> which was already in place. >>> >>> Also I think at that time I couldn't find a more precise >>> instrument in >>> systemds massive toolbox to delay the start of rngd and services >>> that >>> should be started in succession until the just the hardware random >>> generator device is ready and `After=systemd-udev-settle.service` >>> was >>> already there. I guess some `ExecStartPre=` script which delays the >>> start until the conditions are met could be implemented, but that >>> seems >>> a bit hackish. >>> >>> regards, >>> Claudius >>> >> >> We are getting report from our users that adding this "Wants" causes >> extremely slow boots on systems where it did not happen before this >> change. Has anyone looked further into this and whether this change is >> truly necessary? >> >> We have it reverted locally to work around the specific issue but I >> wonder if there is a deeper issue here. > > It seems the issue was that module load was racing with rngd in that > case perhaps adding After=systemd-modules-load.service > might have been another choice to solve it. Using > systemd-udev-settle.service is a bit heavy handed as it will wait for > full h/w discovery which could vary from system to system. Maybe systemd-modules-load.service could be enough in many cases, however it has to be made sure that the device node /dev/hwrng is created before the service is started. Just making sure that the modules are loaded might not be enough... As I described the best, albeit a bit hackish solutions, would be a `ExecStartPre` script that delays the service until the system is ready for rngd. It is a bit difficult for me to test this now, since I no longer have access to exactly that hardware, but I will try to review all patches and comment on it if I find any potential issues. regards, Claudius ^ permalink raw reply [flat|nested] 29+ messages in thread
* [OE-core][PATCH] rng-tools: Replace obsolete "wants systemd-udev-settle" 2022-07-23 7:03 ` Claudius Heine @ 2022-07-26 13:17 ` drew.moseley 2022-08-01 18:44 ` Drew Moseley 0 siblings, 1 reply; 29+ messages in thread From: drew.moseley @ 2022-07-26 13:17 UTC (permalink / raw) To: openembedded-core; +Cc: ch, raj.khem From: Drew Moseley <drew@moseleynet.net> The systemd-udev-settle service is listed as obsolete and does in some cases result in a significant boot time. Replace that with "after systemd-modules-load" to allow the random source hardware to be loaded in the proper sequence. Before this change: Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) = 2min 17.262s multi-user.target reached after 2min 8.153s in userspace After this change: Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s multi-user.target reached after 9.522s in userspace Signed-off-by: Drew Moseley <drew@moseleynet.net> --- meta/recipes-support/rng-tools/rng-tools/rngd.service | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service b/meta/recipes-support/rng-tools/rng-tools/rngd.service index 568686e80e..e818cfcf78 100644 --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service @@ -3,7 +3,7 @@ Description=Hardware RNG Entropy Gatherer Daemon DefaultDependencies=no After=systemd-udev-settle.service Before=sysinit.target shutdown.target -Wants=systemd-udev-settle.service +After=systemd-modules-load.service Conflicts=shutdown.target [Service] -- 2.37.1 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [OE-core][PATCH] rng-tools: Replace obsolete "wants systemd-udev-settle" 2022-07-26 13:17 ` [OE-core][PATCH] rng-tools: Replace obsolete "wants systemd-udev-settle" drew.moseley @ 2022-08-01 18:44 ` Drew Moseley 2022-08-02 7:24 ` Claudius Heine 0 siblings, 1 reply; 29+ messages in thread From: Drew Moseley @ 2022-08-01 18:44 UTC (permalink / raw) To: openembedded-core, raj.khem, ch On 7/26/22 9:17 AM, drew.moseley@gmail.com wrote: > From: Drew Moseley <drew@moseleynet.net> > > The systemd-udev-settle service is listed as obsolete and does in > some cases result in a significant boot time. Replace that with > "after systemd-modules-load" to allow the random source hardware > to be loaded in the proper sequence. > > Before this change: > > Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) = 2min 17.262s > multi-user.target reached after 2min 8.153s in userspace > > After this change: > > Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s > multi-user.target reached after 9.522s in userspace > > Signed-off-by: Drew Moseley <drew@moseleynet.net> > --- > meta/recipes-support/rng-tools/rng-tools/rngd.service | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service b/meta/recipes-support/rng-tools/rng-tools/rngd.service > index 568686e80e..e818cfcf78 100644 > --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service > +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service > @@ -3,7 +3,7 @@ Description=Hardware RNG Entropy Gatherer Daemon > DefaultDependencies=no > After=systemd-udev-settle.service > Before=sysinit.target shutdown.target > -Wants=systemd-udev-settle.service > +After=systemd-modules-load.service > Conflicts=shutdown.target > > [Service] Hi Khem, Claudius, Any thoughts on this change? Obviously I cannot verify if the original hardware combination issue is resolved and unfortunately it sounds like you cannot either but I'm using this successfully to work around the delayed boots I was seeing here. Drew -- mailto:drew@moseleynet.net ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core][PATCH] rng-tools: Replace obsolete "wants systemd-udev-settle" 2022-08-01 18:44 ` Drew Moseley @ 2022-08-02 7:24 ` Claudius Heine 2022-08-02 7:47 ` Khem Raj 0 siblings, 1 reply; 29+ messages in thread From: Claudius Heine @ 2022-08-02 7:24 UTC (permalink / raw) To: Drew Moseley, openembedded-core, raj.khem Hi Drew, On 2022-08-01 20:44, Drew Moseley wrote: > On 7/26/22 9:17 AM, drew.moseley@gmail.com wrote: > >> From: Drew Moseley <drew@moseleynet.net> >> >> The systemd-udev-settle service is listed as obsolete and does in >> some cases result in a significant boot time. Replace that with >> "after systemd-modules-load" to allow the random source hardware >> to be loaded in the proper sequence. >> >> Before this change: >> >> Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) = >> 2min 17.262s >> multi-user.target reached after 2min 8.153s in userspace >> >> After this change: >> >> Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s >> multi-user.target reached after 9.522s in userspace >> >> Signed-off-by: Drew Moseley <drew@moseleynet.net> >> --- >> meta/recipes-support/rng-tools/rng-tools/rngd.service | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service >> b/meta/recipes-support/rng-tools/rng-tools/rngd.service >> index 568686e80e..e818cfcf78 100644 >> --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service >> +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service >> @@ -3,7 +3,7 @@ Description=Hardware RNG Entropy Gatherer Daemon >> DefaultDependencies=no >> After=systemd-udev-settle.service >> Before=sysinit.target shutdown.target >> -Wants=systemd-udev-settle.service >> +After=systemd-modules-load.service >> Conflicts=shutdown.target >> [Service] > > > Hi Khem, Claudius, > > Any thoughts on this change? Obviously I cannot verify if the original > hardware combination issue is resolved and unfortunately it sounds like > you cannot either but I'm using this successfully to work around the > delayed boots I was seeing here. Well as I said, `systemd-modules-load.service` just waits until all statically configured modules are loaded, however not until the `/dev/hwrng` device node is available. `systemd-udev-settle.service` waits until all udev rules are applied, and that means it includes loading of all dynamically loaded modules as well as executing code that creates symlinks, etc. Instead of waiting for modules to be loaded, that might be unrelated or waiting for all (mostly unrelated) udev rules to be settled, I think waiting directly for the `/dev/hwrng` device node might be more explicit and specific. regards, Claudius ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core][PATCH] rng-tools: Replace obsolete "wants systemd-udev-settle" 2022-08-02 7:24 ` Claudius Heine @ 2022-08-02 7:47 ` Khem Raj 2022-08-04 15:09 ` [OE-core][PATCH v2] " drew.moseley 0 siblings, 1 reply; 29+ messages in thread From: Khem Raj @ 2022-08-02 7:47 UTC (permalink / raw) To: Claudius Heine; +Cc: Drew Moseley, openembedded-core [-- Attachment #1: Type: text/plain, Size: 2723 bytes --] On Tue, Aug 2, 2022 at 8:24 AM Claudius Heine <ch@denx.de> wrote: > Hi Drew, > > On 2022-08-01 20:44, Drew Moseley wrote: > > On 7/26/22 9:17 AM, drew.moseley@gmail.com wrote: > > > >> From: Drew Moseley <drew@moseleynet.net> > >> > >> The systemd-udev-settle service is listed as obsolete and does in > >> some cases result in a significant boot time. Replace that with > >> "after systemd-modules-load" to allow the random source hardware > >> to be loaded in the proper sequence. > >> > >> Before this change: > >> > >> Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) = > >> 2min 17.262s > >> multi-user.target reached after 2min 8.153s in userspace > >> > >> After this change: > >> > >> Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s > >> multi-user.target reached after 9.522s in userspace > >> > >> Signed-off-by: Drew Moseley <drew@moseleynet.net> > >> --- > >> meta/recipes-support/rng-tools/rng-tools/rngd.service | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service > >> b/meta/recipes-support/rng-tools/rng-tools/rngd.service > >> index 568686e80e..e818cfcf78 100644 > >> --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service > >> +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service > >> @@ -3,7 +3,7 @@ Description=Hardware RNG Entropy Gatherer Daemon > >> DefaultDependencies=no > >> After=systemd-udev-settle.service > >> Before=sysinit.target shutdown.target > >> -Wants=systemd-udev-settle.service > >> +After=systemd-modules-load.service > >> Conflicts=shutdown.target > >> [Service] > > > > > > Hi Khem, Claudius, > > > > Any thoughts on this change? Obviously I cannot verify if the original > > hardware combination issue is resolved and unfortunately it sounds like > > you cannot either but I'm using this successfully to work around the > > delayed boots I was seeing here. > > Well as I said, `systemd-modules-load.service` just waits until all > statically configured modules are loaded, however not until the > `/dev/hwrng` device node is available. `systemd-udev-settle.service` > waits until all udev rules are applied, and that means it includes > loading of all dynamically loaded modules as well as executing code that > creates symlinks, etc. > > Instead of waiting for modules to be loaded, that might be unrelated or > waiting for all (mostly unrelated) udev rules to be settled, I think > waiting directly for the `/dev/hwrng` device node might be more explicit > and specific. > Yeah something more surgical and pointed Requires=dev-hwrng.device After=dev-hwrng.device Might be worth trying > regards, > Claudius > [-- Attachment #2: Type: text/html, Size: 6465 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* [OE-core][PATCH v2] rng-tools: Replace obsolete "wants systemd-udev-settle" 2022-08-02 7:47 ` Khem Raj @ 2022-08-04 15:09 ` drew.moseley 2022-08-12 12:59 ` Dragos-Marian Panait 0 siblings, 1 reply; 29+ messages in thread From: drew.moseley @ 2022-08-04 15:09 UTC (permalink / raw) To: openembedded-core; +Cc: raj.khem, ch From: Drew Moseley <drew@moseleynet.net> The systemd-udev-settle service is listed as obsolete and does in some cases result in a significant boot time. Replace that with a specific wait for the random source hardware device to be loaded. Before this change: Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) = 2min 17.262s multi-user.target reached after 2min 8.153s in userspace After this change: Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s multi-user.target reached after 9.522s in userspace Signed-off-by: Drew Moseley <drew@moseleynet.net> --- meta/recipes-support/rng-tools/rng-tools/rngd.service | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service b/meta/recipes-support/rng-tools/rng-tools/rngd.service index 568686e80e..0f50890dcb 100644 --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service @@ -3,7 +3,8 @@ Description=Hardware RNG Entropy Gatherer Daemon DefaultDependencies=no After=systemd-udev-settle.service Before=sysinit.target shutdown.target -Wants=systemd-udev-settle.service +Requires=dev-hwrng.device +After=dev-hwrng.device Conflicts=shutdown.target [Service] -- 2.37.1 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [OE-core][PATCH v2] rng-tools: Replace obsolete "wants systemd-udev-settle" 2022-08-04 15:09 ` [OE-core][PATCH v2] " drew.moseley @ 2022-08-12 12:59 ` Dragos-Marian Panait 2022-08-12 15:20 ` Drew Moseley 0 siblings, 1 reply; 29+ messages in thread From: Dragos-Marian Panait @ 2022-08-12 12:59 UTC (permalink / raw) To: Drew Moseley, openembedded-core; +Cc: raj.khem, ch It seems that this change introduced a boot delay for qemux86-64 + systemd build. Steps: git clone git://git.yoctoproject.org/poky . poky/oe-init-build-env add to conf/local.conf: DISTRO_FEATURES:remove = " sysvinit" DISTRO_FEATURES:append = " systemd" VIRTUAL-RUNTIME_init_manager = "systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED = "" bitbake core-image-full-cmdline Cause of boot delay: [ TIME ] Timed out waiting for device /dev/hwrng. [DEPEND] Dependency failed for Hard…e RNG Entropy Gatherer Daemon. Regards, Dragos On 04.08.2022 18:09, Drew Moseley wrote: > [Please note: This e-mail is from an EXTERNAL e-mail address] > > From: Drew Moseley <drew@moseleynet.net> > > The systemd-udev-settle service is listed as obsolete and does in > some cases result in a significant boot time. Replace that with a > specific wait for the random source hardware device to be loaded. > > Before this change: > > Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) = 2min 17.262s > multi-user.target reached after 2min 8.153s in userspace > > After this change: > > Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s > multi-user.target reached after 9.522s in userspace > > Signed-off-by: Drew Moseley <drew@moseleynet.net> > --- > meta/recipes-support/rng-tools/rng-tools/rngd.service | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service b/meta/recipes-support/rng-tools/rng-tools/rngd.service > index 568686e80e..0f50890dcb 100644 > --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service > +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service > @@ -3,7 +3,8 @@ Description=Hardware RNG Entropy Gatherer Daemon > DefaultDependencies=no > After=systemd-udev-settle.service > Before=sysinit.target shutdown.target > -Wants=systemd-udev-settle.service > +Requires=dev-hwrng.device > +After=dev-hwrng.device > Conflicts=shutdown.target > > [Service] > -- > 2.37.1 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#168859): https://lists.openembedded.org/g/openembedded-core/message/168859 > Mute This Topic: https://lists.openembedded.org/mt/92815243/6328324 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [dragos.panait@windriver.com] > -=-=-=-=-=-=-=-=-=-=-=- > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core][PATCH v2] rng-tools: Replace obsolete "wants systemd-udev-settle" 2022-08-12 12:59 ` Dragos-Marian Panait @ 2022-08-12 15:20 ` Drew Moseley 2022-08-15 18:25 ` [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device drew.moseley 0 siblings, 1 reply; 29+ messages in thread From: Drew Moseley @ 2022-08-12 15:20 UTC (permalink / raw) To: openembedded-core, raj.khem, ch; +Cc: Dragos-Marian Panait Well dang. Any other suggestions on how to resolve the original issue without breaking others things? Drew On 8/12/22 8:59 AM, Dragos-Marian Panait wrote: > It seems that this change introduced a boot delay for qemux86-64 + > systemd build. > > Steps: > > git clone git://git.yoctoproject.org/poky > . poky/oe-init-build-env > > add to conf/local.conf: > > DISTRO_FEATURES:remove = " sysvinit" > DISTRO_FEATURES:append = " systemd" > VIRTUAL-RUNTIME_init_manager = "systemd" > DISTRO_FEATURES_BACKFILL_CONSIDERED = "" > > bitbake core-image-full-cmdline > > Cause of boot delay: > [ TIME ] Timed out waiting for device /dev/hwrng. > [DEPEND] Dependency failed for Hard…e RNG Entropy Gatherer Daemon. > > Regards, > Dragos > > On 04.08.2022 18:09, Drew Moseley wrote: >> [Please note: This e-mail is from an EXTERNAL e-mail address] >> >> From: Drew Moseley <drew@moseleynet.net> >> >> The systemd-udev-settle service is listed as obsolete and does in >> some cases result in a significant boot time. Replace that with a >> specific wait for the random source hardware device to be loaded. >> >> Before this change: >> >> Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) = >> 2min 17.262s >> multi-user.target reached after 2min 8.153s in userspace >> >> After this change: >> >> Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s >> multi-user.target reached after 9.522s in userspace >> >> Signed-off-by: Drew Moseley <drew@moseleynet.net> >> --- >> meta/recipes-support/rng-tools/rng-tools/rngd.service | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service >> b/meta/recipes-support/rng-tools/rng-tools/rngd.service >> index 568686e80e..0f50890dcb 100644 >> --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service >> +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service >> @@ -3,7 +3,8 @@ Description=Hardware RNG Entropy Gatherer Daemon >> DefaultDependencies=no >> After=systemd-udev-settle.service >> Before=sysinit.target shutdown.target >> -Wants=systemd-udev-settle.service >> +Requires=dev-hwrng.device >> +After=dev-hwrng.device >> Conflicts=shutdown.target >> >> [Service] >> -- >> 2.37.1 >> >> >> >> -- mailto:drew@moseleynet.net ^ permalink raw reply [flat|nested] 29+ messages in thread
* [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device 2022-08-12 15:20 ` Drew Moseley @ 2022-08-15 18:25 ` drew.moseley 2022-08-15 18:29 ` Drew Moseley 2022-08-19 9:36 ` Claudius Heine 0 siblings, 2 replies; 29+ messages in thread From: drew.moseley @ 2022-08-15 18:25 UTC (permalink / raw) To: openembedded-core; +Cc: raj.khem, ch, dragos.panait From: Drew Moseley <drew@moseleynet.net> The previous change to remove the dependency on systemd-udev-settle caused boot delays at least on qemu. It seems that change required a hwrng device but that's not necessarily available on all platforms. This changes the "Requires" to a "WantedBy" as modeled after the version of this file on Ubuntu 20.04. Signed-off-by: Drew Moseley <drew@moseleynet.net> --- meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service index 0f50890dcb..b013d95932 100644 --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon DefaultDependencies=no After=systemd-udev-settle.service Before=sysinit.target shutdown.target -Requires=dev-hwrng.device -After=dev-hwrng.device Conflicts=shutdown.target [Service] @@ -32,3 +30,4 @@ SystemCallFilter=@system-service [Install] WantedBy=sysinit.target +WantedBy=dev-hwrng.device -- 2.37.2 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device 2022-08-15 18:25 ` [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device drew.moseley @ 2022-08-15 18:29 ` Drew Moseley 2022-08-15 18:47 ` Khem Raj 2022-08-19 9:36 ` Claudius Heine 1 sibling, 1 reply; 29+ messages in thread From: Drew Moseley @ 2022-08-15 18:29 UTC (permalink / raw) To: raj.khem, ch; +Cc: dragos.panait, openembedded-core Hi Khem, It looks like you recently removed both the dependency on hwrng and systemd-udev-settle. Do you think this change will be useful? Claudius, any thoughts here? Drew On 8/15/22 2:25 PM, drew.moseley@gmail.com wrote: > From: Drew Moseley <drew@moseleynet.net> > > The previous change to remove the dependency on systemd-udev-settle > caused boot delays at least on qemu. It seems that change required > a hwrng device but that's not necessarily available on all platforms. > > This changes the "Requires" to a "WantedBy" as modeled after the > version of this file on Ubuntu 20.04. > > Signed-off-by: Drew Moseley <drew@moseleynet.net> > --- > meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > index 0f50890dcb..b013d95932 100644 > --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon > DefaultDependencies=no > After=systemd-udev-settle.service > Before=sysinit.target shutdown.target > -Requires=dev-hwrng.device > -After=dev-hwrng.device > Conflicts=shutdown.target > > [Service] > @@ -32,3 +30,4 @@ SystemCallFilter=@system-service > > [Install] > WantedBy=sysinit.target > +WantedBy=dev-hwrng.device -- mailto:drew@moseleynet.net ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device 2022-08-15 18:29 ` Drew Moseley @ 2022-08-15 18:47 ` Khem Raj 2022-08-18 17:12 ` Alexander Kanavin 0 siblings, 1 reply; 29+ messages in thread From: Khem Raj @ 2022-08-15 18:47 UTC (permalink / raw) To: Drew Moseley; +Cc: ch, dragos.panait, openembedded-core On Mon, Aug 15, 2022 at 11:30 AM Drew Moseley <drew.moseley@gmail.com> wrote: > > Hi Khem, > > It looks like you recently removed both the dependency on hwrng and > systemd-udev-settle. Do you think this change will be useful? Depending on udev-settle certainly seems an overkill so that should go. the change you have made will now ensure that this service starts when dev-hwrng device is created but loses the order of starting the service. So it may still race with device creation. > > Claudius, any thoughts here? > > > Drew > > > > On 8/15/22 2:25 PM, drew.moseley@gmail.com wrote: > > From: Drew Moseley <drew@moseleynet.net> > > > > The previous change to remove the dependency on systemd-udev-settle > > caused boot delays at least on qemu. It seems that change required > > a hwrng device but that's not necessarily available on all platforms. > > > > This changes the "Requires" to a "WantedBy" as modeled after the > > version of this file on Ubuntu 20.04. > > > > Signed-off-by: Drew Moseley <drew@moseleynet.net> > > --- > > meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > > index 0f50890dcb..b013d95932 100644 > > --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > > +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > > @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon > > DefaultDependencies=no > > After=systemd-udev-settle.service > > Before=sysinit.target shutdown.target > > -Requires=dev-hwrng.device > > -After=dev-hwrng.device > > Conflicts=shutdown.target > > > > [Service] > > @@ -32,3 +30,4 @@ SystemCallFilter=@system-service > > > > [Install] > > WantedBy=sysinit.target > > +WantedBy=dev-hwrng.device > > -- > mailto:drew@moseleynet.net > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device 2022-08-15 18:47 ` Khem Raj @ 2022-08-18 17:12 ` Alexander Kanavin 0 siblings, 0 replies; 29+ messages in thread From: Alexander Kanavin @ 2022-08-18 17:12 UTC (permalink / raw) To: Khem Raj; +Cc: Drew Moseley, Claudius Heine, Dragos-Marian Panait, OE-core I am definitely seeing a serious regression where qemu images get stuck for 4 minutes on boot waiting for /dev/hwrng, so if this is fixing the issue, I'd appreciate getting it in! Alex On Mon, 15 Aug 2022 at 20:48, Khem Raj <raj.khem@gmail.com> wrote: > > On Mon, Aug 15, 2022 at 11:30 AM Drew Moseley <drew.moseley@gmail.com> wrote: > > > > Hi Khem, > > > > It looks like you recently removed both the dependency on hwrng and > > systemd-udev-settle. Do you think this change will be useful? > > Depending on udev-settle certainly seems an overkill so that should go. > the change you have made will now ensure that this service starts when > dev-hwrng device is created > but loses the order of starting the service. So it may still race with > device creation. > > > > > Claudius, any thoughts here? > > > > > > Drew > > > > > > > > On 8/15/22 2:25 PM, drew.moseley@gmail.com wrote: > > > From: Drew Moseley <drew@moseleynet.net> > > > > > > The previous change to remove the dependency on systemd-udev-settle > > > caused boot delays at least on qemu. It seems that change required > > > a hwrng device but that's not necessarily available on all platforms. > > > > > > This changes the "Requires" to a "WantedBy" as modeled after the > > > version of this file on Ubuntu 20.04. > > > > > > Signed-off-by: Drew Moseley <drew@moseleynet.net> > > > --- > > > meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +-- > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > diff --git a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > > > index 0f50890dcb..b013d95932 100644 > > > --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > > > +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > > > @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon > > > DefaultDependencies=no > > > After=systemd-udev-settle.service > > > Before=sysinit.target shutdown.target > > > -Requires=dev-hwrng.device > > > -After=dev-hwrng.device > > > Conflicts=shutdown.target > > > > > > [Service] > > > @@ -32,3 +30,4 @@ SystemCallFilter=@system-service > > > > > > [Install] > > > WantedBy=sysinit.target > > > +WantedBy=dev-hwrng.device > > > > -- > > mailto:drew@moseleynet.net > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#169360): https://lists.openembedded.org/g/openembedded-core/message/169360 > Mute This Topic: https://lists.openembedded.org/mt/93042904/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device 2022-08-15 18:25 ` [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device drew.moseley 2022-08-15 18:29 ` Drew Moseley @ 2022-08-19 9:36 ` Claudius Heine 2022-08-19 12:50 ` Dragos-Marian Panait 1 sibling, 1 reply; 29+ messages in thread From: Claudius Heine @ 2022-08-19 9:36 UTC (permalink / raw) To: drew.moseley, openembedded-core; +Cc: raj.khem, dragos.panait Hi Dew. On 2022-08-15 20:25, drew.moseley@gmail.com wrote: > From: Drew Moseley <drew@moseleynet.net> > > The previous change to remove the dependency on systemd-udev-settle > caused boot delays at least on qemu. It seems that change required > a hwrng device but that's not necessarily available on all platforms. > > This changes the "Requires" to a "WantedBy" as modeled after the > version of this file on Ubuntu 20.04. > > Signed-off-by: Drew Moseley <drew@moseleynet.net> > --- > meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > index 0f50890dcb..b013d95932 100644 > --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon > DefaultDependencies=no > After=systemd-udev-settle.service > Before=sysinit.target shutdown.target > -Requires=dev-hwrng.device > -After=dev-hwrng.device > Conflicts=shutdown.target > > [Service] > @@ -32,3 +30,4 @@ SystemCallFilter=@system-service > > [Install] > WantedBy=sysinit.target > +WantedBy=dev-hwrng.device This looses the order. Have you tried just replacing `Requires` with `Wants`. So something like this: ``` Before=sysinit.target shutdown.target Wants=dev-hwrng.device After=dev-hwrng.device Conflicts=shutdown.target ``` If that still would cause the long waiting time on qemu? I haven't investigated the qemu issue, but maybe qemu just doesn't provide a hardware random source? If it doesn't provide a hardware random source, then installing rng-tools on there might also not make sense. Alternatively maybe just adding a start timeout might solve it? regards, Claudius ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device 2022-08-19 9:36 ` Claudius Heine @ 2022-08-19 12:50 ` Dragos-Marian Panait 2022-08-19 14:34 ` Drew Moseley 0 siblings, 1 reply; 29+ messages in thread From: Dragos-Marian Panait @ 2022-08-19 12:50 UTC (permalink / raw) To: Claudius Heine, drew.moseley, openembedded-core; +Cc: raj.khem [-- Attachment #1: Type: text/plain, Size: 2446 bytes --] Hi Claudius, On 19.08.2022 12:36, Claudius Heine wrote: > [Please note: This e-mail is from an EXTERNAL e-mail address] > > Hi Dew. > > On 2022-08-15 20:25, drew.moseley@gmail.com wrote: >> From: Drew Moseley <drew@moseleynet.net> >> >> The previous change to remove the dependency on systemd-udev-settle >> caused boot delays at least on qemu. It seems that change required >> a hwrng device but that's not necessarily available on all platforms. >> >> This changes the "Requires" to a "WantedBy" as modeled after the >> version of this file on Ubuntu 20.04. >> >> Signed-off-by: Drew Moseley <drew@moseleynet.net> >> --- >> meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git >> a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service >> b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service >> index 0f50890dcb..b013d95932 100644 >> --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service >> +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service >> @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon >> DefaultDependencies=no >> After=systemd-udev-settle.service >> Before=sysinit.target shutdown.target >> -Requires=dev-hwrng.device >> -After=dev-hwrng.device >> Conflicts=shutdown.target >> >> [Service] >> @@ -32,3 +30,4 @@ SystemCallFilter=@system-service >> >> [Install] >> WantedBy=sysinit.target >> +WantedBy=dev-hwrng.device > > This looses the order. Have you tried just replacing `Requires` with > `Wants`. So something like this: > > > ``` > > Before=sysinit.target shutdown.target > Wants=dev-hwrng.device > After=dev-hwrng.device > Conflicts=shutdown.target > > ``` > > If that still would cause the long waiting time on qemu? > > I haven't investigated the qemu issue, but maybe qemu just doesn't > provide a hardware random source? If it doesn't provide a hardware > random source, then installing rng-tools on there might also not make > sense. > Alternatively maybe just adding a start timeout might solve it? > regards, > Claudius I've tested the patch on a NUC7, results are the same as with qemu: - increased boot time - timeout for rng-tools.service [ TIME ] Timed out waiting for device /dev/hwrng. [DEPEND] Dependency failed for Hard…e RNG Entropy Gatherer Daemon. Regards, Dragos [-- Attachment #2: Type: text/html, Size: 4281 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device 2022-08-19 12:50 ` Dragos-Marian Panait @ 2022-08-19 14:34 ` Drew Moseley 2022-08-19 15:07 ` Dragos-Marian Panait 0 siblings, 1 reply; 29+ messages in thread From: Drew Moseley @ 2022-08-19 14:34 UTC (permalink / raw) To: Dragos-Marian Panait, Claudius Heine, openembedded-core; +Cc: raj.khem [-- Attachment #1: Type: text/plain, Size: 3047 bytes --] On 8/19/22 8:50 AM, Dragos-Marian Panait wrote: > > Hi Claudius, > > On 19.08.2022 12:36, Claudius Heine wrote: >> [Please note: This e-mail is from an EXTERNAL e-mail address] >> >> Hi Dew. >> >> On 2022-08-15 20:25, drew.moseley@gmail.com wrote: >>> From: Drew Moseley <drew@moseleynet.net> >>> >>> The previous change to remove the dependency on systemd-udev-settle >>> caused boot delays at least on qemu. It seems that change required >>> a hwrng device but that's not necessarily available on all platforms. >>> >>> This changes the "Requires" to a "WantedBy" as modeled after the >>> version of this file on Ubuntu 20.04. >>> >>> Signed-off-by: Drew Moseley <drew@moseleynet.net> >>> --- >>> meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +-- >>> 1 file changed, 1 insertion(+), 2 deletions(-) >>> >>> diff --git >>> a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service >>> b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service >>> index 0f50890dcb..b013d95932 100644 >>> --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service >>> +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service >>> @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon >>> DefaultDependencies=no >>> After=systemd-udev-settle.service >>> Before=sysinit.target shutdown.target >>> -Requires=dev-hwrng.device >>> -After=dev-hwrng.device >>> Conflicts=shutdown.target >>> >>> [Service] >>> @@ -32,3 +30,4 @@ SystemCallFilter=@system-service >>> >>> [Install] >>> WantedBy=sysinit.target >>> +WantedBy=dev-hwrng.device >> >> This looses the order. Have you tried just replacing `Requires` with >> `Wants`. So something like this: >> >> >> ``` >> >> Before=sysinit.target shutdown.target >> Wants=dev-hwrng.device >> After=dev-hwrng.device >> Conflicts=shutdown.target >> >> ``` >> >> If that still would cause the long waiting time on qemu? >> >> I haven't investigated the qemu issue, but maybe qemu just doesn't >> provide a hardware random source? If it doesn't provide a hardware >> random source, then installing rng-tools on there might also not make >> sense. >> Alternatively maybe just adding a start timeout might solve it? >> regards, >> Claudius > > > I've tested the patch on a NUC7, results are the same as with qemu: > - increased boot time > - timeout for rng-tools.service > [ TIME ] Timed out waiting for device /dev/hwrng. > [DEPEND] Dependency failed for Hard…e RNG Entropy Gatherer Daemon. > > Regards, > Dragos > Interesting. I guess this patch should definitely be ignored and the patch from Khem that removes both the dev-hwrng and systemd-udev-settle depencies is the right approach. That means that the original problem that adding systemd-udev-settle was meant to solve, is no longer solved but it seems that the proposed solutions here have adverse effects elsewhere. Simply removing the systemd-udev-settle dependency fixes the issue that my customer has that caused me to start investigating here. Drew -- mailto:drew@moseleynet.net [-- Attachment #2: Type: text/html, Size: 5248 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device 2022-08-19 14:34 ` Drew Moseley @ 2022-08-19 15:07 ` Dragos-Marian Panait 2022-08-19 15:13 ` Drew Moseley 0 siblings, 1 reply; 29+ messages in thread From: Dragos-Marian Panait @ 2022-08-19 15:07 UTC (permalink / raw) To: drew, Claudius Heine, openembedded-core; +Cc: raj.khem [-- Attachment #1: Type: text/plain, Size: 4918 bytes --] On 19.08.2022 17:34, Drew Moseley wrote: > > **[Please note: This e-mail is from an EXTERNAL e-mail address] > > > On 8/19/22 8:50 AM, Dragos-Marian Panait wrote: >> >> Hi Claudius, >> >> On 19.08.2022 12:36, Claudius Heine wrote: >>> [Please note: This e-mail is from an EXTERNAL e-mail address] >>> >>> Hi Dew. >>> >>> On 2022-08-15 20:25, drew.moseley@gmail.com wrote: >>>> From: Drew Moseley <drew@moseleynet.net> >>>> >>>> The previous change to remove the dependency on systemd-udev-settle >>>> caused boot delays at least on qemu. It seems that change required >>>> a hwrng device but that's not necessarily available on all platforms. >>>> >>>> This changes the "Requires" to a "WantedBy" as modeled after the >>>> version of this file on Ubuntu 20.04. >>>> >>>> Signed-off-by: Drew Moseley <drew@moseleynet.net> >>>> --- >>>> meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +-- >>>> 1 file changed, 1 insertion(+), 2 deletions(-) >>>> >>>> diff --git >>>> a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service >>>> b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service >>>> index 0f50890dcb..b013d95932 100644 >>>> --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service >>>> +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service >>>> @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon >>>> DefaultDependencies=no >>>> After=systemd-udev-settle.service >>>> Before=sysinit.target >>>> <https://urldefense.com/v3/__http://sysinit.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhOUu8G5A$> >>>> shutdown.target >>>> <https://urldefense.com/v3/__http://shutdown.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhfig0Hzw$> >>>> >>>> -Requires=dev-hwrng.device >>>> -After=dev-hwrng.device >>>> Conflicts=shutdown.target >>>> <https://urldefense.com/v3/__http://shutdown.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhfig0Hzw$> >>>> >>>> >>>> [Service] >>>> @@ -32,3 +30,4 @@ SystemCallFilter=@system-service >>>> >>>> [Install] >>>> WantedBy=sysinit.target >>>> <https://urldefense.com/v3/__http://sysinit.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhOUu8G5A$> >>>> >>>> +WantedBy=dev-hwrng.device >>> >>> This looses the order. Have you tried just replacing `Requires` with >>> `Wants`. So something like this: >>> >>> >>> ``` >>> >>> Before=sysinit.target >>> <https://urldefense.com/v3/__http://sysinit.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhOUu8G5A$> >>> shutdown.target >>> <https://urldefense.com/v3/__http://shutdown.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhfig0Hzw$> >>> >>> Wants=dev-hwrng.device >>> After=dev-hwrng.device >>> Conflicts=shutdown.target >>> <https://urldefense.com/v3/__http://shutdown.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhfig0Hzw$> >>> >>> >>> ``` >>> >>> If that still would cause the long waiting time on qemu? >>> >>> I haven't investigated the qemu issue, but maybe qemu just doesn't >>> provide a hardware random source? If it doesn't provide a hardware >>> random source, then installing rng-tools on there might also not >>> make sense. >>> Alternatively maybe just adding a start timeout might solve it? >>> regards, >>> Claudius >> >> >> I've tested the patch on a NUC7, results are the same as with qemu: >> - increased boot time >> - timeout for rng-tools.service >> [ TIME ] Timed out waiting for device /dev/hwrng. >> [DEPEND] Dependency failed for Hard…e RNG Entropy Gatherer Daemon. >> >> Regards, >> Dragos >> > > Interesting. I guess this patch should definitely be ignored and the > patch from Khem that removes both the dev-hwrng and > systemd-udev-settle depencies is the right approach. That means that > the original problem that adding systemd-udev-settle was meant to > solve, is no longer solved but it seems that the proposed solutions > here have adverse effects elsewhere. > > Simply removing the systemd-udev-settle dependency fixes the issue > that my customer has that caused me to start investigating here. > > Drew > > -- > mailto:drew@moseleynet.net Sorry for the confusion, I did not test any additional patches/changes that have been suggested in this email thread. My test was performed on current Yocto master sources. No additional patches. I just wanted to inform that the boot delay is also observed on real hw, not just qemu. Again, sorry for the confusion. Dragos [-- Attachment #2: Type: text/html, Size: 8410 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device 2022-08-19 15:07 ` Dragos-Marian Panait @ 2022-08-19 15:13 ` Drew Moseley 2022-08-19 15:21 ` Alexander Kanavin 0 siblings, 1 reply; 29+ messages in thread From: Drew Moseley @ 2022-08-19 15:13 UTC (permalink / raw) To: Dragos-Marian Panait, Claudius Heine, openembedded-core; +Cc: raj.khem [-- Attachment #1: Type: text/plain, Size: 5262 bytes --] On 8/19/22 11:07 AM, Dragos-Marian Panait wrote: > > > On 19.08.2022 17:34, Drew Moseley wrote: >> >> **[Please note: This e-mail is from an EXTERNAL e-mail address] >> >> >> On 8/19/22 8:50 AM, Dragos-Marian Panait wrote: >>> >>> Hi Claudius, >>> >>> On 19.08.2022 12:36, Claudius Heine wrote: >>>> [Please note: This e-mail is from an EXTERNAL e-mail address] >>>> >>>> Hi Dew. >>>> >>>> On 2022-08-15 20:25, drew.moseley@gmail.com wrote: >>>>> From: Drew Moseley <drew@moseleynet.net> >>>>> >>>>> The previous change to remove the dependency on systemd-udev-settle >>>>> caused boot delays at least on qemu. It seems that change required >>>>> a hwrng device but that's not necessarily available on all platforms. >>>>> >>>>> This changes the "Requires" to a "WantedBy" as modeled after the >>>>> version of this file on Ubuntu 20.04. >>>>> >>>>> Signed-off-by: Drew Moseley <drew@moseleynet.net> >>>>> --- >>>>> meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +-- >>>>> 1 file changed, 1 insertion(+), 2 deletions(-) >>>>> >>>>> diff --git >>>>> a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service >>>>> b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service >>>>> index 0f50890dcb..b013d95932 100644 >>>>> --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service >>>>> +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service >>>>> @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon >>>>> DefaultDependencies=no >>>>> After=systemd-udev-settle.service >>>>> Before=sysinit.target >>>>> <https://urldefense.com/v3/__http://sysinit.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhOUu8G5A$> >>>>> shutdown.target >>>>> <https://urldefense.com/v3/__http://shutdown.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhfig0Hzw$> >>>>> >>>>> -Requires=dev-hwrng.device >>>>> -After=dev-hwrng.device >>>>> Conflicts=shutdown.target >>>>> <https://urldefense.com/v3/__http://shutdown.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhfig0Hzw$> >>>>> >>>>> >>>>> [Service] >>>>> @@ -32,3 +30,4 @@ SystemCallFilter=@system-service >>>>> >>>>> [Install] >>>>> WantedBy=sysinit.target >>>>> <https://urldefense.com/v3/__http://sysinit.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhOUu8G5A$> >>>>> >>>>> +WantedBy=dev-hwrng.device >>>> >>>> This looses the order. Have you tried just replacing `Requires` with >>>> `Wants`. So something like this: >>>> >>>> >>>> ``` >>>> >>>> Before=sysinit.target >>>> <https://urldefense.com/v3/__http://sysinit.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhOUu8G5A$> >>>> shutdown.target >>>> <https://urldefense.com/v3/__http://shutdown.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhfig0Hzw$> >>>> >>>> Wants=dev-hwrng.device >>>> After=dev-hwrng.device >>>> Conflicts=shutdown.target >>>> <https://urldefense.com/v3/__http://shutdown.target__;!!AjveYdw8EvQ!bMQ5MfvZXWSzWjMLcLKDiM6wYi4-aF2QLE3CUcAKrFyEDpC2HxgAIFZGkwbGAHCJ81Fwt4gLnBeDKIdmEXOhfig0Hzw$> >>>> >>>> >>>> ``` >>>> >>>> If that still would cause the long waiting time on qemu? >>>> >>>> I haven't investigated the qemu issue, but maybe qemu just doesn't >>>> provide a hardware random source? If it doesn't provide a hardware >>>> random source, then installing rng-tools on there might also not >>>> make sense. >>>> Alternatively maybe just adding a start timeout might solve it? >>>> regards, >>>> Claudius >>> >>> >>> I've tested the patch on a NUC7, results are the same as with qemu: >>> - increased boot time >>> - timeout for rng-tools.service >>> [ TIME ] Timed out waiting for device /dev/hwrng. >>> [DEPEND] Dependency failed for Hard…e RNG Entropy Gatherer Daemon. >>> >>> Regards, >>> Dragos >>> >> >> Interesting. I guess this patch should definitely be ignored and the >> patch from Khem that removes both the dev-hwrng and >> systemd-udev-settle depencies is the right approach. That means that >> the original problem that adding systemd-udev-settle was meant to >> solve, is no longer solved but it seems that the proposed solutions >> here have adverse effects elsewhere. >> >> Simply removing the systemd-udev-settle dependency fixes the issue >> that my customer has that caused me to start investigating here. >> >> Drew >> >> -- >> mailto:drew@moseleynet.net > Sorry for the confusion, I did not test any additional patches/changes > that have been suggested in this email thread. > My test was performed on current Yocto master sources. No additional > patches. > I just wanted to inform that the boot delay is also observed on real > hw, not just qemu. > Again, sorry for the confusion. > > Dragos Sorry for adding to the confusion. My point was intended to be that I am fairly certain the recent patch submitted by Khem will resolve the boot delay issue you are having as well as the original boot delay caused by systemd-udev-settle. Drew -- mailto:drew@moseleynet.net [-- Attachment #2: Type: text/html, Size: 9454 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device 2022-08-19 15:13 ` Drew Moseley @ 2022-08-19 15:21 ` Alexander Kanavin 2022-08-19 16:24 ` Khem Raj 0 siblings, 1 reply; 29+ messages in thread From: Alexander Kanavin @ 2022-08-19 15:21 UTC (permalink / raw) To: drew; +Cc: Dragos-Marian Panait, Claudius Heine, OE-core, Khem Raj So which recent patch? Can you link to it please? Alex On Fri, 19 Aug 2022 at 17:13, Drew Moseley <drew.moseley@gmail.com> wrote: > > > On 8/19/22 11:07 AM, Dragos-Marian Panait wrote: > > > On 19.08.2022 17:34, Drew Moseley wrote: > > [Please note: This e-mail is from an EXTERNAL e-mail address] > > > On 8/19/22 8:50 AM, Dragos-Marian Panait wrote: > > Hi Claudius, > > On 19.08.2022 12:36, Claudius Heine wrote: > > [Please note: This e-mail is from an EXTERNAL e-mail address] > > Hi Dew. > > On 2022-08-15 20:25, drew.moseley@gmail.com wrote: > > From: Drew Moseley <drew@moseleynet.net> > > The previous change to remove the dependency on systemd-udev-settle > caused boot delays at least on qemu. It seems that change required > a hwrng device but that's not necessarily available on all platforms. > > This changes the "Requires" to a "WantedBy" as modeled after the > version of this file on Ubuntu 20.04. > > Signed-off-by: Drew Moseley <drew@moseleynet.net> > --- > meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > index 0f50890dcb..b013d95932 100644 > --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon > DefaultDependencies=no > After=systemd-udev-settle.service > Before=sysinit.target shutdown.target > -Requires=dev-hwrng.device > -After=dev-hwrng.device > Conflicts=shutdown.target > > [Service] > @@ -32,3 +30,4 @@ SystemCallFilter=@system-service > > [Install] > WantedBy=sysinit.target > +WantedBy=dev-hwrng.device > > > This looses the order. Have you tried just replacing `Requires` with > `Wants`. So something like this: > > > ``` > > Before=sysinit.target shutdown.target > Wants=dev-hwrng.device > After=dev-hwrng.device > Conflicts=shutdown.target > > ``` > > If that still would cause the long waiting time on qemu? > > I haven't investigated the qemu issue, but maybe qemu just doesn't > provide a hardware random source? If it doesn't provide a hardware > random source, then installing rng-tools on there might also not make sense. > Alternatively maybe just adding a start timeout might solve it? > regards, > Claudius > > > I've tested the patch on a NUC7, results are the same as with qemu: > - increased boot time > - timeout for rng-tools.service > [ TIME ] Timed out waiting for device /dev/hwrng. > [DEPEND] Dependency failed for Hard…e RNG Entropy Gatherer Daemon. > > Regards, > Dragos > > > Interesting. I guess this patch should definitely be ignored and the patch from Khem that removes both the dev-hwrng and systemd-udev-settle depencies is the right approach. That means that the original problem that adding systemd-udev-settle was meant to solve, is no longer solved but it seems that the proposed solutions here have adverse effects elsewhere. > > Simply removing the systemd-udev-settle dependency fixes the issue that my customer has that caused me to start investigating here. > > Drew > > -- > mailto:drew@moseleynet.net > > Sorry for the confusion, I did not test any additional patches/changes that have been suggested in this email thread. > My test was performed on current Yocto master sources. No additional patches. > I just wanted to inform that the boot delay is also observed on real hw, not just qemu. > Again, sorry for the confusion. > > Dragos > > > Sorry for adding to the confusion. My point was intended to be that I am fairly certain the recent patch submitted by Khem will resolve the boot delay issue you are having as well as the original boot delay caused by systemd-udev-settle. > > Drew > > -- > mailto:drew@moseleynet.net > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#169634): https://lists.openembedded.org/g/openembedded-core/message/169634 > Mute This Topic: https://lists.openembedded.org/mt/93042904/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device 2022-08-19 15:21 ` Alexander Kanavin @ 2022-08-19 16:24 ` Khem Raj 0 siblings, 0 replies; 29+ messages in thread From: Khem Raj @ 2022-08-19 16:24 UTC (permalink / raw) To: Alexander Kanavin; +Cc: drew, Dragos-Marian Panait, Claudius Heine, OE-core On Fri, Aug 19, 2022 at 8:22 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > So which recent patch? Can you link to it please? > https://patchwork.yoctoproject.org/project/oe-core/patch/20220813170156.4040589-1-raj.khem@gmail.com/ but this needs to remove sysinit from target, I have meant to send a v2 but had no time to do so far. > Alex > > > On Fri, 19 Aug 2022 at 17:13, Drew Moseley <drew.moseley@gmail.com> wrote: > > > > > > On 8/19/22 11:07 AM, Dragos-Marian Panait wrote: > > > > > > On 19.08.2022 17:34, Drew Moseley wrote: > > > > [Please note: This e-mail is from an EXTERNAL e-mail address] > > > > > > On 8/19/22 8:50 AM, Dragos-Marian Panait wrote: > > > > Hi Claudius, > > > > On 19.08.2022 12:36, Claudius Heine wrote: > > > > [Please note: This e-mail is from an EXTERNAL e-mail address] > > > > Hi Dew. > > > > On 2022-08-15 20:25, drew.moseley@gmail.com wrote: > > > > From: Drew Moseley <drew@moseleynet.net> > > > > The previous change to remove the dependency on systemd-udev-settle > > caused boot delays at least on qemu. It seems that change required > > a hwrng device but that's not necessarily available on all platforms. > > > > This changes the "Requires" to a "WantedBy" as modeled after the > > version of this file on Ubuntu 20.04. > > > > Signed-off-by: Drew Moseley <drew@moseleynet.net> > > --- > > meta/recipes-support/rng-tools/rng-tools/rng-tools.service | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > > index 0f50890dcb..b013d95932 100644 > > --- a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > > +++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service > > @@ -3,8 +3,6 @@ Description=Hardware RNG Entropy Gatherer Daemon > > DefaultDependencies=no > > After=systemd-udev-settle.service > > Before=sysinit.target shutdown.target > > -Requires=dev-hwrng.device > > -After=dev-hwrng.device > > Conflicts=shutdown.target > > > > [Service] > > @@ -32,3 +30,4 @@ SystemCallFilter=@system-service > > > > [Install] > > WantedBy=sysinit.target > > +WantedBy=dev-hwrng.device > > > > > > This looses the order. Have you tried just replacing `Requires` with > > `Wants`. So something like this: > > > > > > ``` > > > > Before=sysinit.target shutdown.target > > Wants=dev-hwrng.device > > After=dev-hwrng.device > > Conflicts=shutdown.target > > > > ``` > > > > If that still would cause the long waiting time on qemu? > > > > I haven't investigated the qemu issue, but maybe qemu just doesn't > > provide a hardware random source? If it doesn't provide a hardware > > random source, then installing rng-tools on there might also not make sense. > > Alternatively maybe just adding a start timeout might solve it? > > regards, > > Claudius > > > > > > I've tested the patch on a NUC7, results are the same as with qemu: > > - increased boot time > > - timeout for rng-tools.service > > [ TIME ] Timed out waiting for device /dev/hwrng. > > [DEPEND] Dependency failed for Hard…e RNG Entropy Gatherer Daemon. > > > > Regards, > > Dragos > > > > > > Interesting. I guess this patch should definitely be ignored and the patch from Khem that removes both the dev-hwrng and systemd-udev-settle depencies is the right approach. That means that the original problem that adding systemd-udev-settle was meant to solve, is no longer solved but it seems that the proposed solutions here have adverse effects elsewhere. > > > > Simply removing the systemd-udev-settle dependency fixes the issue that my customer has that caused me to start investigating here. > > > > Drew > > > > -- > > mailto:drew@moseleynet.net > > > > Sorry for the confusion, I did not test any additional patches/changes that have been suggested in this email thread. > > My test was performed on current Yocto master sources. No additional patches. > > I just wanted to inform that the boot delay is also observed on real hw, not just qemu. > > Again, sorry for the confusion. > > > > Dragos > > > > > > Sorry for adding to the confusion. My point was intended to be that I am fairly certain the recent patch submitted by Khem will resolve the boot delay issue you are having as well as the original boot delay caused by systemd-udev-settle. > > > > Drew > > > > -- > > mailto:drew@moseleynet.net > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > > Links: You receive all messages sent to this group. > > View/Reply Online (#169634): https://lists.openembedded.org/g/openembedded-core/message/169634 > > Mute This Topic: https://lists.openembedded.org/mt/93042904/1686489 > > Group Owner: openembedded-core+owner@lists.openembedded.org > > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] > > -=-=-=-=-=-=-=-=-=-=-=- > > ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2022-08-19 16:24 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-17 8:08 [PATCH] rng-tools: add systemd-udev-settle wants to service Claudius Heine 2022-02-02 12:38 ` [OE-core] " Kyle Russell 2022-02-02 13:08 ` Claudius Heine 2022-02-02 16:26 ` Kyle Russell 2022-02-03 8:35 ` Claudius Heine 2022-02-03 14:12 ` Kyle Russell 2022-07-21 15:17 ` Drew Moseley 2022-07-21 15:29 ` Khem Raj 2022-07-22 20:42 ` Drew Moseley 2022-07-23 0:30 ` [OE-core] " Khem Raj 2022-07-23 7:03 ` Claudius Heine 2022-07-26 13:17 ` [OE-core][PATCH] rng-tools: Replace obsolete "wants systemd-udev-settle" drew.moseley 2022-08-01 18:44 ` Drew Moseley 2022-08-02 7:24 ` Claudius Heine 2022-08-02 7:47 ` Khem Raj 2022-08-04 15:09 ` [OE-core][PATCH v2] " drew.moseley 2022-08-12 12:59 ` Dragos-Marian Panait 2022-08-12 15:20 ` Drew Moseley 2022-08-15 18:25 ` [OE-core][PATCH] rng-tools: Change "Requires" to "WantedBy" for dev-hwrng.device drew.moseley 2022-08-15 18:29 ` Drew Moseley 2022-08-15 18:47 ` Khem Raj 2022-08-18 17:12 ` Alexander Kanavin 2022-08-19 9:36 ` Claudius Heine 2022-08-19 12:50 ` Dragos-Marian Panait 2022-08-19 14:34 ` Drew Moseley 2022-08-19 15:07 ` Dragos-Marian Panait 2022-08-19 15:13 ` Drew Moseley 2022-08-19 15:21 ` Alexander Kanavin 2022-08-19 16:24 ` Khem Raj
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).