Fedora 43 fresh setup did not use entire drive

I have setup a new fresh F43 and indicated to use the entire disk 50GB. once I log and issue

sudo lsblk

I see

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 50G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 2G 0 part /boot
└─sda3 8:3 0 48G 0 part
└─fedora_pemaster-root 252:0 0 15G 0 lvm /
sr0 11:0 1 1024M 0 rom
zram0 251:0 0 5.7G 0 disk [SWAP]

sda3 is 48GB but fedora_pemaster-root is only 15 GB which is not what I was expecting.

I switched to gui gnome-disks, I see the following but cant modify it here not creating a new partion nor resizing

I was able to resize the dev/pemaster/root using

sudo lvextend -L +5G /dev/mapper/fedora_pemaster-root

sudo xfs_growfs /dev/mapper/fedora_pemaster-root

Now I have 30GB available on sda3 and need to create a data disk/partition but not sure how to do this. Thanks for your help

I assume that you installed the Fedora Server.

It always leaves a lot of free space on the assumption that you will need to create work load specific partitions.

Normally this is the right choice.

The desktop editions of Fedora will use the entire disk.

I usually setup my servers with LVM so that I can add/remove/shrink/grow partitions as required.

I also would note that when using an xfs file system it is possible to grow the file system but that it cannot be shrunk. Unlike an ext4 file system that can be both grown and shrunk as needed.

Using LVM it is quite possible to add additional logical volumes in the unallocated space within the existing volume group. There are many commands related to using LVM related to Physical Volumes (PV), Volume Groups (VG), and Logical Volumes (LV). These can be seen by using a command such as ls /usr/bin/lv* for the LVs and similarly use ls /usr/bin/pv* for the PVs and ls /usr/bin/vg* for the VGs.

The command to create that LV file system would be lvcreate. Use the man page for lvcreate (man lvcreate) to see the exact syntax needed. You will need to specify both the VG to use and the size and name of the new LV being created.

Thanks Jeff, I managed to the 30GB and mounted it as /mnt/mydata. However, I followed instructions for setting up PostgresQL as indicated at How to change PostgreSQL's data directory on Linux - DEV Community then moved its data to this mount, in the instructions, It was mentioned “if SELinux is in enforcing mode, temporarily set it to permissive mode (0)” which I did by running

setenforce 0

I was able to start the postgresql service and access the DBs. However, when I revert back to

setenforce 1

reboot the VM, the postgresql service fails to start as it needs to authenticate to be ablle to access the mount. I revert the setenforce to 0 and the service starts.

How this can be fixed while having setenforce = 1? Thanks for your help

I am not an selinux guru, but you should be able to set the proper context on the directory tree containing the db and allow postgresql to access it.

Check the selinux context on the original location for the db and try switching the selinux context of /mnt/mydata to match.

Sounds like we should split the topic at this point - we’re no longer talking about anything to do with the installer and partitioning.

It is still related to the issue that started this topic and various issues that stemmed from that.

Jeff, inside the instructions there is a step which I executed as follows

semanage fcontext --add --equal /var/lib/pgsql /home/pgdata
restorecon -rv /home/pgdata
setenforce 1

Which I think should make context the same , no?

Try restorecon -rvF /home/pgdata which is more thorough about resetting things in the target directory.

If that still doesn’t work, it would be useful to run sudo ausearch -m avc -ts recent and see exactly what SELinux violations are happening.

Here is the output

$ sudo ausearch -m avc -ts recent

time->Fri Apr 24 18:12:16 2026

type=AVC msg=audit(1777047136.291:472): avc: denied { search } for pid=2640 comm=“postgres” name=“/” dev=“dm-1” ino=2 scontext=system_u:system_r:postgresql_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0

time->Fri Apr 24 18:12:39 2026

type=AVC msg=audit(1777047159.403:490): avc: denied { search } for pid=2700 comm=“postgres” name=“/” dev=“dm-1” ino=2 scontext=system_u:system_r:postgresql_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1

time->Fri Apr 24 18:12:39 2026

type=AVC msg=audit(1777047159.404:491): avc: denied { search } for pid=2700 comm=“postgres” name=“/” dev=“dm-1” ino=2 scontext=system_u:system_r:postgresql_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1

time->Fri Apr 24 18:12:39 2026

type=AVC msg=audit(1777047159.404:492): avc: denied { search } for pid=2700 comm=“postgres” name=“/” dev=“dm-1” ino=2 scontext=system_u:system_r:postgresql_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1

time->Fri Apr 24 18:12:39 2026

type=AVC msg=audit(1777047159.421:493): avc: denied { search } for pid=2700 comm=“postgres” name=“/” dev=“dm-1” ino=2 scontext=system_u:system_r:postgresql_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1

time->Fri Apr 24 18:12:39 2026

type=AVC msg=audit(1777047159.422:494): avc: denied { search } for pid=2700 comm=“postgres” name=“/” dev=“dm-1” ino=2 scontext=system_u:system_r:postgresql_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1

time->Fri Apr 24 18:15:04 2026

type=AVC msg=audit(1777047304.104:520): avc: denied { search } for pid=2705 comm=“postgres” name=“/” dev=“dm-1” ino=2 scontext=system_u:system_r:postgresql_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0

time->Fri Apr 24 18:15:05 2026
type=AVC msg=audit(1777047305.927:531): avc: denied { search } for pid=2806 comm=“postgres” name=“/” dev=“dm-1” ino=2 scontext=system_u:system_r:postgresql_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0

Then it looks like postgres is searching in the root of dm-1, and SELinux is denying that.

Sorry, I don’t know the answer, but it doesn’t seem like there’s a problem with what you did for /home/pgdata, because these denials aren’t related to anything in that path.

hmmm :slight_smile: if you cant what should I sya myself as I am not expert in Linux, only a user