[Qemu-devel] [Bug 1474263] Re: "Image format was not specified" warning should be suppressed for the vvfat (and probably nbd) driver

[Max Reitz]

Yes, it does appear, you just need to make vvfat rw:

$ qemu-system-x86_64 -drive file.driver=vvfat,file.dir=foo,file.rw=on
vvfat foo chs 1024,16,63
WARNING: Image format was not specified for 'json:{"dir": "foo", "driver": 
"vvfat", "rw": "on"}' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write 
operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.

(The warning is not shown with R/O devices because they don’t have the
security issue.)

My point hasn’t changed, though,  I fundamentally agree with the points
in this report, but I don‘t think “fixing” this is worth it.

For NBD, “fixing” it would mean potentially breaking existing use cases
(which I still don’t see the point of, but there’s no point in breaking
them just to make a warning disappear).

For vvfat, there are three things: First of all, I don’t like it very much, so 
as I said, I’d rather deprecate it altogether (though this BZ shows we 
shouldn’t do that).
Secondly, in order for the warning to disappear, a protocol driver would need 
to enforce a certain format on top when probing.  That would require a bit of 
new infrastructure, although I have to admit it wouldn’t be impossible.
Thirdly, I suppose most people use vvfat with block device options like done in 
the bug report?  In that case, it is trivial to add a format=raw (or 
driver=raw), exactly like the warning suggests.

(Though you can use vvfat with a plain filename, too:

$  qemu-system-x86_64 fat:32:rw:foo
qemu-system-x86_64: warning: FAT32 has not been tested. You are welcome to do 
so!
vvfat foo chs 1024,16,63
WARNING: Image format was not specified for 'json:{"fat-type": 32, "dir": 
"foo", "driver": "vvfat", "floppy": false, "rw": true}' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write 
operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.

)

So all in all I think this is indeed kind of a bug (at least it’s a
nuisance that could be better), fixing it would not be impossible, but
it’s just very low on at least my priority list (probably somewhere
around “implement bdrv_refresh_filename() for vvfat so you don't get the
json:{} filenames you can see above”).

Max

** Changed in: qemu
       Status: Incomplete => Opinion

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1474263

Title:
  "Image format was not specified" warning should be suppressed for the
  vvfat (and probably nbd) driver

Status in QEMU:
  Opinion

Bug description:
  Running

  qemu -drive file.driver=vvfat,file.dir=.

  displays

  WARNING: Image format was not specified for 'json:{"dir": ".", "driver": 
"vvfat"}' and probing guessed raw.
           Automatically detecting the format is dangerous for raw images, 
write operations on block 0 will be restricted.
           Specify the 'raw' format explicitly to remove the restrictions.

  However, since "images" provided by the vvfat driver are always raw
  (and the first sector isn't writeable in any case), this warning is
  superfluous and should not be displayed.

  A similar warning is displayed for NBD devices; I suspect it should be
  also disabled for similar reasons, but I'm not sure if serving non-raw
  images is actually a violation of the protocol. qemu-nbd translates
  them to raw images, for what it's worth, even if it may be suppressed
  with -f raw.

  Noticed on 2.3.0; the code that causes this behaviour is still
  apparently present in today's git master
  (f3a1b5068cea303a55e2a21a97e66d057eaae638). Speaking of versions: you
  may want to update the copyright notice that qemu -version displays.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1474263/+subscriptions