Re: I managed to get Debian Live working on the Raspberry Pi3, but it takes some tweaking
For
# --bootstrap-flavour minimal
# this doesn't seem to be a valid parameter any more?
try
--debootstrap-options "--variant=minbase"
but be aware that it doesn't really seem to work anymore. I've been
playing with it lately and had iso images larger than without it.
On 13/10/2020, Stefan Baur <newsgroups.mail2@stefanbaur.de> wrote:
> 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: