1 (edited by lastflight 2018-10-13 20:22:39)

Topic: [SOLVED] GParted sees partiton as 100% full but it's not

Hello.

I am trying to shrink a partition. This is Ubuntu 18.04. df shows that it is far from full: only 41% in use. Yet, when I run gparted (from the live CD) it shows use: 100%. Unsurprisingly, gparted refuses to shrink said partition.

Any ideas why I am getting this discrepancy?

Regards,
Michael

PS - What I am really trying to do is enlarge the boot partition, which is too small for Ubuntu 18.04 to update. To do that I have to shrink and shift the partition that follows, which occupies the remainder of the SSD.

2

Re: [SOLVED] GParted sees partiton as 100% full but it's not

Never seen GParted report a partition / file system as 100% full when it's no where near full.

To diagnose the issue please provide the following:

1. Screen shot of the relevant partition.  GParted > Partition > Information.

2. Partition layout.

sudo parted /dev/sda print
sudo fdisk -l /dev/sda
sudo gdisk -l /dev/sda
sudo lsblk -o name,maj:min,rm,size,ro,type,fstype,label,mountpoint

3. Mounted file system usage.

df -k

4. File system minimum size and super block dump.  (This assumes the file system is ext4, ext3 or ext2.  Replace /dev/sda2 with the actual device name).

sudo resize2fs -P /dev/sda2
sudo dumpe2fs -h /dev/sda2

3

Re: [SOLVED] GParted sees partiton as 100% full but it's not

@lastflight, if Ubuntu 18.04 is installed into an LVM2 PV (Logical Volume Manager - Physical Volume) then that would explain what you are seeing.  LVM is a special type of formatting that permits spanning disks and partitions.  You would need to use commands like

lvresize

to shrink LVM2 LVs (Logical Volumes) to free up space first.  Then you could use GParted to reclaim unallocated space within the LVM2 PV.

4

Re: [SOLVED] GParted sees partiton as 100% full but it's not

Thank you very much for the replies.
@mfleetwo, I will certainly provide the information. Unfortunately, I can't do it tonight.
@gedakc, you could be on the right track. Again, I'll have to make some time tomorrow.
Regards, Michael.

5

Re: [SOLVED] GParted sees partiton as 100% full but it's not

Hello.
I have the pictures you requested, @mfleetwo, but I don't understand how to make them appear in this post. Let's hope for better luck with the rest.

$ sudo parted /dev/sda print
Model: ATA SanDisk SDSSDHP1 (scsi)
Disk /dev/sda: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type      File system  Flags
 1      1049kB  256MB  255MB  primary   ext2         boot
 2      257MB   128GB  128GB  extended
 5      257MB   128GB  128GB  logical                lvm

$ sudo fdisk -l /dev/sda
Disk /dev/sda: 119.2 GiB, 128035676160 bytes, 250069680 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: 0x0000763e

Device     Boot  Start       End   Sectors  Size Id Type
/dev/sda1  *      2048    499711    497664  243M 83 Linux
/dev/sda2       501758 250068991 249567234  119G  5 Extended
/dev/sda5       501760 250068991 249567232  119G 8e Linux LVM

$ sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. 
***************************************************************

