On Fri, 2020-12-04 at 12:08 -0600, Douglas R. Reno via blfs-dev wrote: > > On 12/4/20 11:16 AM, Wayne Blaszczyk via blfs-dev wrote: > > On Sat, 2020-12-05 at 04:04 +1100, Wayne Blaszczyk wrote: > > > On Fri, 2020-12-04 at 09:17 -0600, Douglas R. Reno via blfs-dev wrote: > > > > On 12/4/20 3:03 AM, Wayne Blaszczyk via blfs-dev wrote: > > > > > Hi Guys, > > > > > > > > > > Spent the last hour racking my brain on why Gentoo, Arch, and Fedora > > > > > had version 247.1 > > > > > Turns out that they are pulling from > > > > > https://github.com/systemd/systemd-stable > > > > > I didn't know this repository existed. > > > > > > > > > > Regards, > > > > > Wayne. > > > > > > > > > > > > > > Hi Wayne, > > > > > > > > They started doing that around 243 I think, but started tagging point > > > > versions around 245. > > > > > > > > In LFS, I have a patch that takes care of the changes in 247.1 and some > > > > other fixes (for systemd-networkd). Generally I just backport fixes that > > > > are applicable to {,B}LFS systems rather than trying to update it every > > > > time. > > > > > > > > Unfortunately, BLFS will be out of date when it comes to systemd for at > > > > least the next render. I'm working on that as quickly as I can, but I > > > > decided to do a full rebuild to see if any issues with udev rules come > > > > up. > > > > > > > > - Doug > > > > > > > Thanks Doug, > > > > > > My LFS build has just completed and on the reboot, the following failure > > > occurs: > > > > > > Dec 05 03:51:14 lfs02 systemd[212]: systemd-oomd.service: Failed to > > > determine user credentials: No such process > > > Dec 05 03:51:14 lfs02 systemd[212]: systemd-oomd.service: Failed at step > > > USER spawning /lib/systemd/systemd-oomd: No such process > > > Dec 05 03:51:14 lfs02 systemd[1]: systemd-oomd.service: Main process > > > exited, code=exited, status=217/USER > > > Dec 05 03:51:14 lfs02 systemd[1]: systemd-oomd.service: Failed with > > > result 'exit-code'. > > > Dec 05 03:51:14 lfs02 systemd[1]: Failed to start Userspace Out-Of-Memory > > > (OOM) Killer. > > > > > > Not sure if you have come across this. I'll investigate in the morning. > > > > > > Wayne. > > > > > Found that a user systemd-oom is require. However there are still issues: > > > > Dec 05 04:13:20 lfs02 systemd-oomd[197]: Pressure Stall Information (PSI) > > is not supported > > Dec 05 04:13:20 lfs02 systemd[1]: systemd-oomd.service: Main process > > exited, code=exited, status=1/FAILURE > > Dec 05 04:13:20 lfs02 systemd[1]: systemd-oomd.service: Failed with result > > 'exit-code'. > > Dec 05 04:13:20 lfs02 systemd[1]: Failed to start Userspace Out-Of-Memory > > (OOM) Killer. > > > > > > Regards, > > Wayne. > > > > > > > Hi Wayne, > > Did you build with -Dmode=release? systemd-oomd is classified as > experimental, so we use -Dmode=release to prevent it from being built > and installed. We've got -Dmode=release in LFS. In BLFS, we're also > going to need to add -Dpamconfdir=/etc/pam.d to force the PAM files to > end up in /etc/pam.d rather than /usr/lib/pam.d. > > - Doug >
No I didn't. I've since added the -Dmode=release and also added the kernel parameter CONFIG_PSI suggested by Bruce. The systemd-oom user is still required. I see that there is a -Doomd=false option to disable this. This and the second issue, I couldn't be bothered to re build the kernel without CONFIG_PSI to find out if its still needed when -Dmode=release is set. I'll let somebody else do that. Thanks for the tip about pam. Wayne. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
