On Thu, Jul 5, 2018 at 5:07 PM, Zbigniew Jędrzejewski-Szmek < zbyszek@xxxxxxxxx> wrote: > On Thu, Jul 05, 2018 at 01:55:46PM -0400, Jeff Backus wrote: > > On Thu, Jul 5, 2018 at 12:56 PM, Jeff Backus <jeff.backus@xxxxxxxxx> > wrote: > > > > > Hi Adam, > > > > > > Thanks for your response. > > > > > > On Wed, Jul 4, 2018 at 4:33 PM, Adam Williamson < > > > adamwill@xxxxxxxxxxxxxxxxx> wrote: > > > > > >> On Thu, 2018-06-28 at 13:22 -0400, Jeff Backus wrote: > > >> > Hi folks, > > >> > > > >> > I'm going to take a whack at triaging x86-related bugs. I see a few > > >> listed > > >> > on the x86 tracker bug and the x86 exclude arch bug, which I'll > take a > > >> > closer look at. > > >> > > > >> > Before I start searching for anything i686-related, are there any > issues > > >> > you'd like us to take a look at first? > > >> > > >> Rawhide's been completely broken on x86 since...about 20180611.n.0, > > >> definitely 20180627.n.0. Installer images don't seem to make it out of > > >> dracut. I haven't had time to look into the problem in any detail, but > > >> all the openQA tests are failing, all the time. > > >> > > > > > > Yeah, based on my cursory study of the logs, looks like the 6/10 image > > > started failing for some form of core dump during initial boot that > > > affected at least the Workstation image, and by 6/27 all i686 images > were > > > affected. I'm going to see if I can narrow it down. > > > > > > > I was able to get to a dracut prompt with the 6/30 image. Looks like the > > udev Kernel Device Manager is trying to core q dump? I'm seeing this > > message several times in the log after trying to start > > systemd-udevd.service: > > systemd-coredump[1663]: Failed to connect to coredump service: No such > file > > or directory > > > > Interestingly, I am seeing the following right after attempting to start > > systemd-udevd: > > Assertion 'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at > > ../src/basic/time-util.c:53, function now(). Abortion. > > > > I'll try to get the log off of the machine. Thoughts or suggestions? > > Might be a problem in systemd code to select clock type > (monotonic/realtime/etc.). > You can try taking an older image, and compiling systemd, and running the > tests. > Even something as simple as > sudo dnf build-dep systemd > git clone https://github.com/systemd/systemd > cd systemd > meson -Dman=false build && ninja -C build && ninja -C build test > > If that passes, then the next step would be to take that older image, > install just the newer kernel, and repeat the tests. > > Zbyszek > Thanks! I'll give it a whirl tomorrow. jeff -- Jeff Backus jeff.backus@xxxxxxxxx http://github.com/jsbackus _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx/message/76EINN5GM26FAXXWDS4AMEY4OC63G7K3/
