qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 2/2] hw/sd/sdcard: Do not allow invalid SD card sizes


From: Kevin Wolf
Subject: Re: [PATCH 2/2] hw/sd/sdcard: Do not allow invalid SD card sizes
Date: Fri, 10 Jul 2020 11:58:27 +0200

Am 09.07.2020 um 16:15 hat Peter Maydell geschrieben:
> On Thu, 9 Jul 2020 at 14:56, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> >
> > On 7/7/20 10:29 PM, Niek Linnenbank wrote:
> > > So I manually copy & pasted the change into hw/sd/sd.c to test it.
> > > It looks like the check works, but my concern is that with this change,
> > > we will be getting this error on 'off-the-shelf' images as well.
> > > For example, the latest Raspbian image size also isn't a power of two:
> > >
> > > $ ./arm-softmmu/qemu-system-arm -M raspi2 -sd
> > > ~/Downloads/2020-05-27-raspios-buster-lite-armhf.img -nographic
> > > WARNING: Image format was not specified for
> > > '/home/me/Downloads/2020-05-27-raspios-buster-lite-armhf.img' 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.
> > > qemu-system-arm: Invalid SD card size: 1.73 GiB (expecting at least 2 GiB)
> > >
> > > If we do decide that the change is needed, I would like to propose that
> > > we also give the user some instructions
> > > on how to fix it, maybe some 'dd' command?
> >
> > On POSIX we can suggest to use 'truncate -s 2G' from coreutils.
> > This is not in the default Darwin packages.
> > On Windows I have no clue.
> 
> dd/truncate etc won't work if the image file is not raw (eg if
> it's qcow2). The only chance you have of something that's actually
> generic would probably involve "qemu-img resize". But I'm a bit
> wary of having an error message that recommends that, because
> what if we got it wrong?

What is your concern that we might get wrong? The suggestion is always
extending the size rather than shrinking, so it should be harmless and
easy to undo. (Hm, we should finally make --shrink mandatory for
shrinking. We've printed a deprecation warning for almost three years.)

Kevin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]