Re: how to track down cause for EBUSY on /dev/vda4?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 18, 2020 at 11:49 AM Jeff Moyer <jmoyer@xxxxxxxxxx> wrote:
>
> Chris Murphy <lists@xxxxxxxxxxxxxxxxx> writes:
>
> > Hi,
> >
> > Short version:
> > # mkfs.any /dev/vda4
> > unable to open /dev/vda4: Device or resource busy
> >
> > Curiously /dev/vda4 is just a blank partition, not in use by anything
> > that I'm aware of. And gdisk is allowed to modify the GPT on /dev/vda
> > without complaint. This is a snippet from strace of the above command
> > at the failure point:
> >
> > openat(AT_FDCWD, "/dev/vda4", O_RDWR|O_EXCL) = -1 EBUSY (Device or
> > resource busy)
>
> [snip]
>
> > format, and /proc/mounts shows
> >
> > /dev/vda /run/initramfs/live iso9660
> > ro,relatime,nojoliet,check=s,map=n,blocksize=2048 0 0
>
> That mount claims the device, and you can't then also open a partition
> on that device exclusively.
>
> > So it sees the whole vda device as iso9660 and ro? But permits gdisk
> > to modify some select sectors on vda? I admit it's an ambiguous image.
> > Is it a duck or is it a rabbit? And therefore best to just look at it,
> > not make modifications to it. Yet /dev/vda is modifiable, where the
> > partitions aren't. Hmm.
>
> The file system is mounted read-only.  It may be that the /device/ is not
> read-only.


OK super, thanks for the clear explanation.


-- 
Chris Murphy



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux