I'll go ahead and switch to CentOS8-Stream once the current a-full is complete. If there is a need to follow RHEL8 exactly we can add a Rocky Linux worker in the future.
On Mon, Oct 4, 2021 at 11:28 AM Alexander Kanavin <[email protected]> wrote: > Since the original centos 8 is going away (support-wise) in less than 3 > months, should we just convert all workers to stream and move on? > > Alex > > On Mon, 4 Oct 2021 at 18:27, Michael Halstead < > [email protected]> wrote: > >> This error was fixed upstream >> https://bugzilla.redhat.com/show_bug.cgi?id=1975562 kernel 4.18.0-325.x >> which has landed in CentOS8 Stream on centos8-ty-2 but not plain CentOS8 >> where the newest kernel is still at 4.18.0-305.x. >> >> I'll reboot into the older 4.18.0-240.15 kernel again on centos8-ty-1 as >> a fix for now. >> >> On Tue, Sep 28, 2021 at 6:12 PM Anuj Mittal <[email protected]> >> wrote: >> >>> Did we find out the reason why this was happening? I have started >>> getting this error on Centos-8 while building hardknott. >>> >>> https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/4045 >>> >>> Thanks, >>> >>> Anuj >>> >>> On Wed, 2021-06-16 at 23:45 +0100, Richard Purdie wrote: >>> > On Sun, 2021-06-06 at 21:51 +0200, Alexander Kanavin wrote: >>> > > On Sun, 6 Jun 2021 at 01:10, Richard Purdie >>> > > <[email protected]> wrote: >>> > > > I tried again with the autobuilder, still fails: >>> > > > >>> > > > >>> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3516 >>> > > > >>> > > > so whatever it is, it is still "live". >>> > > > >>> > > >>> > > >>> > > I did some digging. The issue happens when: >>> > > - host is centos8 >>> > > - SDKMACHINE is i686 (e.g. cmake is 32 bit) >>> > > >>> > > Then there's a failing syscall attempting to set file times: >>> > > utimensat_time64(AT_FDCWD, "../install/usr/local/lib/cmake/assimp- >>> > > 4.1/assimp-config.cmake", >>> > > [{tv_sec=1622966723, tv_nsec=6319439026193432576}, >>> > > {tv_sec=1622966579, tv_nsec=17840053692309438464}], 0) = -1 >>> > > EINVAL (Invalid argument) >>> > > >>> > > On latest Fedora, there's no issue: >>> > > utimensat_time64(AT_FDCWD, "../install2/usr/local/lib/cmake/assimp- >>> > > 4.1/assimp-config.cmake", >>> > > [{tv_sec=1623002886, tv_nsec=6369724778172907520}, >>> > > {tv_sec=1623002886, tv_nsec=17839174083007217664}], 0) = 0 >>> > > >>> > > utimensat_time64 only appeared with 5.1 kernels, however, 4.18 should >>> > > be returning ENOSYS in that case >>> > > probably? >>> > >>> > I hacked up a quick test bit of code (which makes assumptions >>> > about 32 bit): >>> > >>> > #include <unistd.h> >>> > #include <sys/syscall.h> >>> > #include <sys/types.h> >>> > #include <sys/stat.h> >>> > #include <fcntl.h> >>> > #include <stdio.h> >>> > >>> > struct timespec64 { >>> > long long tv_sec; /* seconds */ >>> > long long tv_nsec; /* nanoseconds */ >>> > }; >>> > >>> > int main() { >>> > int fd = open("foo", O_RDWR | O_CREAT, 0644); >>> > write(fd, "foo", 3); >>> > struct timespec64 times[2] = {}; >>> > times[0].tv_sec = 1622966723; >>> > times[0].tv_nsec = 631943; >>> > times[1].tv_sec = 1622966579; >>> > times[1].tv_nsec = 178400; >>> > int rc = syscall(SYS_utimensat_time64, fd, NULL, ×[0], 0); >>> > printf("rc=%d\n", rc); >>> > close(fd); >>> > return rc; >>> > } >>> > >>> > built with "gcc -m32 test-syscall.c -o test" and run with "strace >>> > ./test". >>> > This works on all the systems I tried it in. As does: >>> > >>> > >>> > times[0].tv_sec = 1; >>> > times[0].tv_nsec = 2; >>> > times[1].tv_sec = 3; >>> > times[1].tv_nsec = 4; >>> > >>> > however if you set (and ignore the compiler warning): >>> > >>> > times[0].tv_sec = 1622966723; >>> > times[0].tv_nsec = 6319439026193432576; >>> > times[1].tv_sec = 1622966579; >>> > times[1].tv_nsec = 17840053692309438464; >>> > >>> > then you see EINVAL on the centos system but not on my ubuntu one. It >>> > will >>> > do that until you reduce the values of tv_nsec right now. So it seems >>> > most >>> > systems accept large tv_nsec values but the Centos one does not. >>> > >>> > I think tv_nsec may be being clamped to LONG_MAX of 4 bytes but should >>> > be >>> > a LONG_LONG_MAX of 8 bytes on a 32 bit since the field is a 64 bit >>> > long. >>> > >>> > Michael: Hopefully that gives you something to raise with them? >>> > >>> > Cheers, >>> > >>> > Richard >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> >>> >>> >>> >>> >> >> -- >> Michael Halstead >> Linux Foundation / Yocto Project >> Systems Operations Engineer >> > -- Michael Halstead Linux Foundation / Yocto Project Systems Operations Engineer
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#156633): https://lists.openembedded.org/g/openembedded-core/message/156633 Mute This Topic: https://lists.openembedded.org/mt/83304703/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
