Extending an LVM volume: Physical volumes (partitions) -> Volume groups -> Logical volume -> Filesystem

Thanks.  I agree that having one partition for TurnKey makes the most sense as a default.

I'll definitely get around to trying EC2 so I can get a feel for things.  I especially need to figure out how easy it is to add space to the EC2 instance's root partition.

I would make a new App with the space you need somewhere, then migrate the old data in with TKLBAM.

You need to assign the API key to both.

Extending the Filesystem I did do once but forgot now how.

Easiest way to make a bigger install is to install from ISO then determine your HD/RAM and other sizes at start up.

My experience anyway.

Noticed there was another sda3 that was never extended. I extended it and resized. Wiki is back up and running.

#>lvextend -L +17.99G /dev/turnkey/root

Rounding up size to full physical extent 17.99 GiB
  Extending logical volume root to 40.01 GiB
  Logical volume root successfully resizedresize2fs /dev/turnkey/root
resize2fs 1.41.11 (14-Mar-2010)
Filesystem at /dev/turnkey/root is mounted on /; on-line resizing required
old desc_blocks = 2, new_desc_blocks = 3
Performing an on-line resize of /dev/turnkey/root to 10487808 (4k) blocks.
The filesystem on /dev/turnkey/root is now 10487808 blocks long.
root@aserver ~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/turnkey-root
                       40G   21G   17G  56% /
none                  120M  184K  120M   1% /dev
none                  123M     0  123M   0% /dev/shm
none                  123M   56K  123M   1% /var/run
none                  123M     0  123M   0% /var/lock
none                  123M     0  123M   0% /lib/init/rw
/dev/sda1             473M  437M   12M  98% /boot

Hi,

I know this is an old post but I inherited Turnkey and root is out if disk space and mysql will not load. I followed your article and it worked: but still 0% available, I think I am overlooking something simple. Any ideas? Thanks.

root@aserver~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/turnkey-root
                       22G   21G     0 100% /
none                  120M  184K  120M   1% /dev
none                  123M     0  123M   0% /dev/shm
none                  123M   56K  123M   1% /var/run
none                  123M     0  123M   0% /var/lock
none                  123M     0  123M   0% /lib/init/rw
/dev/sda1             473M  437M   12M  98% /boot

>

root@aserver ~# fdisk -l

Disk /dev/sda: 53.7 GB, 53687091200 bytes
4 heads, 32 sectors/track, 819200 cylinders
Units = cylinders of 128 * 512 = 65536 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000339d8

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        7813      500000   83  Linux
/dev/sda2            7825      305168    19030016   8e  Linux LVM
/dev/sda3          305169      573440    17169408   83  Linux
/dev/sda4          573441      819200    15728640   83  Linux

Disk /dev/sdb: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sdb doesn't contain a valid partition table
root@aserver ~# ls /dev/sd*
/dev/sda  /dev/sda1  /dev/sda2  /dev/sda3  /dev/sda4  /dev/sdb
root@aserver ~# pvcreate /dev/sda4
  Physical volume "/dev/sda4" successfully created
root@aserver ~# vgextend turnkey /dev/sda4
  Volume group "turnkey" successfully extended
root@aserver ~# lvextend -L+15 /dev/turnkey/root
  Extending logical volume root to 37.02 GiB
  Logical volume root successfully resized
root@aserver ~# resize
resize2fs   resizecons
root@aserver ~# resize2fs /dev/turnkey/root
resize2fs 1.41.11 (14-Mar-2010)
Filesystem at /dev/turnkey/root is mounted on /; on-line resizing required
old desc_blocks = 2, new_desc_blocks = 2
Performing an on-line resize of /dev/turnkey/root to 5771264 (4k) blocks.
The filesystem on /dev/turnkey/root is now 5771264 blocks long.

>

