Tag debian

Latest posts for tag debian

2017-06-15 09:37:59+02:00

5 years of Debian Diversity Statement

The Debian Project welcomes and encourages participation by everyone.

No matter how you identify yourself or how others perceive you: we welcome you. We welcome contributions from everyone as long as they interact constructively with our community.

While much of the work for our project is technical in nature, we value and encourage contributions from those with expertise in other areas, and welcome them into our community.

The Debian Diversity Statement has recently turned 5 years old, and I still find it the best diversity statement I know of, one of the most welcoming texts I've seen, and the result of one of the best project-wide mailing list discussions I can remember.

debian eng pdo
2017-05-31 21:00:00+02:00

Today I Learnt

Build a system that can install GRUB2 on UEFI and on legacy systems

grub-efi-amd64 and grub-pc are not coinstallable. It turns out however that they do not contain GRUB, but the machinery to keep GRUB configuration up to date on the current system. If I want to be able to install GRUB on other systems, I can use the -bin packages:

apt install grub-common grub2-common grub-efi-amd64-bin grub-pc-bin

That gave me a grub-install command that worked on both kinds of systems.

GRUB configuration on a UEFI system

An old GRUB configuration on a UEFI system gave me this:

error: no suitable mode found
Booting blind

which boots on a blank screen until the kernel reinitialises the video hardware.

The Arch Linux Wiki has excellent documentation for this case, and here's the resulting UEFI GRUB snippet:

insmod efi_gop
insmod efi_uga
insmod font
if loadfont ${prefix}/fonts/unicode.pf2
then
    insmod gfxterm
    set gfxmode=auto
    set gfxpayload=keep
    terminal_output gfxterm
fi

# Follow with the usual GRUB menu entries…

Use an unsigned local APT repository for testing/development purposes

I found out today that one can have options in square brackets in sources.list:

# In /etc/apt/sources.list.d/local-devel.list
deb [trusted=yes] http://localhost:1234/debian jessie main

pabs on IRC also mentioned local-apt-repository but I haven't tried it.

Booting Jessie Debian Live with a kernel from jessie-backports

This requires working around #844749 and 844749.

In hooks/9000-fix-bugs.chroot I ended up having this:

# Workaround per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844749
if ! grep -q ^nls_ascii /etc/initramfs-tools/modules
then
        echo "nls_ascii" >> /etc/initramfs-tools/modules
fi

# Workaround per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844749
if ! grep -q ^overlay /etc/initramfs-tools/modules
then
        echo "overlay" >> /etc/initramfs-tools/modules
fi

Using a custom kernel in Jessie Debian Live

How do I have live-build pick a custom kernel package instead of the default one?

  1. lb config --linux-packages linux-image-$SOMETHING
  2. Use equivs to build a linux-image-$SOMETHING-$ARCH package that depends on the kernel that you built.
debian eng pdo
2017-05-31 20:29:08+02:00

Debian Jessie Live on UEFI part 2

A refinement on my previous attempt.

This is how to configure a Jessie live-build environment to boot on UEFI systems, and get a USB key image that works:

# Build a FAT image instead of an ISO image...
lb config -b hdd

# ...and work around #773833
echo "/usr/lib/syslinux/mbr/*.bin /usr/lib/syslinux/" > hooks/9000-fix-773833.chroot

# Get EFI Shell from https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/
curl -o binary/efi/boot/Bootx64.efi https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi

# Configure the EFI shell to boot the live setup
echo 'live\vmlinuz initrd=live\initrd.img append boot=live components' > binary/startup.nsh

Rationale: UEFI understants FAT filesystems, and would run EFI binaries placed under efi/boot.

For a hard drive, it only considers a FAT filesystem on a GPT partition marked with a special UUID, so that it doesn't get confused with other FAT filesystems that are on disk.

For a USB key, it seems that most hardware will happily look for efi/boot even if the partition table is the old MBR kind.

live-build can build a FAT image for USB keys, losing the ability to boot on CDROMs and DVDs. Since I don't need that ability, I can use -b hdd to get the live system packaged inside a container that UEFI hardware can understand (FAT).

