On Wed, Sep 22, 2021 at 6:35 PM Julian Sikorski <belegdol(a)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
<belegdol(a)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