Tag pdo

Latest posts for tag pdo

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
    insmod gfxterm
    set gfxmode=auto
    set gfxpayload=keep
    terminal_output gfxterm

# 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
        echo "nls_ascii" >> /etc/initramfs-tools/modules

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

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

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:

# 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-05-16 23:12:41+02:00

Accident on the motorway

There was an accident on the motorway, luckily noone got seriously wounded, but a truckful of sugar and a truckful of cereals completely spilled on the motorway, and took some time to clean.

19:15:23 19:45:07 20:02:37 20:11:52 20:28:43 20:32:34 20:44:03 21:27:41 21:44:20 22:10:50

eng life pdo
2017-05-02 15:45:38+02:00

Vector Discordian Pope Cards

I like Discordian Pope cards.

I wanted to print a batch, but online I could only find low-quality .jpg versions, so I took inkscape, used the low-quality as a template grayed out in a background immutable layer, and redid them properly.

Here are the results:


Discordian Pope Card, Front Discordian Pope Card, Back

I release them under the WTFPL license: you can print them, redistribute them, and modify them at will.

The fonts I used are:

Update: now available as a git repo

eng life pdo
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