On Sun Sep 10, 2023 at 7:23 PM CEST, tony mancill wrote: > On Sun, Sep 10, 2023 at 05:53:23PM +0200, Valentin Vidic wrote: > > On Thu, Sep 07, 2023 at 07:55:56PM -0700, tony mancill wrote: > > > Thank you for the bug report. My initial instinct is to use the same > > > unit file and service dependencies as upstream. Looking at the history > > > of Debian's patch [2] of the unit file, and specifically this commit > > > [3], it appears that the change was made to resolve an issue. > > > > > > The patch to the systemd unit file predates my involvement with this > > > package, so Valentin may be able to provide more context. Perhaps > > > there was a bug in fcoe-utils that necessitated the change at that time, > > > but we can now revert to the unit file patch? > > > > > > Valentin, do you have any insight on this? Without a link to the > > > original bug, I'm unsure what regression reverting to the upstream unit > > > file dependencies might cause. > > > > Hi, as the comment on commit 1519b5cd suggests, I think there was some > > race condition with getting FCoE working reliably on boot. It is > > possible this is not required and can be reverted, but I don't have > > access to the hardware anymore to test it. > > > > Another option would be to move both services to start before the > > network, if the testing shows that this is still required. > > I also don't have access to the hardware to test it. My assumption is > that upstream would see bug reports if the race condition still exists, > but that's merely conjecture on my part.
Hi! FWIW: We have a customer who reported everything working as intended after moving the network.target from the "Before" line to the "After" line. However, I myself also don't have the hardware to test it, so I can't verify this independently. > Do you have any concerns with an upload to unstable (or experimental) to > revert the unit file change? > > Thank you, > tony Kind regards, stefan
