<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Linux distribution: Poky reference distribution from Yocto Project release 5.0 “Scarthgap”<o:p></o:p></p>
<p class="MsoNormal">systemd version: 255.4<o:p></o:p></p>
<p class="MsoNormal">kernel: 6.6.25-intel-pk-standard<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Systemd is disabling coredumps during bootup, claiming that it’s “Due to PID 1 having crashed”. However, aside from that log line, I can find no evidence that PID 1 actually crashed, and the system continues to boot normally. Log lines
 immediately afterward indicate that udevd has crashed at the same time, but again, it appears to recover, as the system boots normally afterward and “systemd[1]:” log statements continue to appear.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">root@intel-corei7-64:~# journalctl -b | grep coredump -C10<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">-unrelated context elided-<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Feb 21 19:00:56 intel-corei7-64 systemd-coredump[396]: Due to PID 1 having crashed coredump collection will now be turned off.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Feb 21 19:00:56 intel-corei7-64 systemd-coredump[396]: Resource limits disable core dumping for process 103 (udevd).<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Feb 21 19:00:56 intel-corei7-64 systemd-coredump[396]: Process 103 (udevd) of user 0 terminated abnormally without generating a coredump.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Feb 21 19:00:57 intel-corei7-64 kernel: igb 0000:01:00.0 enp1s0: igb: enp1s0 NIC Link is Up 100 Mbps Half Duplex, Flow Control: None<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Feb 21 19:00:57 intel-corei7-64 kernel: igb 0000:01:00.0: EEE Disabled: unsupported at half duplex. Re-enable using ethtool when at full duplex.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">-unrelated context elided-<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">root@intel-corei7-64:~# cat /proc/sys/kernel/core_pattern<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">|/bin/false<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Setting LogLevel=debug in /etc/systemd/system.conf and rebooting produces a hell of a lot of extra logs, but nothing that mentions PID 1 crashing or provides any additional details about the udevd crash. Same for setting udev_log=debug
 in /etc/udev/udev.conf. coredumpctl lists the udev crash, but makes no mention of the purported “PID 1” crash (note, this log is from a separate boot, so the PID and times are different from above):<br>
<br>
root@intel-corei7-64:~# coredumpctl info 102<o:p></o:p></p>
<p class="MsoNormal">           PID: 102 (udevd)<o:p></o:p></p>
<p class="MsoNormal">           UID: 0 (root)<o:p></o:p></p>
<p class="MsoNormal">           GID: 0 (root)<o:p></o:p></p>
<p class="MsoNormal">        Signal: 6 (ABRT)<o:p></o:p></p>
<p class="MsoNormal">     Timestamp: Thu 2025-02-20 22:29:28 UTC (30min ago)<o:p></o:p></p>
<p class="MsoNormal">  Command Line: udevd --daemon<o:p></o:p></p>
<p class="MsoNormal">    Executable: /usr/bin/udevadm<o:p></o:p></p>
<p class="MsoNormal">Control Group: /init.scope<o:p></o:p></p>
<p class="MsoNormal">          Unit: init.scope<o:p></o:p></p>
<p class="MsoNormal">         Slice: -.slice<o:p></o:p></p>
<p class="MsoNormal">       Boot ID: cc6df2a288af4b3586aa28ddf229ff5e<o:p></o:p></p>
<p class="MsoNormal">    Machine ID: 911fe70f4be4456e9b23f5857dbd73a2<o:p></o:p></p>
<p class="MsoNormal">      Hostname: intel-corei7-64<o:p></o:p></p>
<p class="MsoNormal">       Storage: none<o:p></o:p></p>
<p class="MsoNormal">       Message: Process 102 (udevd) of user 0 terminated abnormally without generating a coredump.<o:p></o:p></p>
<p class="MsoNormal">root@intel-corei7-64:~#<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">At this point I’m not certain how to continue diagnosing this seemingly-spurious “PID 1 crash”, since debug logging produced no leads and there’s no coredump for me to look at for context. Any advice, further troubleshooting steps I can
 take, or pointers toward more information on what might actually be going on would be greatly appreciated.<o:p></o:p></p>
</div>
</body>
</html>