At that point, enabling UEFI boot on a Live Debian Jessie is just a matter of adding an efi/boot/Bootx64.efi binary that is able to load the kernel and initrd in memory, and blow life into them.

debian eng pdo sw
2017-05-29 20:36:40+02:00

Egg-walking with qemu-nbd and kpartx

I wanted to retrieve a file from a VirtualBox VDI image for this blog post.

I followed these instructions and ended up here:

Once having used nbd0, only rebooting the system makes it possible to mount another image ... a little bit unpractical.

What happened was this:

# modprobe nbd  # NOO! Don't *EVER* do that!
# qemu-nbd -c /dev/nbd0 file.vdi
# kpartx -d /dev/nbd0
# mount /dev/nbd0… EHI! Where's /dev/nbdpp1 ??
# qemu-nbd -d /dev/nbd0
# rmmod nbd
rmmod: ERROR: Module nbd is in use
# kpartx -d /dev/nbd0
read error, sector 0
llseek error
llseek error
llseek error
# rmmod nbd
rmmod: ERROR: Module nbd is in use
# WHAT THE…

It turns out it's really modprobe nbd max_part=16, otherwise max_part defaults to, uhm, zero? really? and kpartx cannot create device mappings because there are not enough (as in, not even a single one) partition devices available.

At this point, however, kpartx did create some mappings connected to, uhm, probably Ancient Beings from beyond spacetime, and because of those the device is in use and cannot be removed, and unmapping doesn't work either because the Ancient Beings from beyond spacetime are keeping the device busy by feeding on it.

I energized the pentacle and tried a desperate ritual of banishment:

# # Reconnect nbd0 to the vdi file to Restore the Balance
# qemu-nbd --verbose -c /dev/nbd0 file.vdi
# # This works now
# kpartx -vd /dev/nbd0
del devmap : nbd0p5
del devmap : nbd0p2
del devmap : nbd0p1
# # This too, the Ancient Beings lie asleep yet again
# modprobe nbd -r

At this point I managed to get my file, almost:

# modprobe nbd max_part=16
# qemu-nbd --verbose -c /dev/nbd0 file.vdi
NBD device /dev/nbd0 is now connected to file.vdi
# kpartx -va /dev/nbd0
add map nbd0p1 (254:12): 0 60260352 linear 43:0 2048
add map nbd0p2 (254:13): 0 2 linear 43:0 60264446
add map nbd0p5 (254:14): 0 2648064 linear 43:0 60264448
# mount /dev/nbd0p1 /mnt
mount: /dev/nbd0p1 is already mounted or /mnt busy
# # WHAT NOW?!
# lsblk
NAME                                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
…
nbd0                                        43:0    0    30G  0 disk
├─nbd0p1                                    43:1    0  28.8G  0 part
├─nbd0p2                                    43:2    0     1K  0 part
├─nbd0p5                                    43:5    0   1.3G  0 part
├─nbd0p1                                   254:12   0  28.8G  0 part
├─nbd0p2                                   254:13   0     1K  0 part
└─nbd0p5                                   254:14   0   1.3G  0 part
# # WHAAAT?!!
# kpartx -vd /dev/nbd0
del devmap : nbd0p5
del devmap : nbd0p2
del devmap : nbd0p1
# lsblk
NAME                                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
…
nbd0                                        43:0    0    30G  0 disk
├─nbd0p1                                    43:1    0  28.8G  0 part
├─nbd0p2                                    43:2    0     1K  0 part
└─nbd0p5                                    43:5    0   1.3G  0 part
# mount /dev/nbd0p1 /mnt
# # I got my file, my preciouss file!
# umount /mnt
# kpartx -vd /dev/nbd0
# qemu-nbd -d /dev/nbd0
# rmmod nbd
# # sit in a corner hugging my precious file and sobbing quietly

As can be seen from the multiple exclamation marks, those Ancient Beings from beyond spacetime did manage to have a bite on my sanity after all.

debian eng pdo sw
2017-05-29 20:12:46+02:00

Jessie live on UEFI systems

According to the Debian Wiki, you can't boot a Debian Live based on Jessie on a UEFI system:

