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.ma...@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 > >
