Dev Mac Tech

MAMP Pro – Oops, something is badly wrong!

Out of the blue, MAMP Pro started presenting me with an alert when I tried opening the app:

Oops, something is badly wrong!
Either you did not provide the necessary admin credentials or the MAMP PRO package could not be initialized correctly. You can either restart the application and try again or re-install the software.

I contacted support, they advised me to uninstall/reinstall and that didn’t help. The alert kept on being the only thing I saw when I tried to start the app and then it would just close.

After doing some digging around the web, I ended up here and the following command fixed it:

sudo launchctl load -w /Library/LaunchDaemons/de.appsolute.mampprohelper.plist

I suspect this might have been caused because I manually disabled MAMP Pro helper Launch Agent on macOS. Still not sure why MAMP Pro needs that running to start the app but it looks like it does.

BTW: the databases and settings for MAMP Pro are not in /Applications/MAMP but in /Library/Application Support/appsolute/MAMP PRO/

OpenStack OVH Tech

Transmit OVH OpenStack Swift v3 Configuration

Steps to configure OVH OpenStack Swift v3 on Transmit:

  • Click the + to add a New Server
  • Choose OpenStack Swift

Remote Path: v3

Obviously replace TENANT_NAME, USER and USER_PASSWORD with your values.

OpenStack OVH Tech

CyberDuck OVH OpenStack Swift v3 Configuration

OVH disabled Keystone (OpenStack Identity Service) API v2.0 and requires all endpoints to now use v3.

Currently, the instructions to setup CyberDuck with OVH are not correct. They mention the Tenant_ID:Access_Key should be filled with Project_ID:Horizon_User_ID.

Currently CyberDuck requires Project:Domain:Username and in the case of OVH should be TENANT_NAME:default:USER

Steps to set it up on CyberDuck:

  • click the + to Add a New Bookmark
  • from the dropdown pick OpenStack Swift (Keystone 3)


Server –
Project:Domain:Username – TENANT_NAME:default:USER
Path (under More Options): v3.0

Obviously replace TENANT_NAME, USER and USER_PASSWORD with your values.

Note: ‘default’ is the default domain and if not changed it should work.

Debian Sysadmin Tech

Software RAID1 On Running Debian Stretch LVM + GRUB2

I needed to setup a software RAID1 on a Debian Stretch server where I had no KVM access, so I had to make do with just SSH and rescue access.

I was following this tutorial for How To Set Up Software RAID1 On A Running LVM System (Incl. GRUB2 Configuration) (Debian Squeeze) but ran into some problems. Not sure if it was the version of Debian being different or something else from the hosting pre-installed Debian.

saving /etc/mtab edit

When attempting to save the edit to /etc/mtab I was getting the error:

error writing /etc/mtab invalid argument

So, I ended up using sed:

sed -e "s/dev\/sda1/dev\/md0/" -i /etc/mtab

Doing a cat /etc/mtab showed the correct change but I doubt this made much of a difference and could probably have skipped this step. Not sure but it didn’t hurt.

creating /etc/grub.d/09_swraid1_setup

I added a few lines from /boot/grub/grub.cfg menuentry stanzas in the ### BEGIN /etc/grub.d/10_linux ### that looked to me were missing from the provided menuentry example.

Again, not sure if it made a difference but it worked.

pvmove Insufficient free space

When attempting to do the step:

pvmove -i 2 /dev/sda5 /dev/md1

I was getting the error:

Insufficient free space: X extents needed, but only Y available

As I ended up partially breaking the filesystem a couple of time, trying to solve this, I ended up just requesting a clean install and restarting the tutorial after the step:

sfdisk -d /dev/sda | sfdisk --force /dev/sdb

Booting into live rescue and following How to Shrink an LVM Volume Safely.

The idea on my case was to make ‘/dev/YOUR-VOLUME-GROUP/root’ 1GB smaller.

As my drive had Tb, I had to use the following to determine the GB:

pvs --units g

After that I rebooted back into the system and continued the tutorial and the pvmove problem was gone.

Other issues from live rescue on this particular hosting service:

The version of e2fsprogs and resize2fs was old and I was getting the error “has unsupported feature(s): metadata_csum” or “Filesystem has unsupported read-only feature(s) while trying to open”

I had to upgrade to ‘e2fsprogs-1.43.1’

When attempting to do:


The server in live rescue wasn’t able to resolve DNS, so I had to use curl to hack something:

curl -o e2fsprogs-1.43.1.tar.gz

This showed me one of the download server domains from SourceForge and I pinged that domain to get the IP and used –resolve to be able to reach it, like this:

curl -o e2fsprogs-1.43.1.tar.gz --resolve --resolve

After that I was able to install it:

tar xzf e2fsprogs-1.43.1.tar.gz
cd e2fsprogs-1.43.1
make install

And had to use ./e2fsprogs/e2fsprogs and ./resize/resize2fs as my commands.

Issues that I ignored

  • the ‘mount’ command was still displaying /dev/sda1 before the reboot
  • ‘update-grub’ was returning a few ‘grub-install: warning: Couldn’t find physical volume `(null)’.’ errors
  • the final ‘update-initramfs -u’ required me to do ‘update-initramfs -t -u’

Intel Mac Tech

Mac Mini 2018 graphics Intel UHD 630 and 4K Monitor

The Mac Mini 2018 comes with Intel UHD 630 graphics without a possibility to upgrade unless you use an external eGPU.

I was a bit worried about how it would perform with a 4K monitor scaled at 2560×1440. I use 27 inches 4K monitors and they need to be scaled to 2560×1440 as MacOS default resolution from a 4K monitor (3840×2160) is 1920×1080 and that is way too big for 27 inches.

The problem with scaled resolutions in MacOS is that they degrade performance, as internally the resolution needs to double and then be shrunk down. In my case 2560×1440 is in fact 5120×2880 (5K). As the warning mentions when you scale in System Preferences->Monitors “Using a scaled resolution may affect performance”.

I bought the base configuration Mac Mini in 2020, the 2018 Mac Mini in 2020 comes with 256GB SSD PCIe and the same Intel Quad-Core i3-8100 (graphics UHD 630) and 8GB of RAM.

My plan was to upgrade the RAM myself and save some money and I did to 16GB.

When I initially tried the Mac Mini with 8GB of RAM and scaled resolution there was some noticeable slowness (visual lag and stuttering) in the UI, most noticeable to me when scrolling and on entering/exiting Mission Control. I was getting a bit frustrated/worried but the strange thing is that the graphics history in Activity Monitor didn’t report large spikes in usage during those actions.

After upgrading to 16GB of RAM it felt much smoother. Probably not as smooth as running default scale but for me it has been working fine.