On Sun, 2021-10-31 at 14:50 +0100, Julian Sikorski wrote: > W dniu 20.10.2021 o 20:09, Julian Sikorski pisze: > > W dniu 29.09.2021 o 10:08, Julian Sikorski pisze: > > > W dniu 28.09.2021 o 09:32, Julian Sikorski pisze: > > > > 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@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 > > > > > > > > > > > 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 > > > > > > I have been investigating this further. When building from a > > > different > > > client, I am getting most interesting results: > > > > > > $ mock --chain --localrepo=/mnt/openmediavault/kernel -r > > > fedora-34-x86_64 goffice/goffice-0.10.49-1.fc36.src.rpm > > > gnumeric/gnumeric-1.12.49-1.fc36.src.rpm > > > > > > will keep working from the laptop as goffice-0.10.49 was never > > > rebuilt > > > from the desktop, as long as goffice-0.10.50 results folder is not > > > present in /mnt/openmediavault/kernel. > > > > > > $ mock --chain --localrepo=/mnt/openmediavault/kernel -r > > > fedora-34-x86_64 goffice/goffice-0.10.50-2.fc36.src.rpm > > > gnumeric/gnumeric-1.12.50-2.fc36.src.rpm > > > > > > will fail when run from the laptop, even if the goffice-0.10.50- > > > 2.fc36 > > > folder does not exist when the build is started. Moreover, building > > > to > > > a different folder does not work either: > > > > > > $ mock --chain --localrepo=/mnt/openmediavault/kernel1 -r > > > fedora-34-x86_64 goffice/goffice-0.10.50-2.fc36.src.rpm > > > gnumeric/gnumeric-1.12.50-2.fc36.src.rpm > > > > > > This is beyond strange. To me it looks as if either the permissions > > > set from the desktop PC are somehow wrong and additionally persist > > > the > > > folder deletion, or as if createrepo needs different permissions to > > > generate checksum for goffice-0.10.50-2 than for goffice-0.10.49-1. > > > Neither of the above makes too much sense. > > > What does createrepo use to generate the checksum exactly? It would > > > be > > > good to have a simpler reproducer. > > > > > > Best regards, > > > Julian > > > > > > > I have looked into this further - running createrepo alone works > > fine: > > > > $ createrepo_c /mnt/openmediavault/kernel/results/fedora-34-x86_64/ > > Directory walk started > > Directory walk done - 28 packages > > Temporary output repo path: > > /mnt/openmediavault/kernel/results/fedora-34-x86_64/.repodata/ > > Preparing sqlite DBs > > Pool started (with 5 workers) > > Pool finished > > $ createrepo /mnt/openmediavault/kernel/results/fedora-34-x86_64/ > > Directory walk started > > Directory walk done - 28 packages > > Temporary output repo path: > > /mnt/openmediavault/kernel/results/fedora-34-x86_64/.repodata/ > > Preparing sqlite DBs > > Pool started (with 5 workers) > > Pool finished > > > > What is going on? Is mock not using createrepo? > > > > Best regards, > > Julian > > Upgrading to F35 did not fix this sadly. > if it is a mock bug , you shou report it here [1] maybe you need : config_opts['createrepo_on_rpms'] = True [1] https://github.com/rpm-software-management/mock/issues > Best regards, > Julian > _______________________________________________ > 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 -- Sérgio M. B. _______________________________________________ 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
