Category: Tech Notes

Posted on

Expanding the disk size for an Ubuntu guest on VMware ESXi

Stop the guest VM.

Change the attached disk size in VM settings:

Attach a gparted iso or alternatively you can attach the original Ubuntu desktop ISO that you originally installed from.

Change the Boot Option for your VM to boot into the guest VM’s BIOS (‘Force BIOS setup’) to change the boot order with the cdrom first (by default it won’t boot from the attached cdrom as it’s set to only boot from cdrom if the attached disk does not boot first):

With the gparted iso or Ubuntu desktop install iso attached, restart the VM, and then run gparted.

Use gparted to expand the partition into the free space.

Once resized, reboot the Unbuntu guest (reset the boot order or unattach the cdrom iso image).

Use pvdisplay to get the Volume Group name

$ sudo pvdisplay

  --- Physical volume ---

  PV Name               /dev/sda5

  VG Name               ubuntu-vg

  PV Size               39.76 GiB / not usable 2.00 MiB

  Allocatable           yes (but full)

  PE Size               4.00 MiB

  Total PE              10178

  Free PE               0

  Allocated PE          10178

Use vgextend with the volume group name and physical disk name to extend:

sudo vgextend ubuntu-vg /dev/sda5

Use lvextend with param “-l+100%FREE” to expand the logical volume:

sudo lvextend -l+100%FREE /dev/ubuntu-vg/root

Now use resize2fs:

sudo resize2fs /dev/mapper/ubuntu--vg-root

Done!

More info on using gparted here. Info on resizing LVM disks in this article here.

Posted on

GitLab not restarting, postresql service not running

After restarting my GitLab server I kept getting the 502 “GitLab is taking too much time to respond” error.

Taking a look at the running services, I get this:

$ sudo gitlab-ctl status

run: gitaly: (pid 1048) 382s; run: log: (pid 1046) 382s

run: gitlab-monitor: (pid 1035) 382s; run: log: (pid 1033) 382s

run: gitlab-workhorse: (pid 1047) 382s; run: log: (pid 1045) 382s

run: logrotate: (pid 1029) 382s; run: log: (pid 1028) 382s

run: nginx: (pid 3900) 15s; run: log: (pid 1026) 382s

run: node-exporter: (pid 1031) 382s; run: log: (pid 1030) 382s

run: postgres-exporter: (pid 1039) 382s; run: log: (pid 1038) 382s

down: postgresql: 0s, normally up, want up; run: log: (pid 1041) 382s

run: prometheus: (pid 3919) 15s; run: log: (pid 1032) 382s

run: redis: (pid 1053) 382s; run: log: (pid 1050) 382s

run: redis-exporter: (pid 1037) 382s; run: log: (pid 1036) 382s

run: sidekiq: (pid 3931) 14s; run: log: (pid 1049) 382s

run: unicorn: (pid 3937) 14s; run: log: (pid 1044) 382s

Everything is up apart from Postgresql. Trying to stop all services and restart, or rebooting the sever still gets the same error. Checking GitLab’s postgresql logs, they show:

2018-03-13_04:04:45.73226 FATAL:  pre-existing shared memory block (key 5432001, ID 0) is still in use

2018-03-13_04:04:45.73232 HINT:  If you're sure there are no old server processes still running, remove the shared memory block or just delete the file "postmaster.pid".

Doing a quick search found this identical question. Following the steps in the first answer:

sudo gitlab-ctl stop
sudo systemctl stop gitlab-runsvdir.service
ps aux | grep postgre (check if there are any postgres processes; shouldn't be)
sudo rm /var/opt/gitlab/postgresql/data/postmaster.pid
sudo systemctl start gitlab-runsvdir.service
sudo gitlab-ctl reconfigure

And then ‘sudo gitlab-ctl start’ and now everything is back up and clean.

Posted on

Burning ISOs to disk on MacOS El Cap and later

Prior to El Cap, the Disk Utility on MacOS had an icon to burn an ISO to disk when you mounted the iso. For whatever reason this was removed in El Cap and after, but the ability to burn isos has always bee provided from the Finder.

Right-click an iso file in the Finder and you’ll see a burn option. More info in this article here.

Posted on

kubernetes : kubectl useful commands

Working through the interactive tutorial here is a good reference for kubectl usage.

A few notes for reference:

Copy master node config to a remote machine (from here):

scp root@<master ip>:/etc/kubernetes/admin.conf .

All of the commands if running on a remote machine can use the copied conf file by passing: --kubeconfig ./admin.conf

Query nodes in the cluster:

kubectl get nodes



Show current cluster info:


./kubectl cluster-info

Kubernetes master is running at https://192.168.1.80:6443

KubeDNS is running at https://192.168.1.80:6443/api/v1/namespaces/kube-system/services/kube-dns/proxy


From the interactive tutorial:


Run kubernetes-bootcamp:


kubectl run kubernetes-bootcamp --image=docker.io/jocatalin/kubernetes-bootcamp:v1 --port=8080


Pods:


kubectl get pods
kubectl describe pod podname
kubectl delete pod podname


Deployments:


kubectl get deployments
kubectl describe deployment deploymentname
kubectl delete deployment deploymentname


Get logs


kubectl logs podname

	


	



	
		

	

	





		


		

			

				

	

	

		
		Proudly powered by WordPress