Closed dankamongmen closed 3 years ago
OK, I was able to reproduce this. It has something to do with how we're creating (at least) GPT partition tables.
I have a Corsair USB device, /dev/sdc
:
[grimes](0) $ lsblk /dev/sdc
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdc 8:32 1 230.6G 0 disk
[grimes](0) $
The entirety of related dmesg
output is as follows:
[340809.825600] usb 2-2: new SuperSpeed Gen 1 USB device number 3 using xhci_hcd
[340809.843507] usb 2-2: New USB device found, idVendor=1b1c, idProduct=1a0a, bcdDevice= 1.10
[340809.843513] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[340809.843517] usb 2-2: Product: Survivor 3.0
[340809.843520] usb 2-2: Manufacturer: Corsair
[340809.843523] usb 2-2: SerialNumber: 07089880037D2799
[340809.845566] usb-storage 2-2:1.0: USB Mass Storage device detected
[340809.846198] scsi host4: usb-storage 2-2:1.0
[340810.866617] scsi 4:0:0:0: Direct-Access Corsair Survivor 3.0 000A PQ: 0 ANSI: 6
[340810.867672] sd 4:0:0:0: Attached scsi generic sg2 type 0
[340810.868252] sd 4:0:0:0: [sdc] 483655680 512-byte logical blocks: (248 GB/231 GiB)
[340810.868584] sd 4:0:0:0: [sdc] Write Protect is off
[340810.868593] sd 4:0:0:0: [sdc] Mode Sense: 45 00 00 00
[340810.869006] sd 4:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[340810.988389] sdc: sdc1
[340810.991306] sd 4:0:0:0: [sdc] Attached SCSI removable disk
same behavior with a lengthy stall on gpart
.
This is blkid_partlist_get_table
returning NULL
.
So blkid
identifies this as MBR, even though we supposedly just prepared a GPT partition table on it:
[grimes](0) $ sudo blkid /dev/sdc
/dev/sdc: PTTYPE="PMBR"
[grimes](0) $
I pulled the drive and put it back in, to ensure this isn't just a failure to update kernel data structures. Nope! Still PMBR; kernel sees no partitions, just /dev/sdc
.
and yet fdisk
shows us with a GPT:
[grimes](130) $ sudo fdisk /dev/sdc
Welcome to fdisk (util-linux 2.36.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/sdc: 230.63 GiB, 247631708160 bytes, 483655680 sectors
Disk model: Survivor 3.0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdc1 * 1 4294967295 4294967295 2T ee GPT
Command (m for help):
Hrmmm, we see GPT, but check out that "Disklabel: dos". that doesn't seem right!
wait, is that suggesting that i have a GPT ... something inside of an MSDOS partition?
gparted
says:
Both the primary and backup GPT tables are corrupt. Try making a fresh table, and using Parted's rescue feature to recover partitions.
grimes $ sudo gparted /dev/sdc
Unit \xe2\x97\x8f.service does not exist, proceeding anyway.
GParted 1.1.0
configuration --enable-libparted-dmraid --enable-online-resize
libparted 3.3
Both the primary and backup GPT tables are corrupt. Try making a fresh table, and using Parted's rescue feature to recover partitions.
[grimes](0) $ sudo gparted /dev/sdc
Unit \xe2\x97\x8f.service does not exist, proceeding anyway.
GParted 1.1.0
configuration --enable-libparted-dmraid --enable-online-resize
libparted 3.3
Both the primary and backup GPT tables are corrupt. Try making a fresh table, and using Parted's rescue feature to recover partitions.
So there are two bugs here: we're generating corrupt GPT tables (this might be due to the zlib change for crc), and we're not displaying devices without partition tables, let alone that they have damaged partition tables (like gparted can).
I'll make another bug for the corrupt GPT tables.
ok that EE business is just the protective MBR; i'd forgotten about that
With a correctly-formed header, we display the device fine (see #117). So yeah, we just need to handle the damaged header case.
Got it.
I've got /dev/sdk:
gpart has some real problems with it, stalling out over many seconds:
growlight-readline
does not list it in blockdev output, and loops on the following diagnostic:it doesn't show up at all in
growlight
.hdparm
shows: