<div dir="ltr">This:<div><br></div><div>  $ sudo dd if=ubuntu-core-16-pi2.img of=/dev/sdb bs=32M;sync</div><div><br></div><div>Its sdb because I have the sdcard in a usb card reader.</div><div><br></div><div>Thanks!</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 10, 2016 at 3:58 PM, Oliver Grawert <span dir="ltr"><<a href="mailto:ogra@ubuntu.com" target="_blank">ogra@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hi,<br>
<span class="">Am Samstag, den 10.09.2016, 15:49 +0500 schrieb Omer Akram:<br>
> ><br>
> > <a href="https://bugs.launchpad.net/bugs/1619362" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>bugs/1619362</a><br>
> ><br>
> > there is nothing at the end off the image (the GPT backup that<br>
> > usually<br>
> > sits there gets re-created on first boot anyway when we check if<br>
> > the<br>
> > image is resizable) so technically you can just dd it and ignore<br>
> > the<br>
> > error it will throw without any actual drawbacks, no need to resize<br>
> > in<br>
> > advance since gparted will only move these zeros around.<br>
> I had tried that, it fails to boot, also the writable partition does<br>
> not even mount on my desktop if dd fails, due to lack of space.<br>
<br>
</span>this is weird, the main partition table and vfat definitely sit at the<br>
beginning of the disk, the only thing that could be corrupt (if there<br>
was actual data) should be the end of the writable partition. <br>
<br>
what is your dd command ? <br>
<br>
ciao<br>
        oli</blockquote></div><br></div>