Skip to content

Updateds zfs pool from OpenZFS release 2.2.0 and ZFSBootMenu can not boot from pool, what now?

As mentioned here, ZFSBootMenu prior version 2.2.1 is not able to boot a zpool once updated.

It took me some time and a few tries to understand that the solution is incredible simple.

Based on the official documentation, all you have to do is to:

  • Boot from a live iso like archzfs.iso
  • Mount your EFI-Partition
  • curl -LJO https://get.zfsbootmenu.org/efi
  • cp zfsbootmenu*.EFI /efi/EFI/ZBM/vmlinuz.EFI
  • Umount your EFI-Partition
  • Reboot

I've updated the archzfs iso build script to automatically create a iso file with the latest ZFSBootMenu pre-shipped.

Create php repository and want to quickly develop and test it everywhere? Add a fanzy start_docker_container.sh shell script to it!

I have to maintain a big bunch of repositories with different languages and different language versions.

After some iterations, I came up with a simple idea by using docker for it. To ease up things for any kind of users who have to deal with this code (even qa), the last iteration is to add a "startdockercontainer.sh" script into the repository.

Following an example script for a php repository.
Given is, that the script is located in <project_root>/bin.
Given is, that the docker file exists in <project_root>/data/docker.

#!/bin/bash
####
# Starts a fitting container and creates image if needed.
#
# @todo
####
# @author stev leibelt <artodeto@bazzline.net>
# @since 2018-05-09
####

PATH_OF_THIS_SCRIPT=$(cd $(dirname "$0"); pwd)
DOCKER_IMAGE_NAME='my_php_application'
DOCKER_IMAGE_TAG='0.1.0'

if ! (docker image ls | grep -q "${DOCKER_IMAGE_NAME}\s\+${DOCKER_IMAGE_TAG}")
then
    PATH_TO_THE_DOCKER_SOURCE=$(realpath ${PATH_OF_THIS_SCRIPT}/../data/docker)
    echo ":: We have to build the docker container first."
    echo ":: Please do the following steps first."
    #this is usefull since you have to copy some ssh keys to a path
    # or configure some files.

    read -p ":: Hit <ENTER> to continue."                                                                                                                       

    docker build -t ${DOCKER_IMAGE_NAME}:${DOCKER_IMAGE_TAG} ${PATH_TO_THE_DOCKER_SOURCE}
fi

docker container run --mount type=bind,source="${PATH_OF_THIS_SCRIPT}"/..,target=/application -it ${DOCKER_IMAGE_NAME}:${DOCKER_IMAGE_TAG} /bin/ash

And thats it. If the image is not found on the host, we have to setup things and build the image. Afterwards we start the container and mount the repository code into /applicationof the container.

"amixer: Mixer attach default error: No such file or directory" when try to start blockify or blockify-ul

You want to start blockify-ui or blockify on a pulseaudio served arch linux and get the following error?

amixer: Mixer attach default error: No such file or directory
Traceback (most recent call last):
  File "/usr/bin/blockify-ui", line 11, in <module>
    load_entry_point('blockify==3.6.3', 'gui_scripts', 'blockify-ui')()
  File "/usr/lib/python3.6/site-packages/blockify/gui.py", line 972, in main
    _cli = cli.initialize(__doc__)
  File "/usr/lib/python3.6/site-packages/blockify/cli.py", line 597, in initialize
    cli = Blockify(_blocklist)
  File "/usr/lib/python3.6/site-packages/blockify/cli.py", line 63, in __init__
    self.channels = self.initialize_channels()
  File "/usr/lib/python3.6/site-packages/blockify/cli.py", line 184, in initialize_channels
    amixer_output = subprocess.check_output("amixer")
  File "/usr/lib/python3.6/subprocess.py", line 336, in check_output
    **kwargs).stdout
  File "/usr/lib/python3.6/subprocess.py", line 418, in run
    output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command 'amixer' returned non-zero exit status 1.

Try to call "amixer" first and check the output. The chance is high that it will be something like the follow:

amixer: Mixer attach default error: No such file or directory

How to fix this?

Install the following tools: * extra/pulseaudio-alsa * extra/alsa-utils * extra/alsa-plugins * extra/alsa-lib

After that, amixer should output something meaningful and blockify should work as expected.

MySQL and a known bug since 2003 about the auto_increment value

We detected a bug that is known since 2003.

The value of an auto increment column is set back to zero when you are having an empty table and restarting the MySQL DBMS. We run into this issue by using the auto increment value as a history id into a second table.

How can you work around this issue?

The easiest way is to order by id descending on the second table or to setup a "start up" shell script that calculates and sets the auto increment value.