Clearing out DHCP leases on (K)Ubuntu with dhcpd on OpenBSD.

 I have a lab of iMac computers at work. Recently I have been Installing Kubuntu on them and during the setup I decided to assign them specific hostnames and IPs from DHCP rather than just let them pick up the generic numbered names that my DHCP server was handing out by default.

My DHCP server is dhcpd on OpenBSD. I configured it to reduce the generic name pool and added static assignments for all the iMac MACs.  

Unfortunately, the systems already had leases. And releasing and renewing is not as easy in Kubuntu as in MacOS. Rebooting or disconnecting and reconnecting didn't pick up the new assignments and after a bit I realized that the server had cached the old leases and was renewing them rather than handing out the new static ones I had configured.

So for reference, here is what I did:

In OpenBSD, go through the /var/db/dhcpd.leases file and clean out the ones you don't want it to remember. Then `kill -HUP` the dhcpd process.

On the Kubuntu desktop, `sudo systemctl stop NetworkManager` , `sudo rm /var/lib/NetworkManager/*.lease`, and `sudo systemctl start NetworkManager`.

 Then the client got its new assigned address lease and all was well.

Installing Kubuntu on Late-2015 iMacs

Recently I have been installing and configuring Kubuntu on several older 27" 5K Retina iMacs (17,1 Late-2015) that are no longer supported with software updates or security patches by Apple. They are beautiful systems and have no issues other than being abandoned by Apple.

 These iMacs boot with UEFI and holding the Option key when powering on will offer a choice of boot devices, including the Kubuntu installer USB I flashed from the ISO download.

 Actually booting into the Kubuntu installer was a bit of a challenge though because there is a display power management issue with the AMD graphics in these iMacs that requires passing `amdgpu.dpm=0` to the kernel as an option when booting. If you don't do it, you might *eventually* see *something* to show up, but everything will be extremely slow.

Getting that kernel option in place can be a bit tricky if you can't catch the Grub bootloader in time. One way that helped me was to install Ventoy on the USB stick and then copy the Kubuntu ISO to it. Ventoy gave me a "Boot Kubuntu via Grub2" boot option. That gave me a chance to catch Grub with the ESC key and then `e` to edit the options and put `amdgpu.dpm=0` inline with the `quiet` and `splash` options that are were already there.

Proceeding with the install should cause the installer to install grub with that kernel option in place. But if you want to double check or find any painfully slow boot/display issues later on, you can always make sure that option is set in /etc/default/grub and run update-grub to put it back in place.

Ubuntu Gnome Launcher Missing Application Icons

 Recently, my non-snap version of Element (Desktop) on Ubuntu 26.04 started behaving badly by not displaying its icon properly in the Gnome "Dash" (see Gnome Terminology).

Some searching revealed Fixing Applications Icon Missing from the Launcher in Ubuntu and that led me to a fix by editing /usr/share/applications/element-desktop.desktop to switch the StartupWMClass to element rather than Element.

Unfortunately, some time later (likely after applying updates to the element-desktop package) the behaviour reverted to the broken icon.

I took a guess that copying that /usr/share/applications/element-desktop.desktop file to my ~/.local/share/applications/ folder and fixing it there might override the broken one being installed and maintained by the package and survive future upgrades to the package.

 My first hunch was correct. It overrides and works. Time will tell if it persists. In the meantime, Element issue #33472 exists for the problem caused by a mismatched StartupWMClass.

On a related note: Element issue #34895 points to Electron issue #53215 for the broken status icon in the Gnome "Top Bar".

No DHCP IP on eth0 with Ubuntu Server 26.04 (64-bit) on Raspberry Pi 4b

This week I was attempting to get up and running with Ubuntu Server 26.04 (64-bit) on a Pi 4b using Raspberry Pi Imager 1.8.5. I noticed this same problem both times I went through this process.

I used the option to edit and apply configuration settings in the Raspberry Pi Imager

General Tab:

• Set hostname

• Set username and password

• unchecked Configure wireless LAN

• set locale settings

Services:

• Enable SSH

• Allow Public Key Authentication Only (and pasted in my public key)

Then I flashed the microSD card, booted the Pi with it, watched a lot of stuff go by and then saw that it was trying and failing to reach the Ubuntu repos to update itself. The eth0 interface link light was on and maybe also flashing activity, but the system was unreachable on the network. Logging in on the console showed no assigned IP to eth0 even though /etc/netplan/50-cloud-init.yaml contained:

network:
  version: 2
  ethernets:
    eth0:
      optional: true
      dhcp4: true

In the end, all I had to do was run sudo netplan apply from the console and it picked up its eth0 IP and other info via DHCP.

Disconnect and power off USB peripheral from the Linux command line

I have a headless Proxmox PVE node that I sometimes need to mount USB storage to. When I'm done with it I can unmount the filesystem on it easily enough with the umount command but then I still have the drive and partitions still connected to the system. (In my case, that looks something like this below with my nvme drives and partitions showing up afterwards.)

root@pm:~# lsblk
NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda                            8:0    0   1.9T  0 disk 
└─sda1                         8:1    0   1.9T  0 part

 

In a modern desktop environment on Linux you can find buttons or menu options to 'eject' storage like this but it wasn't obvious to me how to do it from the command line for a USB HDD enclosure. [edit: so the `eject` manual page suggests that running `eject /dev/sda` might have also worked. I'll try it next time!]

So I did a Kagi search and found a solution on Reddit that worked.

From https://www.reddit.com/r/linuxquestions/comments/1dq4ha3/comment/lao9dnq/

Echoing the usb port number to /sys/bus/usb/drivers/usb/unbind works for regular usb devices, like external drives or hubs. It removes them from from the bus and stops them consuming power, just as if they were physically unplugged. You need both the bus number and port, which you can get via lsusb -t. For example if the device is on bus 01 port 3, you would use

echo 1-3 | sudo tee /sys/bus/usb/drivers/usb/unbind

Echoing the same to /sys/bus/usb/drivers/usb/bind plugs it back in.

 

Upgrade self-hosted GitLab instance on Ubuntu after falling too far behind

I recently ran into a signing key issue on an Ubuntu system running gitlab-ee from the official GitLab repos but didn't notice for a while so my normal automatic upgrades hadn't been working to keep it updated. This may have also been affecting other package upgrades... not sure yet.

Anyway, the first thing to solve was getting the latest repo key installed. Downloading and running the script mentioned in step 2 of https://docs.gitlab.com/install/package/ubuntu/?tab=Enterprise+Edition did the trick for the key. 

Afterwards, I was faced with the issue of being multiple Minor revisions behind. This manifested as this error:

Stop optical discs from automatically mounting in Ubuntu 25.10

 I was recently using MakeMKV to rip some old DVDs to watch using Jellyfin/Plex and ran into an issue where the drive seemed to be in contention between GNOME and MakeMKV.

Manually unmounting the DVD in the GNOME dock and restarting MakeMKV seemed to allow it to continue so I had a quick look for how to change that desktop normally useful behaviour while I was working on this task.

 I tried installing dconf-editor but trying to change the org/gnome/desktop/automount value to false gave me a cryptic error about something not being available for editing. Same with other values in that same section. It may have been because I was trying to run it as root rather than my current desktop user or something like that, but since the advice to use that tool was from a decade ago and I'm running Ubuntu 25.10, I had another look around.

I found the gsettings command line utility.

Running gsettings set org.gnome.desktop.media-handling automount false as my logged in user took effect immediately without logging out and in again and I didn't see the MakeMKV problems again.

Afterwards, I ran gsettings set org.gnome.desktop.media-handling automount true to revert to the normally useful default automount behaviour.