On Thu, Jun 3 2021 at 08:56:46 PM -0400, Link Dupont
wrote:
reproducible scenarios
Alright. I reran my tests with a CentOS 8 guest. On CentOS 8 (with a
virtiofs filesystem and with xattr on), the type of files in the
mounted hierarchy are unlabeled_t. I can work around that by switching
SE
On Thu, Jun 3 2021 at 08:24:02 PM +0100, Dr. David Alan Gilbert
wrote:
(I'm not sure el7 had 9p either??)
Oh drat. I'm conflating my issues. I have an EL7 guest that is having a
similar problem, except the guest sees the files as type nfs_t. I guess
the symptoms are the same, but the solutio
* Link Dupont (l...@sub-pop.net) wrote:
> Adding the element to the device does seem
> to spawn virtiofsd with the option string "source=/home,xattr". My guest can
> no longer mount the device though.
>
> It errors with:
>
> [ 170.225553] 9pnet_virtio: no channels available
> mount: mount(2) fa
Adding the element to the device does
seem to spawn virtiofsd with the option string "source=/home,xattr". My
guest can no longer mount the device though.
It errors with:
[ 170.225553] 9pnet_virtio: no channels available
mount: mount(2) failed: No such file or directory
I think what this is
On 6/1/21 8:02 AM, Vivek Goyal wrote:
> On Sat, May 29, 2021 at 01:42:50PM -0500, Harry G. Coin wrote:
>> Some regression in virtio-fs has led to rpm/dnf/yum failing in the same
>> guest it previously worked.
>>
>> linux 5.11.19-300.fc34.x86_64
>>
>> Specifically, all attempts to use dnf/yum lead
On Thu, 27 May 2021 15:24:40 +0200
Max Reitz wrote:
> On 25.05.21 17:02, Greg Kurz wrote:
> > We recently fixed an infinite loop by setting the SB_BORN flag on
> > submounts along with the write barrier needed by super_cache_count().
> > This is the job of vfs_get_tree() and FUSE shouldn't have t