root@aserver~# vgdisplay
  --- Volume group ---
  VG Name               turnkey
  System ID
  Format                lvm2
  Metadata Areas        4
  Metadata Sequence No  15
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               2
  Max PV                0
  Cur PV                4
  Act PV                4
  VG Size               57.51 GiB
  PE Size               4.00 MiB
  Total PE              14722
  Alloc PE / Size       10116 / 39.52 GiB
  Free  PE / Size       4606 / 17.99 GiB
  VG UUID               xDapZk-53wD-mIKE-5OZQ-zd3M-EggS-enn5xC

If you install from the ISO the di-live installer allows you to setup a more advanced configuration if you want. TurnKey is Ubuntu under the hood so any partitioning scheme you would use for Ubuntu would also work with TurnKey. You may have to do some reconfiguring though (e.g., creating new logical volumes, moving data over, configuring mount points in fstab, etc.)

Regarding Amazon EC2, it lets you do exactly what you want via EBS (Elastic Block Store), which are high-speed SAN backed virtual storage devices that can be created and attached to an EC2 server instance on the fly. The Hub makes it very easy to use this functionality. You should try it.

One of the first things I did with my TKL lamp server was increase the size of the root partition but in hindsight I've wondered if it would be better to leave it's size alone and mount an additional storage partition.  Of course you can still use LVM to increase the second storage partition as needed.

It seems that would be a simpler method to manage storage and that method should work as well whether I am running the server in VMware or in Amazon EC2.  It also seems like the separation of large data from the TKL appliance would inherently make it simpler to swap TKL appliances if needed.

More importantly, I'm wondering if there are any issues with the way Amazon instances and storage space are handled that would make either extending root partition or mounting an additional partition a more sensible approach for adding storage space.  I haven't used Amazon's EC2 yet so I don't have any hands-on experience but my impression is that it would be simpler to keep the root partition as standard as possible and just mount additional storage partitions as needed.

Anyone have any insight they'd like to share?

I don't have immediate need for this info and have only just given it a quick scan (rather than a proper read) but appreciate it never the less. I will get back to this and have a good read as LVM is a bit of a mystery to me (I get the basic idea but it still seems a bit esoteric). I'm sure that many others will really appreciate it too.

There already is, and it's pre-installed in all TurnKey appliances v11+.

IIRC, log into webmin -> Hardware ->LVM

Thank you for the clarification. Much clearer now. Any potential of there being a webmin mod for this?

Thanks so much for this Liraz! It worked a treat! Very easy to figure out due to your very simple and clear instructions =D

Last week I extended my Physical Volume in VMWare but ran into the block of not being able to expand the LVM.  I missed the "middle part" about Volume Groups.   I will study and Test.  The Webmin module sounds good (for newbs like me).

Expanding the physical volume itself was pretty easy in VMware (use the Thin format), but unlike in windows, VMWare does not have an easy way to work with Linux Partitions after that - at least that I could find.  The methodologies above will be more than helpful.

TKL uses LVM by default, so this is very relevant for TKL users. If you are looking for more general Ubuntu partitioning info then you would probably want to have a look at this and this.

You need parted istalled, which, for some reason, is not included in the core turnkey setup.

This is great, thanks!

Loving TKL!

Yay! :)

I'm using tkFileServer and I used example #2.

I'm still pretty newb-ish with Linux, but, this helped me gain a better understanding of how LVM works.

I have 3 Windows 7 computers to back up: one gaming rig, one DAW, and a VMware server host; and 18~ GB is hardly enough space for one initial backup, much less three.

Thanks Liraz!

But I have heard some good things about it. I personally use ProxmoxVE and find it really good. TKL installs to KVM no worries (from ISO) and I have also converted lots of images to run under OVZ (PVE has both). Theoretically the TKL VM images should be able to be imported into KVM but I have only played with it once and dind't have any joy (I didn't try real hard because it's pretty quick and easy to install from ISO). But I agree a KVM image that could be easily imprted would be a plus.

