On Wed, Sep 22, 2021 at 6:35 PM Julian Sikorski <belegdol@xxxxxxxxx> 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 <belegdol@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
