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

* how to track down cause for EBUSY on /dev/vda4?
@ 2020-12-17 20:13 Chris Murphy
  2020-12-18 18:49 ` Jeff Moyer
  0 siblings, 1 reply; 3+ messages in thread
From: Chris Murphy @ 2020-12-17 20:13 UTC (permalink / raw)
  To: Linux FS Devel

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)
write(2, "ERROR: ", 7ERROR: )                  = 7
write(2, "unable to open /dev/vda4: Device"..., 49unable to open
/dev/vda4: Device or resource busy) = 49
write(2, "\n", 1
)

Long version:

1. Create an image with xorriso. Result is an ISO 9660 image that also
contains an MBR and GPT. Together, these are all in conflict but
permit magical indirection to successfully boot a computer whether
it's UEFI or BIOS, on optical or USB sticks.

2. Write this image to a USB stick using cat or dd.

3. The horrible idea occurs to use the large pile of extra space on
the USB stick for persistence. Therefore a partition must be added.

4. Given the MBR is not a single partition PMBR, its existence
invalidates the GPT. And at least gdisk doesn't want to modify the GPT
at all. But I can create a new GPT and PMBR, and in effect merge the
old MBR and GPT entries to protect the two El Torito EFI system
partitions, and the ISO 9660 image as a whole. Write this out to
/dev/vda without any complaint, and the resulting image still boots
BIOS and UEFI systems.

5. Upon reboot, /dev/vda4 exists, a large empty partition. The idea is
to format it, but all of the following commands fail with EBUSY:
# mkdosfs /dev/vda4
# mkfs.ext4 /dev/vda4
# mkfs.xfs /dev/vda4
# mkfs.btrfs /dev/vda4
# btrfs device add /dev/vda4 /run/rootfsbase  [1]

6. Color me confused. Granted, despite cleaning up the conflicting MBR
and GPT, this is still an odd duck. ISO 9660 ostensibly is a read-only
format, and /proc/mounts shows

/dev/vda /run/initramfs/live iso9660
ro,relatime,nojoliet,check=s,map=n,blocksize=2048 0 0

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.

Thanks,

--
Chris Murphy

[1]
The last one for the future fs-devel trivia pursuit game. There is a
mounted btrfs "seed" on /run/rootfsbase, and it's possible to make it
a read-write "sprout" merely by adding a writable device. The command
implies mkfs and file system resize. Once it completes, it's possible
to remount,rw and all changes are directed to this device.

-- 
Chris Murphy

^ permalink raw reply	[flat|nested] 3+ messages in thread