On Wed, Sep 22, 2021 at 6:35 PM Julian Sikorski <beleg...@gmail.com> wrote:
>
> W dniu 21.09.2021 o 23:12, Richard W.M. Jones pisze:
> > On Tue, Sep 21, 2021 at 10:16:17PM +0200, Julian Sikorski wrote:
> >> W dniu 21.09.2021 o 11:00, Richard W.M. Jones pisze:
> >>> On Mon, Sep 20, 2021 at 11:45:39AM -0600, Jerry James wrote:
> >>>> On Mon, Sep 20, 2021 at 10:49 AM Julian Sikorski <beleg...@gmail.com> 
> >>>> wrote:
> >>>>> my local kernel rebuilds have started failing for no apparent reason - I
> >>>>> was using a similar command successfully for several months.
> >>>>> /mnt/openmediavault is a samba share. This is what gets output into the 
> >>>>> log:
> >>>>
> >>>> [snip]
> >>>>
> >>>>> /mnt/openmediavault/kernel/results/fedora-34-x86_64/pesign-113-16.fc35/pesign-113-16.fc34.x86_64.rpm:
> >>>>> (39, fsync failed: Permission denied)
> >>>>
> >>>> I suspect that ^^^^ is the real problem, and the incorrect checksum is
> >>>> a result of not being able to read or write the filesystem.  Can you
> >>>> verify correct ownership and permissions on every directory in that
> >>>> path?
> >>>
> >>> If fsync(2) failed then that would be happening after the file
> >>> descriptor was open, so it wouldn't be filesystem permissions but
> >>> probably SELinux.
> >>>
> >>> Rich.
> >>>
> >>
> >> I am seeing no errors in setroubleshoot and setting selinux to
> >> permissive does not help either. Can it be the selinux of the
> >> bootstrapped instance, and if so, how can I control it? There is
> >> nothing obvious in the logs of the host:
> >
> > AFAIK mock only ever uses one kernel (the host) so disabling SELinux
> > on the host rules out my SELinux theory.
> >
> > Rich.
> >
> This is all super strange. If I delete the pesign result dir, it is
> built without issues. Moreover, repodata folder is also created, with
> the sha256 checksum in the file matching the one of the pesign rpm. What
> is odd though, is that even after mock fails, gedit is claiming that
> repomd.xml and the data file extracted from primary.xml.gz keep changing
> on disk. Can it be some odd system clock issue between my desktop an my NAS?

Oh my, that filesystem is mounted over a network? What filesystem is
backing that directory? SMB? NFS?
I assume that the issue you're seeing is caused by something like "NFS
doesn't support the fsync call properly" ...

Fabio
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to