UEFI support in live images At this point, UEFI support exists only in Debian's installation images. The accompanying live images do not have support for UEFI boot, as the live-build software used to generate them still does not include it. Hopefully the debian-live developers will add this important feature soon.

Some people really needed it, though, so I kept looking.

Here's a script that takes a Jessie Debian Live .iso file and the device name for a USB pendrive, and gives you a pendrive that boots on UEFI:

#!/bin/sh
# License: do what you want but it's not my fault, I told you not to.

sh -ue

ISO=${1:?"Usage: $0 file.iso usbdev"}
DEV=${2:?"Usage: $0 file.iso usbdev"}

parted -s $DEV mklabel gpt mkpart primary fat32 1 100%
mkfs.vfat ${DEV}1
mount ${DEV}1 /mnt

bsdtar -C /mnt -xf $ISO

mkdir -p /mnt/efi/boot
# Shell.efi comes from https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/
cp Shell.efi /mnt/efi/boot/Bootx64.efi
echo 'live\vmlinuz initrd=live\initrd.img append boot=live components' > /mnt/startup.nsh

umount /mnt

Only use it if you really need it, though: Stretch will support this out of the box, and it's coming soon.

debian eng pdo sw
2017-04-22 20:48:43+02:00

Splitting a git-annex repository

I have a git annex repo for all my media that has grown to 57866 files and git operations are getting slow, especially on external spinning hard drives, so I decided to split it into separate repositories.

This is how I did it, with some help from #git-annex. Suppose the old big repo is at ~/oldrepo:

# Create a new repo for photos only
mkdir ~/photos
cd photos
git init
git annex init laptop

# Hardlink all the annexed data from the old repo
cp -rl ~/oldrepo/.git/annex/objects .git/annex/

# Regenerate the git annex metadata
git annex fsck --fast

# Also split the repo on the usb key
cd /media/usbkey
git clone ~/photos
cd photos
git annex init usbkey
cp -rl ../oldrepo/.git/annex/objects .git/annex/
git annex fsck --fast

# Connect the annexes as remotes of each other
git remote add laptop ~/photos
cd ~/photos
git remote add usbkey /media/usbkey

At this point, I went through all repos doing standard cleanup:

# Remove unneeded hard links
git annex unused
git annex dropunused --force 1-12345

# Sync
git annex sync

To make sure nothing is missing, I used git annex find --not --in=here to see if, for example, the usbkey that should have everything could be missing some thing.

Update: Antoine Beaupré pointed me to this tip about Repositories with large number of files which I will try next time one of my repositories grows enough to hit a performance issue.

debian eng gitannex pdo sw
2017-04-09 20:54:06+02:00

Ansible config for my stereo

I bought a Raspberry Pi 2 and its case. I could not reuse the existing SD card because it wants a MicroSD.

A wise person once told me:

First you do it, then you document it, then you automate it.

I had done the first two, and now I've redone the whole setup with ansible, here: stereo.tar.xz.

Hifi with a Raspberry Pi 2 and its case

debian eng hw pdo raspi-hifi sw
2017-04-03 11:15:38+02:00

Free Software on my phone

I try to run my phone on Free Software as much as I can.

I recently switched to LineageOS. I took it as an opportunity to do a full factory wipe and reinstall, to simulate a disaster recovery.

Here's a summary of the basic software I use:

debian eng pdo phone sw
2017-04-02 00:10:00+02:00

Stereo remote control

Wouldn't it be nice if I could use the hifi remote control to control mpd?

It turns out many wishes can come true when one has a GPIO board.

A friend of mine had a pile of IR receiver components in his stash and gave me one. It is labeled "38A 1424A", and the closest matching datasheet I found is this one.

I wired the receiver with the control pin on GPIO port 24, and set up lirc by following roughly this guide.

Hifi with shutdown button and IR receiver

Enable lirc_rpi support

I had to add these lines to /boot/config.txt to enable lirc_rpi support:

dtoverlay=lirc-rpi,gpio_in_pin=24,gpio_out_pin=22
dtparam=gpio_in_pull=up

