fdisk -l fails to show partition table, while lsblk succeeds

[scanlom]

Hello,

I'm running Linux Mint 19 on an ASUS VivoBook S14, and have somehow gotten into a situation where fdisk cannot see my partitions. They _are_ visible to lsblk and the "disks" utility. Has anyone seen this before or know what may be going on? Output of fdisk and lsblk below.

A bit more info - for the past few years I've upgraded to the latest mint version every six months. I keep two os partitions, using a separate one every six months, flipping back and forth. This happens to be the second upgrade on this particular laptop.

Code: Select all

scanlom@asus-mint-18 ~ $ sudo fdisk -l
Disk /dev/sda: 477 GiB, 512110190592 bytes, 1000215216 sectors
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: 0x09bebfcf

Device     Boot   Start     End Sectors  Size Id Type
/dev/sda1  *          0 3855295 3855296  1.9G  0 Empty
/dev/sda2       3843044 3847715    4672  2.3M ef EFI (FAT-12/16/32)

Code: Select all

scanlom@asus-mint-18 ~ $ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   477G  0 disk 
├─sda1   8:1    0   524M  0 part /boot/efi
├─sda2   8:2    0  46.6G  0 part /
├─sda3   8:3    0  46.6G  0 part /mnt/prev
├─sda4   8:4    0  14.9G  0 part [SWAP]
└─sda5   8:5    0 368.4G  0 part /mnt/data

Thanks,
Mike

[WharfRat]

Hello scanlom

Welcome to Linux Mint and the Linux Mint forum

I certainly don't have an explanation for that, but did you notice also that fdisk shows /dev/sda1 as empty and /dev/sda2 as EFI yet lsblk shows sda1 as the efi partition and sda2 as / (root)

Never seen root mounted to a FAT filesystem.

What does sudo blkid show and if you have gparted installed take a look at its layout.

[scanlom]

Thanks for the welcome, great to be here! I've been using Mint for years but never had a reason to post, as the knowledge base is already so high quality

Right, the root file system is acutally ext4...in short, I don't trust fdisk or gparted at all, for some reason they are not picking up the correct partition table. Below is sudo blkid, this shows the correct info:

Code: Select all

scanlom@asus-mint-18 ~ $ sudo blkid
[sudo] password for scanlom: 
/dev/sda1: UUID="EE91-DFE7" TYPE="vfat"
/dev/sda2: UUID="16841716-5fbb-48a0-bde8-47bc83da01de" TYPE="ext4"
/dev/sda3: UUID="61575d05-ae83-49d7-8767-fca73e7f76f3" TYPE="ext4"
/dev/sda4: UUID="7ee76343-1274-4d08-9410-f2dcd1afba93" TYPE="swap"
/dev/sda5: UUID="6d5902bc-8d9b-435e-8c39-2088eb558e7e" TYPE="ext4"

[WharfRat]

Just out of curiosity what versions of fdisk and lsblk do you have

Mine are as follows:

Code: Select all

[bill@XPS] ~/script $ lsblk --version
lsblk from util-linux 2.27.1
[bill@XPS] ~/script $ fdisk --version
fdisk from util-linux 2.27.1
[bill@XPS] ~/script $ 

[scanlom]

Looks like 2.31.1:

Code: Select all

scanlom@asus-mint-18 ~ $ lsblk --version
lsblk from util-linux 2.31.1
scanlom@asus-mint-18 ~ $ fdisk --version
fdisk from util-linux 2.31.1

[puddleglum]

It's been a long time since I've used fdisk. Does fdisk handle efi partitions now? It used to only handle MBR partitions. I'm wondering if you got an old invalid MBR entry that fdisk is seeing while the other tools are seeing the correct efi entries.

[WharfRat]

It's been a long time since I've used fdisk. Does fdisk handle efi partitions now? It used to only handle MBR partitions. I'm wondering if you got an old invalid MBR entry that fdisk is seeing while the other tools are seeing the correct efi entries.

fdisk does handle gpt partitions

Code: Select all

Disk /dev/sda: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: D407431D-2E85-4D6E-B9C3-C1D1B8ED0371

Device           Start         End    Sectors  Size Type
/dev/sda1         2048     1050623    1048576  512M EFI System
/dev/sda2      1050624   104802303  103751680 49.5G Linux filesystem
/dev/sda3  11687616512 11721043967   33427456   16G Linux swap
/dev/sda4    104802304   155133951   50331648   24G Linux filesystem
/dev/sda5    155133952   205465599   50331648   24G Linux filesystem
/dev/sda6    205465600   255797247   50331648   24G Linux filesystem
/dev/sda7    255797248   306128895   50331648   24G Linux filesystem
/dev/sda8    356460544  5682278399 5325817856  2.5T Linux filesystem
/dev/sda9   5996851200 11687616511 5690765312  2.7T Linux filesystem
/dev/sda10  5682278400  5996851199  314572800  150G Microsoft basic data
/dev/sda11   306128896   356460543   50331648   24G Linux filesystem

The OP's Disklabel type is dos so I'm quite surprised that it's not reporting correctly.

I'm kinda leaning toward a bug with version 2.31.1 of both utilities.

[scanlom]

And of course, with all my hacking around, I managed to delete my partition table I did a full install of 19.1, now fdisk -l looks good (below). In the end, puddleglum I suspect you are right, I think I somehow had an invalid MBR that wasn't causing an issue with the mint boot but was messing up fdisk. During my 19 install I installed an MBR at least once and then wiped it out on subsequent installs.

Another note, on my Asus VivoBook S14 the 19 USB bootable install does not work, from searching on the forums it looks like USB 3.0 incompatibility combined with my Asus not having a way to force USB 2.0 behavior. So I've been installing 18.3 and immediately upgrading in place through to 19.1...which is a bit round about but works fine.

Code: Select all

scanlom@asus-mint-18 ~ $ sudo fdisk -l
[sudo] password for scanlom:        
Disk /dev/sda: 477 GiB, 512110190592 bytes, 1000215216 sectors
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: gpt
Disk identifier: 90CF0C11-2157-401E-AD5C-E8E5E5BDE20C

Device         Start        End   Sectors   Size Type
/dev/sda1       2048    1023999   1021952   499M EFI System
/dev/sda2    1024000   98680831  97656832  46.6G Linux filesystem
/dev/sda3   98680832  196337663  97656832  46.6G Linux filesystem
/dev/sda4  196337664  225634303  29296640    14G Linux swap
/dev/sda5  225634304 1000214527 774580224 369.4G Linux filesystem