Questions & Issues Resizing /boot/efi Partition, and home + root LVs

[ExesCarnival0891]

I finally have time to reinstall my OS after coming across trouble relating to the /boot/efi partition and the change to grub2-bls. My goals for this installation are simple:

1. Resize the EFI partition to 4GB
2. Resize the LVs so that the root LV takes only up to 100GB, and the rest goes to the home LV (with some going to swap)

I was hoping with the 2nd goal that I do not need to erase the data on my home LV but I have a backup to restore from. So if overwriting the existing LVs with new ones (erasing all the data) is better then I am not mad.

Here is what my current setup looks like (partitions and LVs on my current installation). In all previous installations, I only used guided partitioner.

My main goal is to resize the EFI partition. However, I cannot seem to modify it from guided or expert partitioner. I cannot resize the currently existing EFI partition, and while I forgot to take a picture of it, nor can I create a partition larger than 1GiB.

I cannot resize the other partitions since they are either currently being used by /dev/system, or they similarly cannot be resized beyond what they are currently taking up.

I am not entirely familiar with what I am exactly doing, so any help with this would be appreciated

[exception]

i may suggest using gparted live iso to resize and any partitioning needed and then just set the mount point and the format nesserly during the installation

another thing i notice you try to resize encrypted partitions i think they need extra steps like decrypting them first if i remember correctly if you don’t care about the data in them you can just destroy them and grow the ESP partion from the unalocated space and then create new encrypted partion while installing

[shundhammer]

First of all, you need to make space because all the disk space is already assigned to existing partitions. The /dev/nvme0n1p2 LVM PV would be a hot candidate because it’s right next to your ESP (EFI System Partition). You could remove it from its LVM VG, which would leave a gap of unpartitioned space, and then you could resize the ESP to use that as well.

That would give you 1.91 GiB total space for the ESP; less than you wanted, but double the amount that you have now.

The ESP is just a VFAT partition, so technically it should be possible to resize it, and YaST can resize VFAT partitions (which could be an ordinary Windows partition as well); proabably it’s the ESP partition type that makes it refuse it. But as @exception wrote, you might want to use parted for that.

But for the LVM operations (removing the PV etc.) I’d recommend the YaST partitioner.

You could also simply give up the existing ESP and create a new one instead; for example, resize the NTFS “RESTORE” partition, or delete it entirely. Since you already deleted Windows completely from your machine, I don’t think the vendor’s Windows restore partition will do you any good, much less on the much faster SSD; this seems very wasteful IMHO.

Think about deleting the NTFS partition and turn it into a new ESP with the size that you like, and add another PV in the remaining space. Once you have a new ESP, mount it, copy everything from the old ESP to that new one (sudo rsync -rtv --modify-window=2 /boot/efi /mnt), change the partition type of the old ESP to just VFAT for now (you should only have one of that type!), and reboot to check if it works. If that was successful, delete the old ESP and also turn it into a PV and add it to one of your LVM VGs. And of course adapt the /boot/efi entry in /etc/fstab to use the new ESP (probably the UUID; use sudo blkid to find out).

Old men’s PC legacy lore:

If you wonder about the --modify-window=2: Back in 1980 when FAT filesystems were designed, the directory entry was short one bit for the timestamp (mtime), so they decided to use only 2-second precision, so they could save that one bit. That means that copying between a FAT filesystem and any native Linux fileystem could result in slightly different timestamps, so repeating an rsync command to make sure that nothing is left would always find a difference. --modify-time=2 relaxes this check to 2 seconds.

HTH

[ExesCarnival0891]

Thank you for the information. I do want clarification on a few things before I go ahead with them.

1. For doing the LVM operations in YaST, I would need to unmount the /home directory. I do not think it is safe to unmount the device I am currently on. Should I used gparted for these operations instead?
   
   
2. I do know the resizing partitions/PVs could lead to data loss, but in this case neither my /home or /root PVs are half full. I am still at risk of data loss in this case, or will resizing just affect the “empty” space in both PVs?
3. I think I might need more detailed instructions in opting to remove the NTFS “RESTORE” partition:

@shundhammer

Think about deleting the NTFS partition and turn it into a new ESP with the size that you like, and add another PV in the remaining space. Once you have a new ESP, mount it, copy everything from the old ESP to that new one (sudo rsync -rtv --modify-window=2 /boot/efi /mnt), change the partition type of the old ESP to just VFAT for now (you should only have one of that type!), and reboot to check if it works. If that was successful, delete the old ESP and also turn it into a PV and add it to one of your LVM VGs. And of course adapt the /boot/efi entry in /etc/fstab to use the new ESP (probably the UUID; use sudo blkid to find out).

Deleting the partition and adding a new ESP are simple enough. I haven’t manually mounted a device/partition before. I looked around and found instructions in the Arch Wiki. Would I do mount /boot/efi /mnt to mount it? In addition, how would I change the old ESP to VFAT? I assume I would also use terminal for that since the partitioner doesn’t give me an option to change specifically to VFAT (just FAT).

