Re: Errors on newly created file system

[Ferry Toth <fntoth@gmail.com>]

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.

> 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