Disk /dev/sda: 250069680 sectors, 119.2 GiB
Model: SanDisk SDSSDHP1
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 0385AB0C-9C54-495D-B0C2-2FD470DCA4B1
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 250069646
Partitions will be aligned on 2048-sector boundaries
Total free space is 4717 sectors (2.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          499711   243.0 MiB   8300  Linux filesystem
   5          501760       250068991   119.0 GiB   8E00  Linux LVM

$ sudo lsblk -o name,maj:min,rm,size,ro,type,fstype,label,mountpoint
NAME                  MAJ:MIN RM   SIZE RO TYPE FSTYPE      LABEL        MOUNTPOINT
sda                     8:0    0 119.2G  0 disk                          
├─sda1                  8:1    0   243M  0 part ext2                     /boot
├─sda2                  8:2    0     1K  0 part                          
└─sda5                  8:5    0   119G  0 part LVM2_member              
  ├─ubuntu--vg-root   253:0    0 115.5G  0 lvm  ext4                     /
  └─ubuntu--vg-swap_1 253:1    0   3.5G  0 lvm  swap                     
sdb                     8:16   0  55.9G  0 disk                          
├─sdb1                  8:17   0  47.9G  0 part ext4                     /usr/Caches
├─sdb2                  8:18   0     1K  0 part                          
└─sdb5                  8:21   0     8G  0 part swap                     [SWAP]

# n.b. /dev/mapper/ubuntu--vg-swap_1 isn't mounted, swap is /dev/sdb5

$ df -k
Filesystem                   1K-blocks      Used  Available Use% Mounted on
/dev/mapper/ubuntu--vg-root  119079172  45951108   67056156  41% /
/dev/sda1                       240972     88253     140278  39% /boot
/dev/sdb1                     49303344   6009456   40766304  13% /usr/Caches

It's a shame Windows messes up the output of lsblk.
[mfleetwo: I've fixed the lines in lsblk output.]

For resize2fs and dumpe2fs, it looked like I had to do them with the disk unmounted, but it still failed. Here's what I got:

user@debian:~$ sudo resize2fs -P /dev/sda2
resize2fs 1.44.4 (18-Aug-2018)
open: No such device or address while opening /dev/sda2

user@debian:~$ sudo resize2fs -P /dev/sda5
resize2fs 1.44.4 (18-Aug-2018)
resize2fs: Device or resource busy while trying to open /dev/sda5
Couldn't find valid filesystem superblock.

I haven't forgotten I still have to investigate LVM, @gedakc. But I have run out of time. So that will be for another night.
Michael.

6

Re: [SOLVED] GParted sees partiton as 100% full but it's not

So this is an overview of your first disk layout:

/dev/sda  119 GiB

   Partition                             Type        Size      FS Type   Label       Mount Point

+- /dev/sda1                             Primary     243 MiB   ext2                  /boot
|
+- /dev/sda2                             Extended    119 GiB
   |
   +- /dev/sda5                          Logical     119 GiB   LVM2 PV               ubuntu-vg  (LVM Volume Group name)
      |
      +- /dev/mapper/ubuntu--vg-root     LVM LV   115.5 GiB    ext4                  /
      |
      +- /dev/mapper/ubuntu--vg-swap_1   LVM LV     3.5 GiB    swap

So to answer your original question:

lastflight wrote:

I am trying to shrink a partition.  This is Ubuntu 18.04. df shows that it is far from full: only 41% in use.  Yet, when I run gparted (from the live CD) it shows use: 100%.  Unsurprisingly, gparted refuses to shrink said partition.

Any ideas why I am getting this discrepancy?

So you must have been looking at sda5 and seen the LVM Physical Volume as 100% full, containing the Volume Group ubuntu-vg (and it's fully sized Logical Volumes for the root file system and reportedly unused swap).


MAKE SURE YOU HAVE BACKUPS OF ANY DATA YOU CARE ABOUT.

GParted only handles a sub-part of LVMs; the Physical Volumes, not the Volume Groups or Logical Volumes.  Therefore some of the follow are commands to be run on the command line:

1. Boot from GParted Live CD (or other Live CD with GParted).  This is to allow the root (/) file system to be shrunk.
2. Shrink root (/) file system by 256 MiB.  Close GParted and run "gparted /dev/mapper/ubuntu--vg-root".  Resize the file system making it 256 MiB smaller than before.  Apply operation and close GParted.
3. Shrink root volume group by 256 MiB.  This can't be done in GParted.  Run:

lvm lvresize --size -256M /dev/ubuntu-vg/root

4. Run GParted.
5. If sda5 is active (lock or key symbol in Partition column), deactivate it.
6. Resize sda5 making it 256 MiB smaller than before.   NOTE: This might succeed or might fail with "cannot resize to XXX extents as later ones are allocated".  Assuming it succeeds continue.
7. Move sda5 to the right as far as possible (by 256 MiB).  Apply.
8. Move sda2, the start of the extended partition as far to the right as possible (by 256 MiB).  Apply.
9. Finally grow sda1 as much as possible (by 256 MiB).  Apply.
10. Reboot back to Ubuntu.


If shrink of sda5 failed with "cannot resize to XXX extents as later ones are allocated" then:

a. Based on your claim that /dev/ubuntu-vg/swap_1 is not used, delete it:

lvm lvremove /dev/ubuntu-vg/swap_1

b. Go back and re-run from step 6. onwards.

If /dev/ubuntu-vg/swap_1 is used Ubuntu probably won't boot and you'll have to remove that entry from /etc/fstab to fix.

7

Re: [SOLVED] GParted sees partiton as 100% full but it's not

Thank you @mfleetwo, that was very detailed. It looks like I need to organize a clone operation with clonezilla before I start.
So @gedakc guessed right without even seeing the layout.
If I understand correctly, GParted cannot see through the LVM layer. But, if you tell it where to look

mfleetwo wrote:

gparted /dev/mapper/ubuntu--vg-root

, it will serve you well. Fantastic!

mfleetwo wrote:

a. Based on your claim that /dev/ubuntu-vg/swap_1 is not used,

I am quite sure of that. I added the second disk myself and commented out the line in /etc/fstab about the original swap. But, whether I need it or not, I might as well recover the space.

I will report back when I am all cloned and, hopefully, owning a larger boot partition.

8

Re: [SOLVED] GParted sees partiton as 100% full but it's not

All done. Thank you very much @mfleetwo.
There was a scary moment after moving the root partition: GParted came up with a pop-up saying in essence that it had failed to inform the kernel of the move. I thought about it for a while and decided to ignore that.
Now I have a very large boot partition and my first Ubuntu 18 update happened without a hitch.
All that remains is to figure out how to mark this thread as SOLVED. smile smile