dd is pretty slow but I have successfully dd'd up to 250GB images over a network (SHH) successfully on a number of occasions. That's how I migrated my physical Win2K3 server to a KVM VM. I just used a live CD and dd'd the HDD to a .raw image and KVM picked that up fine. But as I say that was with PVE not Eucalyptus so obviously YMMV.

We're going to publish images optimized for Eucalyptus soon. It would be great to get your feedback on that when it comes out. We'll post an update about it on the blog.

So any sort of copying mechanism eg dd, rsync, etc. But probably easiest of all would be to do a TKLBAM backup of your appliance and do a clean install as you desire (no LVM if that's what you want) and restore the data in. Personally I'd test your backup before you destroy the current machine though, just in case something isn't quite right.

Out of interest why would you want to do that anyway? LVM takes a bit of getting used to but IMO it's way cool!

I run TKL vanilla under KVM (on PVE) and my (anecdotal) experience has been that it seems close to bare metal performance - OVZ performance is even better (although perhaps with VirtIO drivers KVM would be equivalent?) Win is another story though! Without VirtIO drivers disk I/O can be noticably sluggish, especially under load. I haven't noticed much difference with the networking drivers though.

I understand the desire for EC2 compatability. I think OpenStack is probably the future in that regard but i guess time will tell. OTOH via the Hub using a TKLBAM backup I can migrate from KVM/OVZ/VirtualBox/bare metal to an AWS instance very easily (the Hub supports auto restore of a backup to EC2).

Anyway, good luck with your search and let us know if you find something good! :)

Thanks for the small bites of info for a first time LVM-er.

And from what I gather, it seems that the best course of action is to reformat and specify the number of inodes.

