DF != fdisk != gparted after new install [SOLVED]

tercan · 2018-11-05 07:33:07

Hi,

I can't understand why my partitions are all wrong after a fresh Arch Install. I setup the partitions using cfdisk in the live environment as follows:
/dev/nvme0n1p1 550M EFI:Fat32
/dev/nvme0n1p2 48G SWAP
/dev/nvme0n1p3 remainder (~900G) /:ext4

Everything started fine, but i've run out of disk space on root... and nothing makes sense... df-h reports:

Filesystem      Size  Used Avail Use% Mounted on
dev              16G     0   16G   0% /dev
run              16G  1.7M   16G   1% /run
/dev/nvme0n1p3   34G   14G   19G  43% /
tmpfs            16G   82M   16G   1% /dev/shm
tmpfs            16G     0   16G   0% /sys/fs/cgroup
tmpfs            16G  104K   16G   1% /tmp
/dev/nvme0n1p1  300M  1.2M  299M   1% /boot/efi
tmpfs           3.2G   64K  3.2G   1% /run/user/1000

fdisk /dev/nvme0n1 reports:

Disk /dev/nvme0n1: 953.9 GiB, 1024209543168 bytes, 2000409264 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: 4544511F-235A-40C9-9DA4-5A8BF121CA7C

Device              Start        End   Sectors  Size Type
/dev/nvme0n1p1       4097     618497    614401  300M EFI System
/dev/nvme0n1p2     618498  101283839 100665342   48G Linux filesystem
/dev/nvme0n1p3 1928264503 2000397734  72133232 34.4G Linux swap

and gparted reports:
https://cdn.pbrd.co/images/HLJ0dYd.png

fstab is:

# /dev/nvme0n1p3
UUID=73761df3-013f-4a70-a1f7-190e0fb84be3	/         	ext4      	
rw,relatime	0 1

# /dev/nvme0n1p1
UUID=34EE-00F1      	/boot/efi 	vfat      	rw,relatime,fmask=0022,d
mask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-r
o	0 2

# /dev/nvme0n1p2
UUID=62b6174d-f8d9-4d7e-84cc-c1c460fe77a6	none      	swap      	
defaults,pri=-2	0 0

lsblk is:

$ lsblk 
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sr0          11:0    1  1024M  0 rom  
nvme0n1     259:0    0 953.9G  0 disk 
├─nvme0n1p1 259:1    0   300M  0 part /boot/efi
├─nvme0n1p2 259:2    0    48G  0 part [SWAP]
└─nvme0n1p3 259:3    0  34.4G  0 part /

blkid is:

$ blkid
/dev/nvme0n1p1: UUID="34EE-00F1" TYPE="vfat" PARTUUID="436c8201-296d-4013-b2b5-5ef4caf8cf85"
/dev/nvme0n1p2: UUID="62b6174d-f8d9-4d7e-84cc-c1c460fe77a6" TYPE="swap" PARTUUID="cef5132b-0581-4e7a-a667-9e39ec8b9008"
/dev/nvme0n1p3: UUID="73761df3-013f-4a70-a1f7-190e0fb84be3" TYPE="ext4" PARTUUID="d0288f92-4379-42ab-bd66-314f87f1b67b"

Any ideas WHAT is going on here?!?

Last edited by tercan (2018-11-06 17:53:45)

jasonwryan · 2018-11-05 07:38:51

Read the Code of Conduct and only post thumbnails http://wiki.archlinux.org/index.php/Cod … s_and_code

seth · 2018-11-05 08:39:54

No idea what you did, but what happened is obvious: there's a 1826980664 sectro gap between your root and swap partition. This is unallocated space.
You could grow the partition (and the filesystem) easily, since it's forward adjacent.

Trilby · 2018-11-05 14:12:53

Seth, that wouldn't be forward - swap is the second partition, root is the third, he'd want to increase the third partition size backwards.

seth · 2018-11-05 14:49:37

Actually tehre's sth. odd indeed:

/dev/nvme0n1p2     618498  101283839 100665342   48G Linux filesystem
/dev/nvme0n1p3 1928264503 2000397734  72133232 34.4G Linux swap

vs.

├─nvme0n1p2 259:2    0    48G  0 part [SWAP]
└─nvme0n1p3 259:3    0  34.4G  0 part /

According to fdisk, the Linux partition sectors should be before (a giant gap and) the swap sectors… but that doesn't match the lsblk output?

Scimmia · 2018-11-05 15:05:36

lsblk doesn't tell us anything about sectors at all. Unallocated space means nothing to it.