[shundhammer]

@ExesCarnival0891

For doing the LVM operations in YaST, I would need to unmount the /home directory. I do not think it is safe to unmount the device I am currently on. Should I used gparted for these operations instead?

Fair point. No, gparted wouldn’t help you here because it’s the same situation: Working on a mounted partition. But you only need /home for your regular user account; logging in as root from your graphical login manager would work around this problem, because then you could safely unmount /home (because the home directory for root is /root).

It is also possible to boot from an installation medium, switch to a text console and issue LVM commands from there, but this is more complicated and has a higher risk of catastrophic failure.

I am just wondering if it’s sufficient to unmount /home in this scenario; since there is only one VG and multiple PVs, all LVs of the VG probably share those PVs, so it might ask you in the next step to also unmount / which obviously can’t work. AFAIK the PVs are a pooled resource for the VG and not assigned to any LV directly.

But it’s easy enough to try when logging in as root.

[shundhammer]

Useful resource:

Storage Administration Guide

Yes, SLES, but also valid for openSUSE. I didn’t find that Storage Administration Guide for openSUSE.

[shundhammer]

@ExesCarnival0891

• I do know the resizing partitions/PVs could lead to data loss, but in this case neither my /home or /root PVs are half full. I am still at risk of data loss in this case, or will resizing just affect the “empty” space in both PVs?

Resizing is always a two-step process:

• Resize the container object, i.e. the partition or LVM LV
• Resize the filesystem inside that container (here: btrfs resize)

Obviously, to resize smaller, first resize the filesystem, then the container; to resize larger, first the container, then the filesystem.

LVM has the big advantage that you can add PVs at any time, and remove PVs as long as not all that disk space is already allocated. All PVs are treated as a large pool of disk space for that VG; that’s also the rationale for YaST typically not assigning all available disk space to, say, the root filesystem.

LVM allocates disk space in terms of extents to LVs, i.e. just a part of a PV at a time. The extent size is configurable, by default 4 MiB. Exactly where on the disk any LV is located isn’t easy to say; or you could say it’s “all over the place”, one extent here, one extent there, all handled by the device mapper. As long as there is still free disk space on any PV, those extents may be reallocated, e.g. to another PV; this is transparent. See also man pvmove.

If you decide to repurpose your “Restore” partition as another PV, you could do that beforehand: Delete that partition, recreated it as a PV (don’t forget the encryption!), add it to the VG; then there is plenty of free space, and moving things around should be much easier.

@ExesCarnival0891

• I think I might need more detailed instructions in opting to remove the NTFS “RESTORE” partition:

That’s the easiest part: Select it, if it’s mounted, unmount it, click “Delete”, confirm.

Then decide if this is where you want to put your ESP, and create either a new ESP from part of that partition and a PV right after it (think about encryption for the PV!), or just a large PV.

[shundhammer]

@ExesCarnival0891

Deleting the partition and adding a new ESP are simple enough. I haven’t manually mounted a device/partition before. I looked around and found instructions in the Arch Wiki.
Would I do mount /boot/efi /mnt to mount it?

Exactly that; but this is only a temporary mount for copying the content of the old ESP to it (the rsync ... command in my first post).

@ExesCarnival0891

In addition, how would I change the old ESP to VFAT? I assume I would also use terminal for that since the partitioner doesn’t give me an option to change specifically to VFAT (just FAT).

The partition type (ID in GPT lingo) here is “Windows Data Partition”.

The filesystem type for formatting is the more generic FAT; the exact subtype (FAT16, FAT32) is chosen automatically depending on the partition size, and VFAT is chosen automatically to enable more than the old MS-DOS 8+3 filenames. But of course you shouldn’t format it just yet, you want to copy the content first.

Just for completeness (you are probably aware of that): Make sure to back up the content of your /home filesystem, at least your home directory or any photo / video / music collection that you want to keep.

Nothing bad should happen, but this is hardcore partitioning; there is always a risk of something going wrong and thus data loss.

[exception]

@shundhammer thank you for sharing you knowledge i learned a lot

@ExesCarnival0891 i just want to add you could use live ISO and work freely insted of gparted live iso so you can install any tools you want including gparted and mix and match how ever you see fit

maybe use opensuse live ISO so you could use YAST partioner , KDE partioner , gparted and any manual tool you want on top of it

but it’s not recmonded to install from the live ISO

[jonzn4suse]

I would just get a new drive and bring the needed data from the old one.
Don’t you want a shiny new and faster drive?!

[malcolmlewis]

It should be “EFI System Partition” from memory (Not sure if “Windows Data Partition” is the same…), as long as the type is set to ef00 in gdisk speak…

[shundhammer]

No, this is about handling the old ESP after a new one was created, to make sure there is only one ESP on the disk. Simply changing the type to “Windows Data Partition” makes it available as a simple VFAT partition. But as I wrote, it could be better used as yet another PV.