Have a read of these links for starters (although there may be betters one, they're just what came up via google):

http://serverfault.com/questions/111857/linux-help-im-running-out-of-inodes
http://www.linuxquestions.org/questions/linux-general-1/inode-lvm-and-in...
http://www.linuxquestions.org/questions/linux-newbie-8/running-out-of-in...

Hi

My problem is a little bit different - I am out of iNodes on my turnkey LVM...

root@core /tmp# df -hi
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/mapper/turnkey-root
                        416K    416K     126  100% /
tmpfs                    63K       4     63K    1% /lib/init/rw
udev                     62K     514     62K    1% /dev
tmpfs                    63K       1     63K    1% /dev/shm
/dev/sda1               122K     207    122K    1% /boot
/dev/sda6               755K      18    755K    1% /storage

What is my best cours of action ?

Any pointer appreciated

But it is not supportted OOTB so you'd need to configure this manually on each guest (although perhaps you could script it to somewhat automate the process).

My suggestion would be to have a look at ProxmoxVE. It allows the configuring of users and groups which each can have certain levels of control/access on a per vm, or per host/node basis. It also allows TKL (and other Linux distros) to run under OVZ (which gives you 97-99% performance of bare metal) or KVM (which supports Windows and other OS).

That's a whole other issue then. My advice to start with would be to take an image of the drive before doing anything. Ideally I like to image to a same or larger size drive. dd is the go, or ddrescue if there are hardware or data corruption issues.

Otherwise I'm not much help. I had a HDD fail on me some time ago and I managed to recover some of the data (about a quarter) by writing a new super block, but I don't recall how I did it... Sorry...

But why not just mount your LV and then copy out the files?

Something like this should work:

mount /dev/c/c /mnt

Then all your files should be somewhere in /mnt (I have no idea what subfolder - it depends on where ReadyNAS stores stuff).

But I'm sure if you search on google you'll find plenty of info. Keep in mind that TKL v12.x is based on Debian Squeeze and I'm sure you'll find something. Hint: I think you are after user quotas using LVM

But I've never done it... I think mdam is the one to use for software RAID.

The only thing is that I'm not sure if LVM would really be relevant then... AFAIK the way that quotas work is that they use separate partitions...

I need to grow my storage space. I've usually started with something like VBoxManage.exe modifyhd linuxturnkeylamp.vdi --resize 30000, followed by lots of steps from various tutorials. I've tried resizing things with GParted, and have screenshot below after too many changes. I've tried cfdisk, but none of these instructions include which settings/options to select and I get errors surrounding partioning tables not setup or invalid settings. I've tried pvcreate but get a different error or overwrite warning per sda#. I've tried creating a new VHD using VirtualBox but still none of them show up afterwards for extending, using pvdisplay --maps or vgdisplay. You might realize from these tries I'm pretty notice in this area, but am starting to believe it's not just me. Anyone have some ideas or better directions on these commands? If can elaborate of any errors but not even sure which direction to go at this point.

Linux linuxturnkeylamp 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u2 x86_64
Welcome to Linuxturnkeylamp, TurnKey Linux 13.0 / Debian 7.2 Wheezy
System load: 0.08 Memory usage: 4%
Processes: 83 Swap usage: 0%
Usage of /: 99.8% of 5.89GB IP address for eth0: 10.0.2.15
IP address for eth1: 192.168.100.200
IP address for eth2: 192.168.56.100
TKLBAM (Backup and Migration): NOT INITIALIZED

root@linuxturnkeylamp ~# pvdisplay --maps
--- Physical volume ---
PV Name /dev/sda5
VG Name turnkey
PV Size 45.25 GiB / not usable 2.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 11583
Free PE 9797
Allocated PE 1786
PV UUID g0UVfV-Z30e-8hln-HUtz-F3kw-YXMt-Rm2Hre

--- Physical Segments ---
Physical extent 0 to 1530: Logical volume /dev/turnkey/root
Logical extents 0 to 1530
Physical extent 1531 to 1785: Logical volume /dev/turnkey/swap_1
Logical extents 0 to 254
Physical extent 1786 to 11582:    FREE

root@linuxturnkeylamp ~# vgdisplay

--- Volume group ---
VG Name turnkey
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 5
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 45.25 GiB
PE Size 4.00 MiB
Total PE 11583
Alloc PE / Size 1786 / 6.98 GiB
Free PE / Size 9797 / 38.27 GiB
VG UUID cnjfUb-Zp0u-Ns5Z-xchm-9J07-MCvT-IclgSf

this is a screenshot of slightly earlier states of my debugging

Anyway, as a general rule, we highly recommend using TKLBAM for backups. WOrst case you could have then restored the data to a new VM (with a bigger root volume) off the bat. Obviously a snapshot would also work. And all of that is moot now anyway...

FWIW log files are usually only pretty small so unlikely cleaning up them will give you enough room. Probably the best way to clear a bit of space is removing the apt cache:

apt-get clean

Although obviously how much room that will give you will depend on how much stuff is there (and when/if you've ever run it before).

One really handy tool to see what is taking up all your space (and give you ideas for removal candidates) is ncdu. It's not that big, but obviously it's preferable to install it before lack of space becomes an issue... Install that like this:

apt-get update && apt-get install ncdu

ncdu /

As a general rule, keeping a regular eye on your free space before it becomes a problem is highly recommended. Again probably not much use to you this time, but hopefully might help save headaches next time!? :)

Do you have a backup you can restore from?

I've just had a closer look at my home server because I was sure that I had a VG larger than 2TB. It's not TurnKey, but it is Debian Jessie based (same as TurnKey) so I was hoping it should be the same. Unfortunately, it seems that the version of LVM I have is a little newer, so YMMV.

root@tkl-14-2 ~# lvm version
  LVM version:     2.02.111(2) (2014-09-01)
  Library version: 1.02.90 (2014-09-01)
  Driver version:  4.27.0

root@pve ~# lvm version
  LVM version:     2.02.116(2) (2015-01-30)
  Library version: 1.02.93 (2015-01-30)
  Driver version:  4.34.0

root@pve ~# vgdisplay pve3
  --- Volume group ---
  VG Name               pve3
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               2.73 TiB
  PE Size               4.00 MiB
  Total PE              715396
  Alloc PE / Size       707789 / 2.70 TiB
  Free  PE / Size       7607 / 29.71 GiB
  VG UUID               eMT1kU-T5ZC-9HzC-QgpG-5Mmb-tqOj-ZK7ESO

root@pve ~# pvdisplay /dev/sdb
  --- Physical volume ---
  PV Name               /dev/sdb
  VG Name               pve3
  PV Size               2.73 TiB / not usable 4.46 MiB
  Allocatable           yes
  PE Size               4.00 MiB
  Total PE              715396
  Free PE               7607
  Allocated PE          707789
  PV UUID               hAv4dj-yTXL-Cikh-lgpr-EcUs-DDbb-ZaU20r

root@pve ~# fdisk -l /dev/sdb

Disk /dev/sdb: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

If that still doesn't work, perhaps one more thing worth trying is to create individual partitions smaller than 2TB and add them all to the same VG. TBH, I'm not sure it will work, but hopefully...

It sounds like you are doing all the right things. A quick google, bought up a similar issue to your on SE: How to create a LVM Partition/physical volume > 2TB.

If this is a VM, then I suggest that you follow the recommendations of the top answer and add a new vHDD with the size that you want. Then, as per the answer, don't partition it at all, just add the whole disk as a PV as is.

If this is a physical hard drive, then rather than adding a new partition, why not try just increasing the size of the existing partition (rather than adding a new one)?

Either way, I urge you to make sure that you have a current working (i.e. tested) backup of your important data before you start. Worst case scenario, you can roll back to where you are now.

If you installed TurnKey from ISO, then LVM is optional. IIRC the default option in v14.0 was no LVM. I don't recall if it was v14.1 or v14.2 when we changed it to be the default.

Hi Jeremy,
Thanks again for your help. Here is the output:

root@lamp ~# resize2fs
/dev/turnkey/root resize2fs 1.43.4 (31-Jan-2017) The filesystem is already 25144320 (4k) blocks long. Nothing to do!

root@lamp ~# df -h
Filesystem                Size  Used Avail Use% Mounted on
udev                      4.9G     0  4.9G   0% /dev
tmpfs                    1001M   13M  988M   2% /run
/dev/mapper/turnkey-root   95G   12G   79G  14% /
tmpfs                     4.9G     0  4.9G   0% /dev/shm
tmpfs                     5.0M     0  5.0M   0% /run/lock
tmpfs                     4.9G     0  4.9G   0% /sys/fs/cgroup

root@lamp ~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=5109612k,nr_inodes=1277403,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1024312k,mode=755)
/dev/mapper/turnkey-root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=42,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=9804)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)

