BarryK wrote:
When you use "dd" to write to a flash drive, it shouldn't matter what was on the drive before.
However, GPT is strange -- it has a secondary GUUID Partition table at the physical end of the drive. And this is where I am suspicious that may be the cause of problems with resizing that you guys are reporting, but not me. I am wondering if a left-behind secondary GPT is confusing sfdisk.
Coz dd is only going to write the approx. 8GB image, and everything past that is as it was before.
A secondary GPT that is different from the main one, would certainly be the cause of the error reported by Gparted.
There are various ways to fix this. A simple "dd if=/dev/zero ..." to the end of the drive would wipe the old invalid GPT.
Actually, fdisk does fix this at bootup when a f.s. resize is being performed. But it is before that, at the first bootup, where we have the problem -- sfdisk getting confused and thus not offering to do a resize in the first place.
Hi Barry,
I think you should write a simple explanation on your website and also let it be known here:
It is flatout crazy that anyone who does a compressed image install using the dd command does not
first do a complete dd wipe of that install device, whether they had GPT-related partitions previousy or not. Especially this is true if they've previously used that device for other pups, pup-related & any-Linux installs..just dd wipe it first, then dd install it.
For all Quirky installs (acutally since you first released the format of compressed images), I run this command first:
dd if=/dev/zero of=/dev/sd# bs=1M. After that, only then do I follow your dd-ing command for installing to that device.
Thus, I believe, make the above mandatory, for installation instructions for Quirky and/or any compressed image install. I know, from experience, that what suspicions you have now and are writing about must be happening. More than a few times I have found friends, knowledgeable Linux friends, who make the mistake of doing an compressed image install to a USB/SD/external drive where they first did not do a complete dd-ing wipe pass. These exact same problems being described here pop up. The only way to get the problems resolved is by starting over, first dd-ing the "whole" device (even large drives), then doing the dd command for the compressed image.
It is my opinion no one should ever think that dd-ing once with a compressed image install is going to be all peaches and roses.
Two levels of dd-ing everyone, not one.
That'll let Barry (and us all) focus on other issues