seth · 2018-11-05 16:38:20

The devices are swapped between lsblk and fdisk as well, though (that's the weird part to me)

However, unless there's a typo in the fdisk output (other than the device names, the sector layout is the relevant part), growing the root partition should be straightforward.

Scimmia · 2018-11-05 18:34:20

Ah, you're looking at the partition type. Not really used for anything, AFAIK. Pretty meaningless.

tercan · 2018-11-05 18:40:15

Why would the partition type be useless? It's worrisome that each tool reports something different about the filesystem... And why would my partitions (which I formatted correctly) be so different when I booted into the actual disk (instead of the DF report in the live arch install env)?

What should I trust? Restoring a backup already failed because the root partition was reported as 34G...

It would be great if I could take the root partition and expand it backwards, but I haven't seen a safe way to do that... And even if I found a way, I'm still concerned the partition map is lying to me...

Scimmia · 2018-11-05 19:15:48

The partition type is just the entry in the partition table. I has nothing to do with what's actually there or with the filesystem and doesn't really man anything.

You keep saying that things don't match, everything you have posted makes sense.

tercan · 2018-11-05 19:26:10

They don't match given how I partitioned the disk in the first place...

Scimmia · 2018-11-05 19:33:43

How you think you partitioned the disk

tercan · 2018-11-05 19:42:32

does that mean I shouldn't trust cfdisk? I partitioned and wrote the partition map. The partitions were correct when I wrote them to disk... What I think is irrelevant. What cfdsik reported is relevant.

jasonwryan · 2018-11-05 19:45:21

tercan wrote:

I partitioned and wrote the partition map.

What is the likelihood of a cfdisk bug that no-one else has encountered versus PEBKAC?

Lone_Wolf · 2018-11-06 16:27:23

/dev/nvme0n1p1       4097     618497    614401  300M EFI System

this appears to be a GPT-disk .
cfdisk can't handle GPT disks, are you sure you used cfdisk and not cgdisk ?

Scimmia · 2018-11-06 16:54:29

cfdisk has handled gpt for years now.

tercan · 2018-11-06 17:48:24

More accurately, fdisk has handled GPT for a while now. cfdisk is just a terminal GUI wrapping it.

I fixed the problem by reinstalling, using gdisk, and blowing away the GPT table. Now my partitions are what I expect after creating them again.

RE: cfdisk... more context, this was my 2nd go with cfdisk. First install I saw the messed up partitions and assumed I fat-fingered something. The 2nd install I double checked my work and the partitions were still messed up.

Third time's a charm with gdisk

jasonwryan · 2018-11-06 17:51:09

Please remember to mark your thread as [Solved] by editing your first post and prepending it to the title.

Arch Linux

#1 2018-11-05 07:33:07

DF != fdisk != gparted after new install [SOLVED]

#2 2018-11-05 07:38:51

Re: DF != fdisk != gparted after new install [SOLVED]

#3 2018-11-05 08:39:54

Re: DF != fdisk != gparted after new install [SOLVED]

#4 2018-11-05 14:12:53

Re: DF != fdisk != gparted after new install [SOLVED]

#5 2018-11-05 14:49:37

Re: DF != fdisk != gparted after new install [SOLVED]

#6 2018-11-05 15:05:36

Re: DF != fdisk != gparted after new install [SOLVED]

#7 2018-11-05 16:38:20

Re: DF != fdisk != gparted after new install [SOLVED]

#8 2018-11-05 18:34:20

Re: DF != fdisk != gparted after new install [SOLVED]

#9 2018-11-05 18:40:15

Re: DF != fdisk != gparted after new install [SOLVED]

#10 2018-11-05 19:15:48

Re: DF != fdisk != gparted after new install [SOLVED]

#11 2018-11-05 19:26:10

Re: DF != fdisk != gparted after new install [SOLVED]

#12 2018-11-05 19:33:43

Re: DF != fdisk != gparted after new install [SOLVED]

#13 2018-11-05 19:42:32

Re: DF != fdisk != gparted after new install [SOLVED]

#14 2018-11-05 19:45:21

Re: DF != fdisk != gparted after new install [SOLVED]

#15 2018-11-06 16:27:23

Re: DF != fdisk != gparted after new install [SOLVED]

#16 2018-11-06 16:54:29

Re: DF != fdisk != gparted after new install [SOLVED]

#17 2018-11-06 17:48:24

Re: DF != fdisk != gparted after new install [SOLVED]

#18 2018-11-06 17:51:09

Re: DF != fdisk != gparted after new install [SOLVED]

Board footer