root@lamp ~# cat /etc/fstab
/dev/mapper/turnkey-root        /       ext4    errors=remount-ro       0       1
/dev/mapper/turnkey-swap_1      none    swap    sw      0       0

root@lamp ~# pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda1
  VG Name               turnkey
  PV Size               18.57 GiB / not usable 608.50 KiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              4753
  Free PE               0
  Allocated PE          4753
  PV UUID               EHxRup-p9EQ-hXeO-Sd6g-suT5-uLwG-QT4p1z

  --- Physical volume ---
  PV Name               /dev/sda2
  VG Name               turnkey
  PV Size               77.85 GiB / not usable 1.52 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              19930
  Free PE               0
  Allocated PE          19930
  PV UUID               k44hv7-TtkM-yPND-eRR7-enZN-7PVE-Xi92Xl

root@lamp ~# vgdisplay
  --- Volume group ---
  VG Name               turnkey
  System ID
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  12
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               96.42 GiB
  PE Size               4.00 MiB
  Total PE              24683
  Alloc PE / Size       24683 / 96.42 GiB
  Free  PE / Size       0 / 0
  VG UUID               i36ljm-rI3j-LNIe-eYPs-AYEb-w8ca-ddtCyN

root@lamp ~# lvdisplay
  --- Logical volume ---
  LV Path                /dev/turnkey/root
  LV Name                root
  VG Name                turnkey
  LV UUID                Hzcyyq-iTnJ-Y6Fl-igdZ-bO3a-vg1n-KKLj64
  LV Write Access        read/write
  LV Creation host, time tkldev, 2018-11-28 19:39:19 +0000
  LV Status              available
  # open                 1
  LV Size                95.92 GiB
  Current LE             24555
  Segments               3
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:0

  --- Logical volume ---
  LV Path                /dev/turnkey/swap_1
  LV Name                swap_1
  VG Name                turnkey
  LV UUID                RmerUk-Kt62-eZ2M-6t5L-Gfik-vllg-K32ueP
  LV Write Access        read/write
  LV Creation host, time tkldev, 2018-11-28 19:39:19 +0000
  LV Status              available
  # open                 2
  LV Size                512.00 MiB
  Current LE             128
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:1

