[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

I managed to get Debian Live working on the Raspberry Pi3, but it takes some tweaking



Hi List,

I've been tinkering with getting Debian Live to run on the Raspberry Pi3
(and, since it has become available, on the Pi4, but that's a different
can of worms - I got it working on both, but let's stick to the Pi3 for
the scope of this post).

I took some inspiration from
<https://github.com/simonpoole1/raspbian-live-build>, which either never
fully worked or ceased to work, I don't remember the details any more.

Anyways, I did manage to create a bootable image (created on amd64, with
target platform arm64 - this uses qemu-arm-static).

For a minimal working build, this is what I came up with:

#!/bin/bash

if      [ -z "$(which lb)" ] || \
        [ -z "$(which find)" ] || \
        [ -z "$(which head)" ] || \
        [ -z "$(which sfdisk)" ] || \
        [ -z "$(which losetup)" ] || \
        [ -z "$(which qemu-arm-static)" ] || \
        [ -z "$(which sed)" ] ; then
        echo "At least one of the required tools is missing."
        exit 1
fi

# create a builddir and change into it.
mkdir -p builddir && cd builddir

# start configuring the build
lb config \
 --architectures arm64 \
 --bootstrap-qemu-arch arm64 \
 --bootstrap-qemu-static /usr/bin/qemu-arm-static \
 --firmware-binary false \
 --firmware-chroot false \
 --binary-filesystem fat32 \
 --binary-images hdd \
 --chroot-filesystem squashfs \
 --hdd-size 512 \
 --initramfs live-boot \
 --system live \
 --apt-indices none \
 --apt-secure false \
 --apt-source-archives false \
 --archive-areas 'main firmware non-free' \
 --bootappend-live "boot=live config hostname=pi username=pi" \
 --cache-stages false \
 --compression gzip \
 --distribution buster \
 --gzip-options '-9 --rsyncable' \
 --mode debian \
 --security false \

# note that these parameters don't work as intended:
# --binary-filesystem fat32
# this uses mkfs.fat32 (or whatever), but the partition type is set to
# 83 instead of b.  Which is bad.

# --bootstrap-flavour minimal
# this doesn't seem to be a valid parameter any more?

# --bootappend-live "boot=live config hostname=pi username=pi"
# this does not end up in cmdline.txt, so we need to patch it
# in manually later on

# we need to add a firmware package to make our image bootable ...
echo "raspi3-firmware" >config/package-lists/raspi.list.chroot


# the config is done, let's start the build.
lb build

# after the build, let's determine the name of our image file ...
IMAGEFILE=$(find . -name "live*img" | head -n 1)

# ... and change the partition type to reflect the file
# system actually in use for partition 1 ("b" is FAT32)
sfdisk --part-type $IMAGEFILE 1 b

# next, we need to patch two things inside the image, so
# we need to set up a loop device for it.
FREELOOP=$(losetup -f)
# note that this could become a TOCTOU issue if more than
# 1 process tries to use loop devices

# as the image is a full disk image containing a partition, we
# need to jump to the position where the first partition starts
losetup -o 1048576 $FREELOOP $IMAGEFILE

# now let's mount it
mkdir -p tempmount
mount $FREELOOP tempmount

# first, we copy the contents of the boot/firmware/ folder to the root
directory, because that is where these files are needed
cp -a chroot/boot/firmware/* tempmount

# next, we replace the "root=" parameter with the parameters needed for
# live-booting (this goes all on one line)
sed -e 's#root=/dev/mmcblk0p2 #boot=live components config toram
hostname=pi username=pi #' -i tempmount/cmdline.txt

# here comes the cleanup part
sync
umount $FREELOOP
losetup -d $FREELOOP

Now if you dd the resulting *.img file to an SD card or to USB media,
the pi will boot from it.


However, the following questions remain:

First, something seems to be wrong with "--binary-filesystem fat32"
which creates a FAT32 filesystem in a partition marked as 83 (Linux)
instead of b (FAT32).  Should I report this as a bug, or am I "holding
it wrong"?

Second, "--bootstrap-flavour minimal", which was used in the
above-mentioned git repo, doesn't seem to exist any more?  What was it
good for?  What has it been replaced with?

Third, "--bootappend-live " seems to get ignored as well.  Again, should
I report this as a bug, or am I "holding it wrong"?

Fourth, all the files needed to boot a Pi need to go into the root
directory of the first partition (which neeeds to be a FAT partition) of
the boot media.  At the moment, live-build saves them in /boot/firmware
inside the squashfs file, so even with the partition type issue fixed,
the Pi still can't boot, unless you manually extract them and copy them
into their right place.  This is pretty hairy and requires the use of
losetup plus calculating an offset to hit the partition start.
Shouldn't there be a piece of code that takes care of all that before
the image is built, similar to how syslinux, grub, etc. are configured
by live-build for intel/amd builds?  And if there isn't, where should it
be added?  Does this need to go into live-build or into the
raspi(3)-firmware package?

Kind Regards,
Stefan Baur


Reply to: