Failed to copy large file

[daveTheOldCoder]

Pop!_OS 20.04 LTS

Popsicle 1.3.3172177329820.04~3a87912

Hardware: Thelio-b1

I attempted to flash a Memorex 16GB USB Flash Drive with ubuntu-24.04-desktop-amd64.iso, which was downloaded from https://ubuntu.com/download/desktop and has size 6.1 GB.

Popsicle reported that the operation was completed, and did not display any error messages.

I attempted to boot from the flash drive; there were errors.

Then I used the cmp command to verify the contents of the flash drive:
sudo cmp -n stat -c '%s' ubuntu-24.04-desktop-amd64.iso ubuntu-24.04-desktop-amd64.iso /dev/sdb

In the above code, this should be enclosed in backticks, but they don't appear in this post: stat -c '%s' ubuntu-24.04-desktop-amd64.iso

The cmp command indicated there were differences.

Then I used the dd command to flash the drive:
sudo dd bs=4M if=ubuntu-24.04-desktop-amd64.iso of=/dev/sdb status=progress oflag=sync

That failed with an error that there was not enough space on the device.

I used gparted to reformat the partition on the flash drive to "cleared", and then tried the same dd command.

That was successful; the same cmp command produced no output.

I had previously used Popsicle to successfully flash various Pop!_OS .iso files, which were much smaller, onto the same model of flash drive.

[leviport]

I used gparted to reformat the partition on the flash drive to "cleared", and then tried the same dd command.

That was successful; the same cmp command produced no output.

Did you happen to also try Popsicle again after reformatting the drive?

[daveTheOldCoder]

I don't think so, but I'm not sure.

But why would that matter? Shouldn't Popsicle erase the contents of the drive?

Actually, I wouldn't think that the dd command would need the drive to be reformatted either. But it's possible that I used /dev/sdb1 rather than /dev/sdb as the dd command's destination, which might explain it.

[leviport]

I'm just sussing out what might have happened and looking for more definitive information. A good bug report has to be reproducible in order to be actionable, and flashing an Ubuntu ISO to a flash drive is a very routine thing for Popsicle. In my experience, it doesn't even have a problem flashing EndlessOS ISOs, which are in the neighborhood of 20gb. If dd also failed the first time, but succeeded after the drive was formatted, then the device may have been in some kind of weird state that was giving both utilities troubles.

To confirm whether or not dd was used on /dev/sdb1, rather than /dev/sdb, you could check your bash history.

[daveTheOldCoder]

I checked my bash history, and the first time I used dd the destination was /dev/sdb1.

I think the USB flash drive was a new one that I had never used before the first attempt to flash it using Popsicle. It was unlabelled and in the original package. The package originally contained three flash drives, and I had used two of them. But it's not impossible that I had used the drive and returned it to the package.

It's also possible that the drive is defective or was in a weird state, although I successfully booted from it and installed Ubuntu 24.04. If you want to send me a prepaid envelope, I don't mind giving you the drive so you can run diagnostics on it.

Does Popsicle completely erase the contents of the drive to which it's writing? Does it verify the contents of the drive after the write operation by using cmp, sha256sum or an equivalent method?

I've used Popsicle several times to make Pop!_OS boot drives, and this is the first time I've had a problem.

[mmstick]

The GTK application uses the udisks2 dbus service to dd images to devices, so it's not performed by the application itself. The CLI application does directly write to USB disk devices in parallel. Regardless, any prior signatures should be the first to get overwritten when imaging.

[daveTheOldCoder]

Unfortunately, I can't tell whether that answers my questions. 😄