root@lamp ~# growpart /dev/sda 1
NOCHANGE: partition 1 could only be grown by 1051 [fudge=2048]

Looking at what you posted, it appears that everything is as it should be?! You appear to have a VG that consists of PVs /dev/sda1 & /dev/sda2 (total of 95.9G). Your root LVM (turnkey-root) appears to have 95.92G so you should be all good.

If you're still not seeing the full ~95GB within your root filesystem, my guess is that you haven't run the final command to extend the filesystem:

resize2fs /dev/turnkey/root

If you have definitely done all that and still not seeing the full free space, please run the following commands and copy/paste the output:

df -h
mount
cat /etc/fstab
pvdisplay
vgdisplay
lvdisplay

Hello,

I tried to follow the instructions in attempt to resize root from 18GB to entire free space (100GB SSD) and it seems that I managed to resize the VG:

root@lamp ~# vgdisplay
  --- Volume group ---
  VG Name               turnkey
  System ID
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  12
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               96.42 GiB
  PE Size               4.00 MiB
  Total PE              24683
  Alloc PE / Size       24683 / 96.42 GiB
  Free  PE / Size       0 / 0
  VG UUID               i36ljm-rI3j-LNIe-eYPs-AYEb-w8ca-ddtCyN

Also Logical volumes:

root@lamp ~# lvs
  LV     VG      Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root   turnkey -wi-ao----  95.92g                                             
  swap_1 turnkey -wi-ao---- 512.00m

But I guess that I stuck with Physical volumes:

root@lamp ~# lsblk
NAME               MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
fd0                  2:0    1    4K  0 disk
sda                  8:0    0 96.5G  0 disk
|-sda1               8:1    0 18.6G  0 part
| |-turnkey-root   254:0    0 95.9G  0 lvm  /
| `-turnkey-swap_1 254:1    0  512M  0 lvm  [SWAP]
`-sda2               8:2    0 77.9G  0 part
  `-turnkey-root   254:0    0 95.9G  0 lvm  /
sr0                 11:0    1 1024M  0 rom

And now I don't know what to do. I want TKL to use the entire 100GB SSD. Shall I merge sda1 and sda2 and how?

Many thanks!                                            

Glad to hear that you got there in the end. Although FWIW, it was already working when you posted your previous post above:

root@lamp ~# df -h
Filesystem                Size  Used Avail Use% Mounted on
[...]
/dev/mapper/turnkey-root   95G   12G   79G  14% /
[...]

I.e. 95GB total size of your '/' filesystem (i.e. /dev/mapper/turnkey-root), 79GB available (i.e. free space). :)

Damn, I don't know how but somehow after 2nd restart it came up with the real size.

Thanks for looking anyway!