Back in the day my Linux distro of choice was Slackware and the name of the game was dual boot systems. We did not have all the modern virtualization capabilities like what is available at our fingertips now. I still have that old Slackware system and it stills chugs along in a tower that I built out myself with various parts. I could not afford a computer then and this particular system lived in my closet in boxes as I purchased parts here and there until that fateful weekend when it all came together.

It is amazing that this was 18 years ago and that system still hums along with an Intel Celeron overclocked to 450Mhz. Even more amazing is that it is a prime example of how technology has evolved over the years, the advancement in speed of memory and processors is just amazing as I stand looking back at this old hunk of parts. I digress.

Over the weekend a newer Lenovo workstation was reborn with Fedora 28 on it, which is another bit of nostalgia that hit me. Back in the day, setting up a Linux distro could be a very tedious and lengthy chore, not to mention having to then install and configure everything one might want to use on the OS. One of the qualities I liked about Slackware back in the day was that it did not do everything for you and you were required to learn how everything worked.

It looks like Slackware may be slacking as the latest version released was 14.2 and that was over 2 years ago. Another nostalgia moment.

I guess I have gotten older, wiser, maybe lazier, or something, because I enjoyed setting up Fedora on this system, it was painless, and went smoothly. The only oddity that I ran into was due to the workstation’s previous life as a Windows machine, which caused it to fail to boot successfully after setup was complete due to the EFI deployment.

The boot issue was resolved with a quick modification using the efibootmgr to set the correct boot entry. EFI – Extensible Firmware Interface developed by Intel, which evolved into UEFI as a unification standard for firmware interface managing boot service calls available to the OS and generally contains a lightweight shell. You can read more at: http://www.uefi.org.

More to the solution, I have a newer Lenovo workstation that leverages UEFI and the correct boot loader is not configured by default, so this means pointing it to the correct file with the following command after booting to a rescue shell:

[user@host ~]# efibootmgr -c -L “Windows Boot Manager” -l “\EFI\fedora\grubx64.efi”

After this, I was up and running, mostly and this is where I get to the “maybe lazier” part as I let anaconda do the default install instead of defining the disk allocation of my 2Tb disk. The only problem here was that it chose to make the root mount / only 16Gb, which was definitely not big enough for my plans, so this meant a mild adjustment using lvextend to extend the logical volume and then fsadm to resize the file system.

Sounds pretty involved, however only a couple commands necessary once one decides on the size they want to extend to and how to arrive at it. First we want to do a little fact finding to get information about our volume group with vgdisplay. This will provide us with the amount of free physical extents and size as well as the physical extent size itself:

[user@host ~]#vgdisplay

— Volume group —

VG Name fedora

…

PE Size 4.00 MiB

…

Free PE / Size 330285 / 1.26 Tib

I left out everything here except the information we really need, feel free to run this for yourself to see the full output. With a physical extent(PE) size of 4.00 MiB one could surmise that dividing the Free Size in MiB by 4 would get them pretty close to the number of extents needed, however we can get more precise by converting the Free Size to MiB and dividing it by the number of Free PE, Free Size / Free PE.

Let’s approach this for a target size increase of 50 GiB

• 1.26 TiB = 1260000 MiB
• Free MiB / 4 = 315000 PE
• Free Size / Free PE = 3.81488714, not quite 4.00 MiB
• Free MiB / (Free Size / Free PE) = 330285 PE, sanity check holds true
• 50 GiB = 50000 MiB
• Number of PE = 50000 / 3.81488714 = 13106.5476
• Rounding this number up we can arrive at 13107 PE to end up at right at 50 GiB

If the logic of dividing by 4 were used we would fall a little short, but in most cases be pretty close, some might consider that close enough. Moving right along, we now know how many physical extents required and can extend the logical volume with this information:

[user@host ~]# lvextend -l +13107 /dev/fedora/root

If you check the disk allocation at this point you will see that the disk still shows the old value of 16 GiB. The reason here is fairly obvious, because we have only extended the logical volume, so one more step is required to extend the file system.

[user@host ~]# df -h | grep root

/dev/mapper/fedora-root 16G 12G 4G 75% /

Using fsadm to perform the final resize of the file system:

[user@host ~]# fsadm resize /dev/mapper/fedora-root

[user@host ~]# df -h | grep root

/dev/mapper/fedora-root 66G 12G 54G 18% /

Now we have a much more likable amount of disk allocated to our root mount. Good stuff! Now for some VM action, which was even easier due to the Virtual Machine Manager utility virt-manager.

I was able to add the first VM with virt-manager pretty quickly and easily by installing it from the same DVD that was used for setting up the workstation. After the first machine the command line utility for cloning was used:

[user@host ~]# virt-clone –original <original_vm> –name <new_vm> –file </vm/image/file>

Ran this twice and now I have a fresh Fedora install with 3 VM’s up, running, and ready for my next project, which should be completed in about 6 – 8 months!

This whole endeavor was a little exciting. For many years now, the last thing I want to do when I get home from work is get on a computer. Another bit of nostalgia striking me in the face, as back in the day it was Quake, LAN parties, and all night gaming. My, how times change.