[SOLVED] 1TB SSD df -h shows 137GB available of 150GB

AliSrc · 2020-09-17 22:51:49

Hi everyone.

This should be my first post. I use this forum frequently to find answers. Thank you all!

I have searched in this forum and google etc. without any luck. That's why I'm creating a new topic.

I know the ext4 takes 5% from the drive but my problem is;
I have an SSD with 1TB space. With a fresh install of Arch, I followed the Wiki Installation Guide as always. It even shows my boot partition as 500MB but its a 1GB partition

Output of df -h:

Filesystem      Size  Used Avail Use% Mounted on
dev              16G     0   16G   0% /dev
run              16G  1,2M   16G   1% /run
/dev/nvme0n1p2  150G  5,0G  137G   4% /
tmpfs            16G     0   16G   0% /dev/shm
tmpfs           4,0M     0  4,0M   0% /sys/fs/cgroup
tmpfs            16G   16K   16G   1% /tmp
/dev/nvme0n1p1  511M   70M  442M  14% /boot
tmpfs           3,2G     0  3,2G   0% /run/user/1000

Difference between -h and -H is the size
Output of df -H:

Filesystem      Size  Used Avail Use% Mounted on
Filesystem      Size  Used Avail Use% Mounted on
dev              17G     0   17G   0% /dev
run              17G  1,2M   17G   1% /run
/dev/nvme0n1p2  161G  5,4G  148G   4% /
tmpfs            17G     0   17G   0% /dev/shm
tmpfs           4,2M     0  4,2M   0% /sys/fs/cgroup
tmpfs            17G   17k   17G   1% /tmp
/dev/nvme0n1p1  536M   74M  463M  14% /boot
tmpfs           3,4G     0  3,4G   0% /run/user/1000

Output of fdisk -l

Device           Start        End    Sectors   Size Type
/dev/nvme0n1p1    2048    2099199    2097152     1G EFI System
/dev/nvme0n1p2 2099200 2000409230 1998310031 952,9G Linux filesystem

Output of lsblk -a:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
nvme0n1     259:0    0 953,9G  0 disk
├─nvme0n1p1 259:1    0     1G  0 part /boot
└─nvme0n1p2 259:2    0 952,9G  0 part /

Fdisk shows the start sector and end sector right. I want to be able to use my entire disk.

What can it be?

Thank you all in advance

Last edited by AliSrc (2020-09-18 08:10:28)

djgera · 2020-09-17 23:25:30

Hola

The only explanation that I can guess is that you made the partitions on the SSD, then "clone" each filesystem with some "raw" method (for example "dd"). If that is the case, then just run resize2fs on "ext4" (I guess), and for the FAT32 copy all the data, format it and copy data again (EDIT: or use fatresize)

Good luck!

Last edited by djgera (2020-09-17 23:29:10)

AliSrc · 2020-09-17 23:30:05

djgera wrote:

Hola
The only explanation that I can guess is that you made the partitions on the SSD, then "clone" each filesystem with some "raw" method (for example "dd"). If that is the case, then just run resize2fs on "ext4" (I guess), and for the FAT32 copy all the data, format it and copy data again.
Good luck!

Thank you for your answer, but I installed from a bootable USB stick with Pacstrap. I followed the Wiki Installation Guide as I always did before. Exactly the same procedure but this time this happened.

Last edited by AliSrc (2020-09-17 23:30:33)

loqs · 2020-09-17 23:37:25

What tool did you use to partition the device?
Can you reproduce the issue to rule out user error? If so please post the exact commands used.

djgera · 2020-09-18 00:02:30

mmm interesting, strange.

What is the output of these commands?

tune2fs -l /dev/nvme0n1p2
grep nvme0 /proc/partitions

AliSrc · 2020-09-18 07:09:40

Hi,

I hope we solve the problem

djgera wrote:

mmm interesting, strange.
What is the output of these commands?
tune2fs -l /dev/nvme0n1p2
grep nvme0 /proc/partitions

Output of; tune2fs -l /dev/nvme0n1p2:

tune2fs 1.45.6 (20-Mar-2020)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          dd8b584a-e1dc-452b-9d83-6bf7e3c64131
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              10027008
Block count:              40108032
Reserved block count:     2005401
Free blocks:              38597255
Free inodes:              9951298
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Wed Sep 16 21:19:38 2020
Last mount time:          Wed Sep 16 23:23:48 2020
Last write time:          Wed Sep 16 23:23:48 2020
Mount count:              9
Maximum mount count:      -1
Last checked:             Wed Sep 16 21:19:38 2020
Check interval:           0 (<none>)
Lifetime writes:          5951 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      fd9b273e-82f7-47ac-a210-6fd2c9a3386d
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x08096652