At first I had missed configuration of the internal pull up resistor, and reception worked but was very, very poor.

Then reboot.

Install and configure lirc

apt install lirc

I added these lines to /etc/lirc/hardware.conf:

DRIVER="default"
DEVICE="/dev/lirc0"
MODULES="lirc_rpi"

Stopped lircd:

systemctl stop lirc

Tested that the receiver worked:

mode2 -d /dev/lirc0

Downloaded remote control codes for my hifi and put them in /etc/lirc/lircd.conf.

Started lircd

systemctl start lirc

Tested that lirc could parse commands from my remote control:

$ irw
0000400405506035 00 CD_PAUSE RAK-SC304W
0000400405506035 01 CD_PAUSE RAK-SC304W
0000400405506035 02 CD_PAUSE RAK-SC304W
0000400405505005 00 CD_PLAY RAK-SC304W
0000400405505005 01 CD_PLAY RAK-SC304W

Interface lirc with mpd

I made this simple lirc program and saved it in ~pi/.lircrc:

begin
     prog = irexec
     button = CD_NEXT
     config = mpc next
end

begin
     prog = irexec
     button = TAPE_FWD
     config = mpc next
end

begin
     prog = irexec
     button = TAPE_REW
     config = mpc prev
end

begin
     prog = irexec
     button = CD_PREV
     config = mpc prev
end

begin
     prog = irexec
     button = TAPE_PAUSE
     config = mpc pause
end

begin
     prog = irexec
     button = CD_PAUSE
     config = mpc pause
end

begin
     prog = irexec
     button = CD_PLAY
     config = mpc toggle
end

begin
     prog = debug
     button = TAPE_PLAY_RIGHT
     config = mpc toggle
end

Then wrote a systemd unit file to start irexec and saved it as /etc/systemd/system/mpd-irexec.service:

[Unit]
Description=Control mpd via lirc remote control
After=lirc mpd

[Service]
Type=simple
ExecStart=/usr/bin/irexec
Restart=always
User=pi
WorkingDirectory=~

[Install]
WantedBy=multi-user.target

Then systemctl start mpd-irexec to start irexec, and systemctl enable mpd-irexec to start irexec at boot.

Profit!

All of this was done by me, with almost no electronics training, following online tutorials for the hardware parts.

To connect components I used a breadboard and female-male jumper leads, so I didn't have to solder, for which I have very little practice.

Now the Raspberry Pi is so much a part of my hifi component that I can even control it with the hifi remote control.

Given that I disconnected the CD and tape players, there are now at least 16 free buttons on the remote control that I can script however I like.

Raspberry Pi closeup

debian eng hw pdo raspi-hifi sw
2017-04-01 00:10:00+02:00

Shutdown button for my Raspberry Pi

My Raspberry Pi hifi component setup lacked a way to cleanly shutdown the system without ssh.

I wished the Raspberry Pi had a button so I can tell it to shutdown.

I added one to the GPIO connector.

It turns out many wishes can come true when one has a GPIO board.

This is the /usr/local/bin/stereo-gpio script that reacts to the button press and triggers a shutdown:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
#!/usr/bin/python3
# http://razzpisampler.oreilly.com/ch07.html
# http://web.archive.org/web/20160305001215/http://razzpisampler.oreilly.com/ch07.html
from RPi import GPIO
import time
import subprocess

def on_button(pin):
    print("Button pressed", pin)

GPIO.setmode(GPIO.BCM)

GPIO.setup(18, GPIO.IN, pull_up_down=GPIO.PUD_UP)

while True:
    pin = GPIO.wait_for_edge(18, GPIO.FALLING)
    if pin == 18:
        subprocess.check_call(["/bin/systemctl", "halt"])

This is the /etc/systemd/system/stereo-gpio.service systemd unit file that runs the script as a daemon:

[Unit]
Description=Stereo GPIO manager

[Service]
Type=simple
ExecStart=/usr/local/bin/stereo-gpio
Restart=always

[Install]
WantedBy=multi-user.target

Then systemctl start stereo-gpio to start the script, and systemctl enable stereo-gpio to start the script at boot.

debian eng hw pdo raspi-hifi sw