Resizing Linux Partition After Deleting Windows

Xavier333 · 2024-07-13 01:52:06

Hello,

I had already mounted the Arch Linux system partitions and successfully dual-booted Arch Linux with Windows. However, I decided to stop dual booting. I deleted all Windows file systems using fdisk on Linux, but I am now unable to resize the Linux file system partition to utilize the free space. Fdisk states that I have 349.2G of free space.

How can allocate these 349.2G of memory to Linux filesystem partition? Just resizing it does not work.

Last edited by Xavier333 (2024-07-13 01:52:46)

ConnahGriffin · 2024-07-13 02:28:32

Can you run a few commands first for me and answer some questions?

What sort of file system do you use on your main partition? Can you show me the output from

sudo fdisk -l  /dev/sdX

? I may be able to help you or give you an option with these answered.

Xavier333 · 2024-07-13 15:10:14

I can use

 sudo fdisk -l /dev/nvme0n1

The output is:

Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: Micron_2210_MTFDHBA512QFD
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: 6B5694A8-0CAE-45AE-9691-E19CEC33008A

Device             Start        End   Sectors   Size Type
/dev/nvme0n1p6 732416000  734513151   2097152     1G EFI System
/dev/nvme0n1p7 734513152  763873279  29360128    14G Linux swap
/dev/nvme0n1p8 763873280 1000215182 236341903 112.7G Linux filesystem

Head_on_a_Stick · 2024-07-13 15:30:46

Unfortunately the Linux partitions occupy the upper sector numbers so enlarging the partition directly is problematic.

If you're using btrfs or zfs or LVM you could add a new partition in the lower sector section of the disk and incorporate that into your current filesystem. Failing that, backing up the system then re-partitioning the disk to copy it back would be my favoured approach. I think gparted might be able to "move" the partition from the live environment but making a backup first would be prudent anyway.

Xavier333 · 2024-07-13 16:21:58

If I use gpart, will it be necessary to remount my partitions afterward?

Head_on_a_Stick · 2024-07-13 16:26:20

"Moving" the root partition will likely have consequences for the bootloader and also in respect of /etc/fstab configuration, which may be rendered incorrect.

Which bootloader do you use? Where is the EFI system partition mounted in the running system?

Last edited by Head_on_a_Stick (2024-07-13 16:26:45)

Xavier333 · 2024-07-13 16:34:30

I use GRUB and my EFI system is mounted on /dev/nvme0n1p6

Last edited by Xavier333 (2024-07-13 16:34:41)

cryptearth · 2024-07-13 17:17:54

I would recommend against trying to move something around - it comes with a high risk of data loss.
If available: use another disk, preferable formatted with a linux filesystem, to fully backup your data - wipe the drive and start over from scratch.
Even on flash storage the actual physical storage location has a fixed address - and that can't be moved without re-assign the locations address (which I don't any drive current or in history which support that on a physical level) or move the data physical.
I'm also quite curious how you ended up with an ESP at that address - as there should had been the 100mb or so initially created by windows at the very start - in that case the "extended boot partition" scheme using a type-id of XBOOTLDR is a neat way as just a bootloader often fit on a windows esp - and from several posts multiple ESP on the same drive can lead to issues.

If there's a way it won't be easy as you want to move the start of a partition whoch requires reformatting for new super blocks.
Maybe some tool can "move" it - but I wouldn't try it from the running system - that just asks for trouble.

Head_on_a_Stick · 2024-07-13 20:15:37

Xavier333 wrote:

my EFI system is mounted on /dev/nvme0n1p6

Yes, I can see that. Where is the mountpoint? Are you using /boot/, /boot/efi/, /efi/, or something else?

If you're not sure this command from the running system will show us:

lsblk -f

The problem with relying on gparted is that I think you would have to delete the ESP & swap partitions in order to be able to "move" the root partition, which makes things a lot more complicated than the alternative backup-and-restore approach.

Xavier333 · 2024-07-14 20:16:38

Output of lsblk -f:

NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p6 vfat   FAT32       8693-E550                             810.9M    21% /boot
├─nvme0n1p7 swap   1           ff4b28cd-bc1e-4825-a274-ab1a619449d0                [SWAP]
└─nvme0n1p8 ext4   1.0         603aceac-921e-401a-a00d-6b2d9a5063b1   81.4G    13% /

V1del · 2024-07-14 20:43:21

You'd not have to delete the partitions if you're using gparted. You can just move all of them and then expand to the right. In theory trivial and gparted makes it trivial -- in practice an expensive and dangerous operation should anything fail while it's happening.

Make sure you have backups of stuff you can't afford to lose and then do it with gparted. Deleting and recreating partitions is unnecessary work assuming everything goes well, you'll have to move the bulk of data on root anyway regardless.

kermit63 · 2024-07-14 21:06:43

Also make sure you have a working arch usb installer in case you need to recreate the GRUB menu entries. AFAIK moving the vfat partition may erase the UEFI boot entries, hence the need to reinstall GRUB.

Last edited by kermit63 (2024-07-14 21:45:51)

cryptearth · 2024-07-14 21:12:01

V1del wrote:

Deleting and recreating partitions is unnecessary work

I'm not sure about if "modifying" of the partition table is part of spec - but in the end isn't "deleting and recreating" what most tools would do anyway?
ESP and swap will be scraped - and aside from the new super blocks there shouldn't be any move of data required as long as the new partition still spans the current region?
GPT is quite dynamic, so are modern filesystems - but are we already at a point where a simple "move" can be seen reliable?

Nikolai5 · 2024-07-15 07:45:12

I think the point is, telling them that moving is potentially dangerous for the data so they should instead delete their data and start from fresh is no different to them trying gparted and it failing. So they might as well take a backup of their stuff, then try gparted, if it works, and there's a good chance it will, then fantastic, if it fails they can start from fresh.

cryptearth · 2024-07-15 09:42:12

Ah, got it. Thanks!

Arch Linux

#1 2024-07-13 01:52:06

Resizing Linux Partition After Deleting Windows

#2 2024-07-13 02:28:32

Re: Resizing Linux Partition After Deleting Windows

#3 2024-07-13 15:10:14

Re: Resizing Linux Partition After Deleting Windows

#4 2024-07-13 15:30:46

Re: Resizing Linux Partition After Deleting Windows

#5 2024-07-13 16:21:58

Re: Resizing Linux Partition After Deleting Windows

#6 2024-07-13 16:26:20

Re: Resizing Linux Partition After Deleting Windows

#7 2024-07-13 16:34:30

Re: Resizing Linux Partition After Deleting Windows

#8 2024-07-13 17:17:54

Re: Resizing Linux Partition After Deleting Windows

#9 2024-07-13 20:15:37

Re: Resizing Linux Partition After Deleting Windows

#10 2024-07-14 20:16:38

Re: Resizing Linux Partition After Deleting Windows

#11 2024-07-14 20:43:21

Re: Resizing Linux Partition After Deleting Windows

#12 2024-07-14 21:06:43

Re: Resizing Linux Partition After Deleting Windows

#13 2024-07-14 21:12:01

Re: Resizing Linux Partition After Deleting Windows

#14 2024-07-15 07:45:12

Re: Resizing Linux Partition After Deleting Windows

#15 2024-07-15 09:42:12

Re: Resizing Linux Partition After Deleting Windows

Board footer