W dniu 22.09.2021 o 21:07, Julian Sikorski pisze:
Am 22.09.21 um 19:38 schrieb Fabio Valentini:
> 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
>
It is a local network samba share, from a host running armbian and
openmediavault. This used to work until last week or so, which is why I
am starting to suspect some strange clock problem. I have tried
rebooting the NAS but it did not help.
Best regards,
Julian
I have now managed to generate logs on the NAS, see attached. There are
two errors which stand out: NT_STATUS_NO_EAS_ON_FILE and
NT_STATUS_ACCESS_DENIED later. Does this give any indication as to what
might be happening?
Best regards,
Julian