Weird usb partitioning issues

unixbot443 · 2026-04-24 18:54:18

I am experiencing some weird USB partitioning issues. In gparted, my usb stick does not show the full size, and when there should be 3 partitions, only 1 is listed. lsblk shows 3 partitions. When I go to do a dd to write a iso (~4gb) to usb, it takes ~2s. I've tried 2 different usb sticks now, and get the same thing.

Mercury · 2026-04-24 19:03:01

Unfortunately, I don't have any insight, but I have encountered instances where gparted was "confused" about the partitions on a drive but CLI tools (including parted!) correctly recognized the layout. I've been suspicious of it ever since.

rolfie · 2026-04-24 19:26:53

Defective or fake stick?

unixbot443 · 2026-04-24 19:29:18

Nope, they were working previously.

greenjeans · 2026-04-24 23:26:34

Okay, in general it depends on the tool you used to create partitions. Gparted has a flaw where it can't always read a USB properly, but it's not altogther Gparted's fault all the time. There are a number of tools to create a liveUSB, and a lot will install your iso, but they take up the entire stick with one iso-9660 partition. Unless the tool that you used to create any new partitions pre-emptively wiped the free space before it created your new partitions, it will frequently leave a small signature of 5 bytes that still identifies it (at least to Gparted) as one big partition.

The gnome-disk-utility should "see" your other partitions correctly, but even if you make new ones with it Gparted still won't "see" them even if GDU and your file-manager do, because GDU doesn't pre-emptively wipe either. But it will see extra partitions even if Gparted won't.

Both gnome-related, so good luck with getting them to admit it's an issue or fix it.

Last edited by greenjeans (2026-04-24 23:27:18)

Elyon · 2026-04-25 20:52:19

Have you tried wiping all partition info on the usb?

sudo dd if=/dev/zero of=/dev/sdX bs=1M status=progress

guuml.dev1 · Today 00:27:41

There is a BIG "weird" (not really;-) distinction between USB stick and USB hard disk: The "type of storage" depends on the partition table found on the device. And "device" means for example /dev/sdb XOR /dev/sdb1.

Given you're creating a boot stick from some image with dd of=/dev/sdb if=./cool-devuan your stick becomes a kind of CD or DVD: there is only one partition with the size of the image! On the other hand gparted /dev/sdb shows you the whole space on the device just because the found partition table is interpreted a similar way like grub will do.

There is no supposed "flaw" in gparted: GÜ has spent his last raw DVD to chimaera and has checked that DVD with several machines successfully. GÜ has copied that 1.9GB image to a 32 GB USB-Stick (your devices may differ)

dd if=./cool-devuan of=/dev/sdc

The BIOS/UEFI recognizes the Stickas a "bootable CD" and boots successfully, BUT gparted /dev/sdc shows roughly 30GB unused spaced on the stick. And that is good! Doing a dd of=/dev/sdbc1 if=./cool-devuan and creating a filesystem on /dev/sdc2 while keeping the stick bootable is left as an exercise to the reader.

steve_v · Today 02:51:02

The only "flaw" here is the usual confusion regarding partitions, filesystems, and the x86 boot process.
isohybrid is a hack, and writing an iso image to a USB device does not create a normal partition table - that's the whole point, to be bootable from optical media it needs to look exactly like a CD to the BIOS routines.
CDs don't have partitions or an MBR, the raw iso9660 filesystem starts at sector 17 and the space before that is an "unused" system area to be used by [insert system-specific boot hackery here] - often syslinux and/or a partition table defining an ESP for UEFI in a bootable GNU/Linux image.
Thus what you usually end up with is a disk where the partition table does not reflect reality, intentionally, the first few reserved sectors contain an el-torito CD boosector, an MBR, a GPT, syslinux, or some combination of those, and the whole mess appears to be a simple iso filesystem to anything that doesn't look too hard.

All this will confuse traditional partitioning tools, especially if the device was previously partitioned and whatever you used to write the image didn't remove the existing partition table (and backup), RAID headers, or whatever else was on there.
It's not a "flaw" in parted, iso9660 on anything but optical media was just never supposed to be a thing and the spec for what should be at the start of the disk is intentionally vague.

Ed. Also, this.

Having a bootable iso image and other filesystems on one device simultaneously is even more of a hack, and generally requires installing a (second) bootloader that can chainload an iso9660 [insert system-specific hackery here] boot record or handle loop-mounting the filesystem and locating the kernel image itself... This is why grub-imageboot and ventoy exist, and it's also why they are so complicated and unreliable.

On the OP: Make sure the device is properly clean, first with a (fast) tool like wipefs, and if that doesn't do it, nuke the entire device with a (slow) cp or dd from /dev/zero. Check the latter can write the entire expected size of the device - if it can't then what you have is likely a hardware problem.
As for "takes ~2s", you're probably just seeing write-cache. Try oflag=direct to bypass kernel caches (see dd manpage).

Last edited by steve_v (Today 03:53:25)

The officially official Devuan Forum!

#1 2026-04-24 18:54:18

Weird usb partitioning issues

#2 2026-04-24 19:03:01

Re: Weird usb partitioning issues

#3 2026-04-24 19:26:53

Re: Weird usb partitioning issues

#4 2026-04-24 19:29:18

Re: Weird usb partitioning issues

#5 2026-04-24 23:26:34

Re: Weird usb partitioning issues

#6 2026-04-25 20:52:19

Re: Weird usb partitioning issues

#7 Today 00:27:41

Re: Weird usb partitioning issues

#8 Today 02:51:02

Re: Weird usb partitioning issues

Board footer