Articles tagged with Debian

  1. God object
    07 Feb 2016
    1. A year ago we had an issue using Git from TeamCity “JSchException: Algorithm negotiation fail” due to diffie-hellman-group-exchange-sha256 wasn’t supported. (see Git connection fails due to unsupported key exchange algorithm on JetBrains issue tracker)

      Today we had a similar issue with using the TeamCity plugin for RubyMine.
      Our TeamCity installation is served through a reverse proxy by an Apache web server. The only common algorithm between Java and our TLS configuration is TLS_DHE_RSA_WITH_AES_128_CBC_SHA.

      Due to Java’s JCE provider having a key size upper limit of 1024, since Java 8 it is 2048, the connection fails because we require at least 4096. In RubyMine you get the Message “Login error: Prime size must be multiple of 64, and can only range from 512 to 2048 (inclusive)”.

    2. To fix this on a Debian “Jessie” 8 system with OpenJDK 8 installed follow these steps.

      Install the Bouncy Castle Provider:

      sudo aptitude install libbcprov-java

      Link the JAR in your JRE:

      sudo ln -s /usr/share/java/bcprov.jar /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/bcprov.jar 

      Modify the configuration /etc/java-8-openjdk/security/

  2. Debian
    12 Dec 2015
    1. We recently started experimenting with Ansible for automation of multi-step software installations on our servers. Quickly, we realized that Ansible version 1.7.2, which is available through Debian Jessie’s official repositories, doesn’t include all the features we needed. Sadly, the missing recursive option for the acl module is first available in Ansible 2.0, which is not yet fully released. Official packages and Debian Testing packages were only available for Ansible version 1.9.4.

      In the end I decided to investigate how to manually build a Debian package. Here is what I found:

    2. Acquire the source repository

      At first, I cloned the official Git-repository from GitHub:

      cd /usr/local/src
      git clone --recursive

      Then I checked-out the latest 2.0.0 RC tag:

      cd ansible
      git checkout -b v2.0.0-0.7.rc2 tags/v2.0.0-0.7.rc2
      git submodule update
    3. Install build-dependencies

      The mk-build-deps command is part of the devscripts package. The debian make task requires asciidoc to be installed. You can install these like this:

      sudo aptitude install asciidoc devscripts

      To install the development packages necessary to build the Ansible package I generated a temporary package named ansible-build-deps-depends. This temporary package states dependencies on all the packages that are necessary for building the actual Ansible package.

      make DEB_DIST=jessie debian
      mk-build-deps --root-cmd sudo  --install --build-dep deb-build/jessie/ansible-2.0.0/debian/control
      sudo aptitude markauto asciidoc
    4. Build the Ansible package

      To generate the actual .deb file, I issued the following command:

      make DEB_DIST=jessie deb
    5. Install Ansible

      And afterwards I installed the freshly built Ansible .deb package like this:

      sudo gdebi deb-build/jessie/ansible_2.0.0-0.git201512071813.cc98528.headsv20007rc2\~jessie_all.deb

      In case you don’t have gdebi installed, for example if you don’t have a desktop environment running, you can use the following more noisy alternative:

      sudo dpkg -i deb-build/jessie/ansible_2.0.0-0.git201512071813.cc98528.headsv20007rc2\~jessie_all.deb
      sudo apt-get install -f
    6. Remove the build-dependencies again

      After I built the Ansible package I just removed the temporary ansible-build-deps-depends package again. APT will then automatically remove all the development dependencies that it depends upon, leaving a clean system.

      sudo aptitude purge ansible-build-deps-depends
  3. Debian
    11 Jan 2015
    1. Some time ago I acquired a BeagleBone Black, a hard-float ARM-based embedded mini PC, quite similar to the widely popular Raspberry Pi. Mainly I did this because I was disappointed in the Raspberry Pi for its need of non-free firmware to boot it up and because you had to rely on third-party maintained Linux distributions of questionable security maintenance for it to function.

      Because some people gave me the impression that you could easily install an unmodified, official Debian operating system on it, I chose to take a look at the BeagleBone Black.
      After tinkering a bit with the device, I realized that this is not true at all. There are some third-party maintained Debian-based distributions available, but at their peak of security awareness, they offer MD5 fingerprints from a non-HTTPS-accessible website for image validation. I’d rather not trust in that.

      When installing an official Debian Wheezy, the screen stays black. When using Jessie (testing) or Sid (unstable), the system seems to boot up correctly, but the USB host port malfunctions and I’m unable to attach a keyboard. Now while I was looking for a way to get the USB port to work, some people hinted to me, that it might be possible to fix this problem by changing some Linux kernel configuration parameters. Sadly I cannot say whether this actually works or not, because it seems to work only for boards of revision C and higher. My board, from the third-party producer element14 seems to be a revision B.

      Still I would like to share with the world, how I managed to cross-compile the armmp kernel in Debian Sid with a slightly altered configuration on a x86_64 Debian Jessie system.

    2. Creating a clean Sid environment for building

      First of all, I created a fresh building environment using debootstrap:

      sudo debootstrap sid sid
      sudo chroot sid /bin/bash

      Further instructions are what I did while being inside the chroot environment

      Then I added some decent package sources, and especially made sure there is a line for source packages. You might want to exchange the URL with some repository close to your location, the Debian CDN sometimes leads to strange situations in my experience.

      cat <<FILE > /etc/apt/source.list
      deb sid main
      deb-src sid main

      Then I added the foreign armhf architecture to this environment, so I could acquire packages from that:

      dpkg --add-architecture armhf
      apt-get update

      Next, I installed basic building tools and the building dependencies for the Linux kernel itself:

      apt-get install build-essential fakeroot gcc-arm-linux-gnueabihf libncurses5-dev 
      apt-get build-dep linux
    3. Configuring the Linux kernel package source

      Still within the earlier created chroot environment I then prepared to build the actual package.

      I reset the locale settings to have no dependency on actual installed locale definitions:

      export LANGUAGE=C
      export LANG=C
      export LC_ALL=C

      I then acquired the kernel source code:

      cd /tmp
      apt-get source linux
      cd linux-3.16.7-ckt2

      I configured the name prefix for the cross-compiler executable to be used:

      export CROSS_COMPILE=arm-linux-gnueabihf-

      Now in the file debian/config/armhf/config.armmp, I changed the Linux kernel configuration. In my case I just did change the following line:


      You might need completely different changes here.

    4. Building the kernel package

      Because for some reason this package expects the compiler executable to be gcc-4.8 and I couldn’t find out how to teach it otherwise, I just created a symlink to the cross-compiler:

      ln -s /usr/bin/arm-linux-gnueabihf-gcc /usr/local/bin/arm-linux-gnueabihf-gcc-4.8

      Afterwards, the build process was started by the following command:

      dpkg-buildpackage -j8 -aarmhf -B -d

      The -j flag defines the maximum amount of tasks that will be done in parallel. The optimal setting for fastest compilation should be the amount of CPU cores and/or hyper-threads you’ve got on your system.

      The -d flag ignores if some dependencies aren’t installed. In my case, the process complained about python and gcc-4.8 not being installed before, even though they actually were installed. I guess it meant python:armhf and gcc-4.8:armhf then, but installing these is not even possible on my x86_64 system, even with multiarch enabled. So in the end I decided to ignore these dependencies and the compilation went fine by the looks of it.

      Now that compilation process takes quite a while and outputs a lot of .deb and .udeb package into the /tmp directory. The actual kernel package I needed was named linux-image-3.16.0-4-armmp_3.16.7-ckt2-1_armhf.deb in my case.

    5. Creating a bootable image using the new kernel

      For this, I left the Sid chroot environment again. I guess you don’t even have to.

      Now I used the vmdebootstrap tool to create an image that can then be put onto an SD card.

      First of all I had to install the tool from the experimental repositories, because the versions in Sid and Jessie were bugged somehow. That might not be needed anymore in the future.

      So I added the experimental repository to the package management system:

      cat <<FILE > /etc/apt/sources.list.d/experimental.list
      deb experimental main contrib non-free
      deb-src experimental main contrib non-free

      And afterwards I did the installation:

      apt-get update
      apt-get -t experimental vmdebootstrap

      I created a script named that sets the bootloader up inside the image, with the following content (many thanks to Neil Williams):

      set -e
      # copy u-boot to the boot partition
      cp $rootdir/usr/lib/u-boot/am335x_boneblack/MLO $rootdir/boot/MLO
      cp $rootdir/usr/lib/u-boot/am335x_boneblack/u-boot.img $rootdir/boot/u-boot.img
      # Setup uEnv.txt
      kernelVersion=$(basename `dirname $rootdir/usr/lib/*/am335x-boneblack.dtb`)
      version=$(echo $kernelVersion | sed 's/linux-image-\(.*\)/\1/')
      # uEnv.txt for Beaglebone
      # based on
      cat >> $rootdir/boot/uEnv.txt <<EOF
      mmcroot=/dev/mmcblk0p2 ro
      mmcrootfstype=ext4 rootwait fixrtc
      loadkernel=load mmc \${mmcdev}:\${mmcpart} \${loadaddr} \${kernel_file}
      loadinitrd=load mmc \${mmcdev}:\${mmcpart} \${initrd_addr} \${initrd_file}; setenv initrd_size \${filesize}
      loadfdt=load mmc \${mmcdev}:\${mmcpart} \${fdtaddr} /dtbs/\${fdtfile}
      loadfiles=run loadkernel; run loadinitrd; run loadfdt
      mmcargs=setenv bootargs console=tty0 console=\${console} root=\${mmcroot} rootfstype=\${mmcrootfstype}
      uenvcmd=run loadfiles; run mmcargs; bootz \${loadaddr} \${initrd_addr}:\${initrd_size} \${fdtaddr}
      mkdir -p $rootdir/boot/dtbs
      cp $rootdir/usr/lib/linux-image-*-armmp/* $rootdir/boot/dtbs

      Afterwards the image was built using the following command:

      Note that you might want to change the Debian mirror here as well.

      sudo -H \
        vmdebootstrap \
        --owner `whoami` \
        --log build.log \
        --log-level debug \
        --size 2G \
        --image beaglebone-black.img \
        --verbose \
        --mirror \
        --arch armhf \
        --distribution sid \
        --bootsize 128m \
        --boottype vfat \
        --no-kernel \
        --no-extlinux \
        --foreign /usr/bin/qemu-arm-static \
        --package u-boot \
        --package linux-base \
        --package initramfs-tools \
        --custom-package [INSERT PATH TO YOUR SID CHROOT]/tmp/linux-image-3.16.0-4-armmp_3.16.7-ckt2-1_armhf.deb \
        --enable-dhcp \
        --configure-apt \
        --serial-console-command '/sbin/getty -L ttyO0 115200 vt100' \
        --customize ./

      The result is a file called beaglebone-black.img that can easily be put onto an SD card by using the dd command.

    6. After I put that image on my SD card and booted it, it didn’t solve the USB problem, maybe it isn’t working at all, or maybe it just doesn’t work on my hardware revision. At least it did boot like a regular Sid image I tried before and now I have the knowledge to conduct further experiments.

      It was a hell of a job to find out how to do it, involving tons of guides and howtos giving contradicting instructions and being outdated in different grades. In the end, what helped the most was talking to a lot of people on IRC.

      So I hope this is helpful for someone else and should you be aware of a way to actually fix the USB host problem, please send me a comment.