Output of; grep nvme0 /proc/partitions:

 259        0 1000204632 nvme0n1
 259        1    1048576 nvme0n1p1
 259        2  999155015 nvme0n1p2

Before this installation I've installed Fedora 32 just for try and see how it is, but before installing Arch again I formatted the drive with mkfs. Maybe a hint.

Last edited by AliSrc (2020-09-18 07:12:07)

AliSrc · 2020-09-18 08:09:09

I found the fix on askubuntu. If someone else faces the same problem here is the solution. Link to solution

I do not know if I can give a link to the solution if not I can remove it again.

Get a backup of all your data THIS IS IMPORTANT DO NOT SKIP IT
Boot with Arch iso USB Stick

Run:

lsblk /dev/nvme0n1p2 -o size
It should return:

Now that we are 100% sure about the actually home partition size.

Run check disk:

e2fsck /dev/nvme0n1p2

Run:

resize2fs /dev/nvme0n1p2

Mount the partition:

mount /dev/nvme0n1p2 /mnt

Check the size of filesystem:

df -h --out=size /mnt

Wild Penguin · 2020-09-18 14:05:15

Weird indeed, that should not happen. I'm happy you got it solved, however why it happened in the first place is undetermined.

One thing which could explain this, is that the SSD was not empty when you began. Then, if after partitioning, there just happens to lie a file system in the to-be "/" partition, mkfs will bail out. But it should spit out an error at that point. So my question is: were there any errors? Those could be missed in case the user has never (or for only a very few times) run mkfs.ext4 before, and is not familiar with reading and interpreting the output at all...

Another alternative is that for some reason the Kernel was not addressing the whole block device, however if that was the case, the used partitioning tool would have failed too, and/or the partition would not be that large just by rebooting (but there should be non-partitioned space) ... so I can not see how something like this could have actually resulted in this situation.

AliSrc · 2020-09-19 12:37:34

Hi,

Me either. I also tried to shift to the LTS kernel, the same result. The only thing that fixed my problem was the solution above.

I tried the whole procedure when there was another OS installed, where I mkfs the partition without any error. This one is very strange. Lucky that it is solved now. thank you all.

Wild Penguin wrote:

Weird indeed, that should not happen. I'm happy you got it solved, however why it happened in the first place is undetermined.
One thing which could explain this is that the SSD was not empty when you began. Then, if after partitioning, there just happens to lie a file system in the to-be "/" partition, mkfs will bail out. But it should spit out an error at that point. So my question is: were there any errors? Those could be missed in case the user has never (or for only a very few times) run mkfs.ext4 before, and is not familiar with reading and interpreting the output at all...
Another alternative is that for some reason the Kernel was not addressing the whole block device, however if that was the case, the used partitioning tool would have failed too, and/or the partition would not be that large just by rebooting (but there should be non-partitioned space) ... so I can not see how something like this could have actually resulted in this situation.

Last edited by AliSrc (2020-09-19 12:39:18)

Arch Linux

#1 2020-09-17 22:51:49

[SOLVED] 1TB SSD df -h shows 137GB available of 150GB

#2 2020-09-17 23:25:30

Re: [SOLVED] 1TB SSD df -h shows 137GB available of 150GB

#3 2020-09-17 23:30:05

Re: [SOLVED] 1TB SSD df -h shows 137GB available of 150GB

#4 2020-09-17 23:37:25

Re: [SOLVED] 1TB SSD df -h shows 137GB available of 150GB

#5 2020-09-18 00:02:30

Re: [SOLVED] 1TB SSD df -h shows 137GB available of 150GB

#6 2020-09-18 07:09:40

Re: [SOLVED] 1TB SSD df -h shows 137GB available of 150GB

#7 2020-09-18 08:09:09

Re: [SOLVED] 1TB SSD df -h shows 137GB available of 150GB

#8 2020-09-18 14:05:15

Re: [SOLVED] 1TB SSD df -h shows 137GB available of 150GB

#9 2020-09-19 12:37:34

Re: [SOLVED] 1TB SSD df -h shows 137GB available of 150GB

Board footer