Hello.

Using GParted 0.25.0 on Ubuntu 16.04 - also using other burning methods such as "Etcher", "dd", etc.
Media: various USB thumb drives but generally at least 14 gigabytes.

Errors:

Constantly getting the "The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes." once the drive is formatted and opened in gparted

If i wipe the drive using: sudo dd if=/dev/zero of=/dev/sdX bs=1k count=2048 and load in gparted there are no errors but after burning with:

"sudo dd bs=4M if=/path/to/input.iso of=/dev.sdb" then open in gparted I see an additional 56 gigabytes and the message "The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes."

One obvious question which I can't find the answer to is this: when burning an .iso to a thumb drive using any method (gparted, dd, etcher, etc.) does the .iso (for example "ubuntu-16.04.5-desktop-amd64.iso") contain all of the necessary formatting including msdos, operating system code, UEFI codes, parameters, etc. to make a complete, usable thumb drive, or must the thumb drive *first* be formatted with msdos with some kind of formatting tool (dd, etcher, gparted)?

I might add this doesn't seem to be unique to gparted: if I use etcher or dd I get the same results: an additional 56 gigabytes added to a 14 gigabyte drive as well as once the writing has been done, the same message on opening gparted that "The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes."

Please advise what kind of troubleshooting information, output, is needed to assist me.

Just use dd to image your .iso file to the pendrive, the image contains everything needed, including the booting code.

There is no point in formatting the pendrive as it gets overwritten by the image.

1 members found this post helpful.

Yes, I did us dd, still getting the messages attached herein as images.

For example after burning the .iso (but not before) the USB now shows unformatted space at 59Gb.

Attached Thumbnails

     

Hi,

this looks like a confusion in libparted.
Just google for
"The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes"
but be critical towards the answers given.

The symptoms indicate that the software is confused by the filesystem
block size 2048 of ISO 9660 and the block size 512 of the partition table
inside the ISO.
The reason for this confusion might be that the ISO 9660 filesystem is not
confined in a partition.

The situation of ISO 9660 and partition tables is normal with most bootable
GNU/Linux ISOs for x86/x86_64 nowadays. libparted should recognize this
and suppress its urge to complain. All is well. Really.

As fatmac stated: It is futile to partition the stick in advance because
the ISO image has to be put on the base device and thus overwrites any
previously existing partition table.

If you tell me which ISO image you put on the USB stick, then i will
have a look at its entrails and explain them in detail.

Have a nice day

Thomas

it's not a problem.
what you "burned" is not a regular filesystem, but for some reason gparted does not understand.
just choose "Ignore". check the checksums, and boot into it (or whatever you're planning to do with it).

PS: didn't know gparted can burn usb sticks (perform dd copying). learned something.

Hi,

i forgot to explain the riddle of the 50+ GB size.

2048 divided by 512 is 4. 59.64 divided by 4 is 14.91.

This is not completely plausible yet, because a USB stick of 14.9 GiB
would probably be sold as 15 GB stick.

There might also be a confusion of merchant's GB (1 billion) and
programmer's GiB (2 exp 30 = 1,073,741,824).
If your stick has 14 GiB (14 times 2 exp 30) then it has slighly more
then 15 GB (15 * 10 exp 9). 4 times 15 is 60.

So if we assume not only cluelessness with ISO 9660 but also with
GiB <-> GB, and given that gparted reports 59.63 "GiB" i'd say your
stick has actually 14,907,500,000 bytes = 13.88 GiB.

If this is true, then you should really try out other partition editors.

-------------------------------------------------------------------

And since the label of /dev/sdb1 says "Ubuntu 16.04" and "amd64" we have
an ISO with the layout invented by Matthew J. Garrett for Fedora:

Partition 1 reaches from block 0 to the end of the ISO.

Partition 2 is located inside partition 1 (which nearly all partition
editors do hate) and has the role of EFI System Partition.

(There is also an invalid GPT, which any partition editor should ignore.)

So /dev/sdb1 is misrepresented by gparted as much too short (this fault
is somewhat excusable) and most of the blocks outside /dev/sdb2 are
misrepresented as unallocated (this is boldly wrong).


Have a nice day

Thomas