Re: Errors on newly created file system

[Ferry Toth <fntoth@gmail.com>]

Hi

Op 24-04-2025 om 23:16 schreef Ferry Toth:
> Op 24-04-2025 om 22:49 schreef Qu Wenruo:
>>
>>
>> 在 2025/4/25 05:41, Ferry Toth 写道:
>>> Hi
>>>
>> [...]
>>>>
>>>>
>>>> Except with newer mkfs.btrfs (I tested using 6.13) the files are 
>>>> owned by the unprivileged user.
>>>>
>>>>
>>>> The result is, the image will not boot correctly.
>>>>
>>>>
>>> I found more about this issue here
>>>
>>> https://lore.kernel.org/yocto/ 
>>> tRtu.1740682678597454399.5171@lists.yoctoproject.org/T/ 
>>> #m5de0afa17d2c0f640e86ffe67e0d74aea467fd5b
>>>
>> Thanks for the report.
>>
>> Just want to be sure, with pseudo emulating root environment, how does 
>> it handle the file uid/gid?
>>
>> Mkfs.btrfs uses the uid/gid reported from stat() system calls, thus if 
>> pseudo doesn't change uid/gid reported from stat(), mkfs.btrfs will 
>> just follow the result.
> 
> The change in mkfs.btrfs is reportedly:
> "The important change is that previously mkfs.btrfs was
> using lstat syscall to get file stats, but then it switched to nftw libc
> function to do the same. Pseudo[3] however doesn't support this call -
> it "knows" that it exists (at least nftw64), but there seems to be no
> implementation."
> 
> So, as I understand, pseudo would hook into stats call, lookup in 
> database and change uid/gid accordingly. But now there is only a stub.
> 
> Right now I am trying a patch for pseudo that implements nftw64. It 
> triggers a rebuild for half my image, so that will takes another hour or 
> so. I'll let you know how that goes.
> 
> This particular problem does seem to be more pseudo related.

Yes, the patch for pseudo is working. So, this is not a mkfs.btrfs bug.

Thanks for your support!

>> I guess it's possible for us to implement an idmap-like solution, but 
>> I'd like to know how pseudo works first.
>>
>> Thanks,
>> Qu
>