guysoft / custompios

A Raspberry Pi and other ARM devices distribution builder

CustomPiOS

A Raspberry Pi and other ARM devices distribution builder. CustomPiOS opens an already existing image, modifies it and repackages the image ready to ship.

This repository contains the source script to generate a distribution out of an existing Raspbian distro image, or Armbian devices.

Donate

CustomPiOS is 100% free and open source and maintained by Guy Sheffer. If its helping your life, your organisation or makes you happy, please consider making a donation. It means I can code more and worry less about my balance. Any amount counts. Also many thanks to people contributing code.

Where to get it?

Clone this repo. Then follow instructions either to build an existing distro or create your own.

How to use it?

1. Clone this image git clone https://github.com/guysoft/CustomPiOS.git
2. Run ./src/make_custom_pi_os -g <distro folder> in the repo, distro folder should not exist and contain no spaces. This will both create a folder to build a new distro from, and also download the latest raspbian lite image. The initial distro has a module that has the name of your distro, and you can find it under <distro folder>/src/modules/<distro name> (there should be only one module in the modules folder).
3. cd to <distro folder>/src
4. Edit your <distro folder>/src/config, you can also edit the starting module, which is named as your distro at modules/<dstro name>. More on that in the Developing section.
5. Run sudo ./<distro folder>/src/build_dist to build an image. If this fails use the method described in the vagrant build section (which makes sure sfdisk and other things work right).

Features

• Modules - write one module and use it for multiple distros
• Write only the code you need for your distro - no need to maintain complicated stuff like building kernels unless its actually want to do it
• Standard modules give extra functionality out of the box
• Supports over 40 embedded devices using Armbian and Raspbian.
• Supports Raspberry Pi OS arm64 bit using the raspios_lite_arm64 variant.

Developing

Requirements

1. qemu-arm-static or gentoo qemu with static USE
2. Downloaded Raspbian image.
3. root privileges for chroot
4. Bash
5. jq
6. git
7. realpath
8. file
9. sudo (the script itself calls it, running as root without sudo won't work)
10. p7zip-full
11. Python 3.2+

Known to work building configurations

1. Using the CustomPiOS docker image
2. Linux (Ubuntu / Debian / Gentoo etc)
3. OS X - See this thread for information

Modules

See Modules entry in wiki

chroot_script

This is where the stuff you want to execute inside the distro is written.

In start_chroot_script write the main code, you can use end_chroot_script to write cleanup functions, that are run at the end of the module namespace.

Useful commands from common.sh

CustomPiOS comes with a script common.sh that has useful functions you can use inside your chroot_script. To use it you can add to your script source /common.sh.

unpack [from_filesystem] [destination] [owner] - Lets you unpack files from the filesystem folder to a given destination. [owner] lets you set which user is going to be the owner. e.g. unpack /filesystem/home/pi /home/pi pi

gitclone <MODULE_NAME>_<REPO_NAME>_REPO destination - Lets you clone a git repo, and have the settings preset in the config file. Example usage in OCTOPI module.

In chroot_script:

gitclone OCTOPI_OCTOPRINT_REPO OctoPrint

In config:

[ -n "$OCTOPI_OCTOPRINT_REPO_SHIP" ] || OCTOPI_OCTOPRINT_REPO_SHIP=https://github.com/foosel/OctoPrint.git 

Export files from image

CustomPiOS has a feature to export files created in the chroot to archives you can ship as a tar.gz archive.

To export run inside of a chroot_script: custompios_export [name of archive] [file path in chroot]

You can also use: copy_and_export [name of archive] [source] [destination]

and: copy_and_export_folder [name of archive] [folder] [destination]

The results would be saved in the workspace folder.

filesystem

Lets you add files to your distro, and save them to the repo. The files can be unpacked using the unpack command that is in common.sh.

config

This is where you can create module-specific settings. They can then be overwritten in a distro or variant. The naming convention is the module name in

Build a Distro From within Raspbian / Debian / Ubuntu / CustomPiOS Distros

See building entry in wiki

Building Distro Variants

See building entry in wiki

Building Using Docker

See Building with docker entry in wiki

Building Using Vagrant

See Building with Vagrant entry in wiki

Build using CI/CD

You can build CustomPiOS images from a continuous integration system in the cloud. For an example on how to do this on github take a look at this github actions yaml

Usage

1. If needed, override existing config settings by creating a new file src/config.local. You can override all settings found in src/config. If you need to override the path to the Raspbian image to use for building your distro, override the path to be used in BASE_ZIP_IMG, which is part of the base module. By default the most recent file matching *-raspbian.zip found in src/image will be used.
2. Run src/build as root.
3. The final image will be created at the src/workspace

Community --------

List of Distributions using CustomPiOS

• OctoPi - The ready-to-go Raspberry Pi image with OctoPrint
• FarmPi - An Ubuntu ARM 64bit Raspberry Pi image running OctoFarm
• FullPageOS - A Raspberry Pi distro to display a full page browser on boot
• Zynthian - Open Synth Platform
• ElectricSheepPi - A Raspberry Pi distribution to run Electric Sheep digital art
• AlarmPi - A Raspberry Pi distribution that turns a Raspberry Pi to an IOT telegram-controlled alarm clock
• RealtimePi - An out-of-the-box Raspebrry Pi/Raspbian distro with a realtime kernel
• RMS Pi - Raspberry Pi Distro for Winlink RMS
• V1PI - Use your Raspberry Pi to control your V1Engineering machine
• HotSpotOS - Makes a Raspberry Pi start a hotspot, if no wifi was found to connect to
• MtigOS - Distro that lets you receive, store and graph sensor information from ESP8266 chips. It uses and MTIG stack: Mosquitto, Telegraf, InfluxDB and Grafana which are all pre-configured to work together. They automatically update using Docker.
• Tilti-Pi - Distro that lets you submit BLE data for the tilt hydrometer via the tilty package and a built in dashboard
• MainsailOS - Distro that packages the Mainsail web UI, the Moonraker API, and the Klipper 3D printer firmware in an easy to package.
• UbuntuDockerPi - Distro ships with Ubuntu ARM 64bit Docker and docker-compose ready to build stuff for arm64v8/aarch64 or host whatever you like.
• FluiddPi - Distro that packages Fluidd, Moonraker, and Klipper into the ultimate 3D printer firmware package.
• My Naturewatch Camera - A Python / OpenCV camera server to stream Pi camera content to a remote client through a website.
• PiFireOS - Distro for pellet grill/smoker control, running PiFire.
• MonsterPi - An Ubuntu ARM 64bit Raspberry Pi image running FDM Monster. This 3D Print server will help you connect 200+ OctoPrints together while providing a strong, professional workflow.

Code contribution would be appreciated!

custompios's Issues

ArchLinux build issue: unmount detaches loopback

Hi,
thank you for your framework. Very interesting and charming work.

I am currently investigating the possibilities and try a "hello world" build. My host system is running ArchLinux and it seems the upstream tool behavior is different then expected: During unmount of a loopback mount, my loopback device is detached, too. As an result, the framework fails because it is not able to detach its own lo-devices.
(I stumbled on similar issues on a different project).

Where does it make sense to add a build option to ignore the detach in some cases?
The relevant function - to be enhanced- seem to be: "common.sh"

best regards Matthias

Allow to choose custom "config" file when building

Hi,
I am integrating the build process into a gitlab CI,and it is possible to define the "config" file name before calling the build_custom_os script, so I can create one config file per target I would like to build.
Thanks.

Failed to setup loop device: No such file or directory

I'm trying to generate a distro with CustomPiOS on Ubuntu 18.04 under VirtualBox. Here are the steps I'm currently taking:

1. Clone this repo
2. Use build_custom_os script to generate a distro called test
3. Add a few modules in test/src/config
4. Run docker run -v `pwd`:/distro --device /dev/loop-control -it -t guysoft/custompios:devel build whilst in test/src directory

It successfully expands the image file, changes the partition, but fails when it tries to mount the image with losetup.

losetup -f --show -o 272629760 2020-02-13-raspbian-buster-lite.img
losetup: 2020-02-13-raspbian-buster-lite.img: failed to set up loop device: No such file or directory

docker build fails at losetup

I'm building with Docker on Ubuntu. I've download the Pi lite image and used modprobe. Here's the command I'm running:

time docker run -it -v `pwd`:/distro --name mydistro_builder --device /dev/loop-control guysoft/custompios:devel /CustomPiOS/nightly_build_scripts/custompios_nightly_build

It fails as follows:

Device                                Boot Start     End Sectors  Size Id Type
2018-11-13-raspbian-stretch-lite.img1       8192   98045   89854 43.9M  c W95 FAT32 (LBA)
2018-11-13-raspbian-stretch-lite.img2      98304 4464639 4366336  2.1G 83 Linux

Command (m for help): The partition table has been altered.
Syncing disks.

++++ losetup -f --show -o 50331648 2018-11-13-raspbian-stretch-lite.img
losetup: 2018-11-13-raspbian-stretch-lite.img: failed to set up loop device: No such file or directory
+++ LODEV=
+ exit 1

Looking at common.sh around line 250, the code looks like this:

  echo "Resizing file system to $size MB..."
  start=$(sfdisk -d $image | grep "$image$partition" | awk '{print $4-0}')
  offset=$(($start*512))
  
  LODEV=$(losetup -f --show -o $offset $image)

For some reason $image doesn't contain the full name and it is needed for that to run. Here's the full build log. Thoughts?

auto-hotspot module makes ssh only work on second boot

If the auto-hotspot module is enabled, then ssh works only on second boot.
Not sure how to solve, workaround would be to boot after the first boot.
There is a distro with this at:
http://unofficialpi.org/Distros/hotspot/2018-03-13-hotspot-stretch-lite-0.1.zip
md5: fe3d24008362b1cf93755aa5169f749e

Usage

Wow, I added this to my github and the guy got mad about me using it. I see he is letting you.

Where does the image get created?

When we finally use: <distro folder>/src/build_dist where does it create the image file? As far as i can see, there are no errors right now but, after the final line of output i am not able to see the image file 😕

Compile Auto-Hotspot for OctoPi; no success so far?

Hi,

I'm trying to compile OctoPi with auto-hotspot. I know you're still working on it, but the basic functionality seems stable, and I wanted to beta test it.

I verified that the CustomPiOS has Auto-Hotspot in modules CustomPiOS/src/modules/auto-hotspot, and I modified the OctoPi>src>config as follows

export MODULES="base(raspicam, network, disable-services(octopi,auto-hotspot), password-for-sudo)"

It compiles successfully into an image. No errors. OctoPrint runs as expected.

Trouble is, I get no hotspot.

Test 1: I leave wpa-supplicant untouched so that the Pi has no internet, but no hotspots starts. I tried reboot in vain.
Test 2: Also tried connecting the Pi and verify OctoPi is working, then kill the ned, and still nothing.
Test 3: I'm on RPI 3B+. I tried to add an edimax wifi dongle (that I'm used to used with RPi2 to get wifi) and reboot. This did not help either.

---

Q: Did I do all that I needed to do?
Are there more steps in the compilation or in the setip usage department?

Q: Should the auto-hotspot work with RPi 3B+ out of the box or do I need a wifi dongle?

Thanks for any pointers!

Better build tracking in stdout

Currently strout is a total mess out bash command output, which is great for build.log, but it should really display something like>

building module

Perhaps also add debug to only print certain modules. Out, and print the last lines of build.log if the build fails.
Also alert of a module is broken.

Figure how to release versions

Hey,
So at the moment CustomPiOS is picking up momentum, and other people are using it too. And its time to start tagging releases, so people know what they built against when releasing distros.
The question is - how should versions be organized?
I could just tag when I feel like it, but would like to hear when there is any way other people would prefer?

Once this happens CustomPiOS will have a master branch with the versions tagged, and a devel branch which would be the one updating regularly.

gitclone call question

CustomPiOS/src/common.sh

Line 65 in e9d972e

repo_dir=$(echo ${REPO} | sed 's%^.*/\([^/]*\)\(\.git\)?$%\1%g')

I can’t find any other reference to “${REPO}”. Is this a bug? Should it be $1 instead of "${REPO}"

pi 4 boot config.txt

With the update to the pi 4 board there is now another board revision.
https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md

This commit https://github.com/guysoft/CustomPiOS/pull/53/commits fixed it for the previous revisions but it's now not applying the correct boot options correctly as the new boards are 03112(just got a couple new ones).
I'm currently building with all of that logic removed to see if it's still necessary in either pi 3/4. If it is still necessary I'll add to it to fix the current issue.

I'll submit a new pull with this fix if needed. I've got a couple pr's just about ready anyway.

Loop doesn't seem to be working with Ubuntu 19.04, fails at losetup

Building my own version of OctoPrint with a few plugins when the build command is issued and it appears to go all the way through building the necessary modules and ripping apart the image, only to fail rebuilding the image.

Using Ubuntu 19.04 (64-bit) in a VirtualBox VM from osboxes.org. Simply using 'terminal' and not trying to install in Docker or with Vagrant.

build.log

I am pretty sure it is a permissions issue, but can't figure out how to fix it, sorry I am a linux noob.

A couple of notes, 'realpath' is not in the current Ubuntu package repository so it cannot be installed, also 'curl' needed be added to the install list in order to download the source via the provided instructions. Also, loop is not built into the kernel and not a loadable module so 'modprobe loop' does nothing. Nor does it list loop when searching for modules with 'lsmod'.

I studied the four other issues that mention loop failing (2 closed, 2 open) and it does not appear to provide a clear understanding of what is going on.

Just to verify if my setup of OctoPrint was the culprit, I tried building AlarmPi and OctoPi and both failed at the same location.

Realpath does not exist in Debian 10

There is no Buster version of realpath, https://packages.debian.org/search?keywords=realpath. It is also no longer included in coreutils.

In many instances you can use readlink -f
Can CustomPiOS be modified to use readlink instead of relying on realpath?

Unpack does chmod on entire target dir

When I unpack directly into a folder that has existing content, that content also gets chmoded, and I believe that process may also mess with the setuid bit. Is this intended behavior?

cp -v -r --preserve=mode,ownership,timestamps $from/. $to
  if [ -n "$owner" ]
  then
    chown -hR $owner:$owner $to
  fi

Seems to be the issue.

I am trying this untested workaround, but I do not like it because of the extra disk activity:

function unpack() {
  # call like this: unpack /path/to/source /target user -- this will copy
  # all files & folders from source to target, preserving mode and timestamps
  # and chown to user. If user is not provided, no chown will be performed

  from=$1
  to=$2
  owner=
  if [ "$#" -gt 2 ]
  then
    owner=$3
  fi
  mkdir -p /tmp/unpack/
  # $from/. may look funny, but does exactly what we want, copy _contents_
  # from $from to $to, but not $from itself, without the need to glob -- see 
  # http://stackoverflow.com/a/4645159/2028598
  cp -v -r --preserve=mode,timestamps $from/. /tmp/unpack/
  
  if [ -n "$owner" ]
  then
    chown -hR $owner:$owner $to
  fi

  cp -v -r --preserve=mode,ownership,timestamps /tmp/unpack/. $to
  rm -r /tmp/unpack

}

Building Broken on x86\64 Debian System

Commented on the issue here
fb4b810#r38695924

Using a custompios file prior to this commit or just editing that line has building working again.

Will provide a fix as soon as I have one that doesn't break any work after this commit.

Keep the apt archive cache?

I notice that there is a bind mount used to store the apt archive cache, but it also appears to be deleted with apt-get clean in several places.

Package caching is pretty useful and would speed builds a lot, is there a chance of using apt autoclean instead? The bindfs already prevents taking up space in the image itself, so it seems worth it.

Thanks again for the great product!

Variables are not escaped properly

While creating #8, I fixed some of the variable occurrences with improper escaping. The scripts should be revised, and the variables should be escaped appropriately. This is probably quite some work, but should prevent the usual annoyances (like "there must be no space in the paths" etc.).

Wrong size expansion

I do not know if it's a mistake or I've lost something.
I'm trying to generate an image that works on the orange pi zero plus.
I downloaded the specific armbian image for OpiZero plus. I did all the required steps and launched sudo bash -x ./build_dist armbian.
When the image is resized, something strange happens: the resize is always + 400Mbyte even if / CustomPiOS / src / variants / armbian / config explicitly reports BASE_IMAGE_RESIZEROOT = 500

+++ echo 'Resized parition 1 of Armbian_5.38_Orangepizeroplus_Debian_stretch_next_4.14.14.img to +400 MB'

I tried other values but the resize is always 400. The only solution I found was to modify CustomPiOS / src / common.sh function enlarge_ext () changing size = $ 3 in size = 750

[?] How do I use <distroname>-hostname.txt

I have seen the references to the <'distroname'>-hostname.txt file that can be put in /boot but I can't see where the service change_hostname is ever called. I am not sure if it works the same as /<'distroname'>-wpa-supplicant.txt.

If I place a /<'distroname'>-hostname.txt in the root before my first boot, does it change the name before or after expanding the filesystem? Does the change_hostname service need to be run manually from SSH?

aarch64 OrangePi Zero Plus

I'm trying to generate an image to useon Orange PiZero Plus (H5 4 core 64bit) armbian variant
I'm using the OPi0 + to build the image, it seems to be all successful but then the script tries to run /bin/bash with Qemu-arm-static generates an error because it tries to run bash aarch64 with qemo-arm (32bit) .

You probably need to make sure that the right qemu is used according to the target architecture ....

[feature] set name of img on release

See:
zynthian/zynthian-sys#66 (comment)

tl;dr
CustomPiOS should have a variable that lets you set the file name of the image.
Should be used here:
https://github.com/guysoft/CustomPiOS/blob/devel/src/release#L16

cc @jofemodo

Intermittent loop errors

I'm attempting to build something based on the octopi layout.

This build worked, but I wanted to remove the if on the workflow: https://github.com/myoung34/tilty-pi/actions/runs/187201484

which caused this failure despite no changes: https://github.com/myoung34/tilty-pi/runs/923707874

Resizing file system to 1620 MB...
++++ awk '{print $4-0}'
++++ sfdisk -d 2020-05-27-raspios-buster-lite-armhf.img
++++ grep 2020-05-27-raspios-buster-lite-armhf.img2
+++ start=532480
+++ offset=272629760
+++ detach_all_loopback 2020-05-27-raspios-buster-lite-armhf.img
++++ losetup
++++ awk '{ print $1 }'
++++ grep 2020-05-27-raspios-buster-lite-armhf.img
+++ for img in $(losetup  | grep $1 | awk '{ print $1 }' )
+++ losetup -d /dev/loop2
+ exit 1
losetup: /dev/loop2: detach failed: No such device or address
##[error]Process completed with exit code 1.

which seems to be from https://github.com/guysoft/CustomPiOS/blob/master/src/common.sh#L143

other intermittent failures:

• https://github.com/myoung34/tilty-pi/runs/924344319
• https://github.com/myoung34/tilty-pi/runs/924357321

Hit re-run enough times and finally there's a success with no changes: https://github.com/myoung34/tilty-pi/runs/924379003

Add shebang

Add shebang to here:
https://github.com/guysoft/CustomPiOS/blob/CustomPiOS/src/dist_generators/dist_example/src/build_dist

github action for docker build

I am still using custompios, and the octopi work to make the v1pi images. It is working well. I basically ignore it most of the time, and then about every three months I come back and spin up a new pair of images from the scripts on my local machine.

My setup is still a bit brittle though. I am using my own docker setup, and it works on this machine, but it would be better if it was done nightly someplace.

I was thinking about working on some github actions, or a circleci, or travisci setup. But I don't want to reinvent the wheel. Do you (or any images you know) have a CI setup like that? I've used the github actions for another project, and circle CI for another. They both seem to work pretty well. I'm not sure if it is possible with the loop devices though.

When a module fails to build, CustomPiOS keeps building the other modules

A failure should halt the build, the problem happens because there is no testing in /distro/src/workspace/chroot_script that is generated by execution_order.py.

The code there should be improved.

[?] How to rid all set -x commands

I have my OS build working very well (building on Debian), we are nearing the 2nd phase of our OS project. the inclusion of a custom GUI that mimics the Robo3D GUI. But now I am trying to streamline the build log. I thought I had removed all the set -x commands from my module as well as the modules I use from CustomPiOS, but apparently there is one hidden somewhere. When I look at the build log now, it is cleaned up until you get to the point in the build just after the last line of my module's start-chroot-script (there is nothing in the end-chroot-script). Then I see in the log

+ '[' -d custompios_export ']'
+ rm chroot_script
+ '[' -d filesystem ']'
+ rm -rfv filesystem

my config runs everything in base so it looks like this:
export MODULES="base(raspicam,network,disable-services(communityos),password-for-sudo)"
I looked at modules raspicam, network, disable-services, password-for-sudo as well as all the bash scripts I could find, like common.sh, argparse.bash, basically every single file that has #!/bin/bash or #!/usr/bin/env bash as the first line. But somewhere there is a set -x that I can't find.

Debian 10 (Buster), can't mount loop devices

When using Debian 10 as the host to build a CustomPiOS, pulling the latest stable release of Raspbian (Buster) the build script fails when it gets to mounting the loop devices. After the script fails, the following loop devices exist:

loop0 loop1 loop2 loop3 loop4 loop5 loop6 loop7 loop-control

Option to shrink result image

Enlarging the image can be usefull to install apps, but reducing the result image can be also interesting.

For example, you can expand image by 4Gb, do the stuff, and then use a tool like https://github.com/Drewsif/PiShrink to reclaim unused space left, to have a minimal size image (faster to write on SD) that will auto-expand on first boot.

Maybe it can be an option in the config file

Possible leakage of login name from host system?

While building an image, I got the following error:

+ gpg --fetch-keys https://neilalexander.s3.dualstack.eu-west-2.amazonaws.com/deb/key.txt gpg: Fatal: can't create directory '/home/daniel/.gnupg': No such file or directory

I'm not sure what the cause is, but I suspect that anything that looks for the login name is returning the actual user running the build script outside of the VM.

Would setting the login name to pi be more appropriate?

Octopi overwriting variant files on first real boot

Hi Guy/Gina

I'm attempting to turn Prusa 3Ds Octopi fork into a variant (haven't put it onto Github yet, can do if it'll help) so that it can be applied more easily to "central code" - their changes (on the face of it) are configuration for the most part, and it all goes swimmingly right up until I burn the image to SD and boot off it.

The majority of the variant is a config.yaml and printer profile under /filesystem (_default.profile if I'm being pedantic about replicating the fork). I've used post_chroot_script to apply the filesystem changes, and when I qemu_boot.sh the image, everything is right - the config.yaml is there with it's changes, the printer profile is there with it's changes.

As soon as I boot that same image burned to an SD card on an actual Pi, it looks for all the world like both config.yaml and _default.profile are overwritten (entirely in the case of _default.profile, and partially in the case of config.yaml)?

Make release run on dist_build on default distro

Because people want their image to have the right name

Doubt!

I am unable to understand the purpose of this project since readme.rst is not much informed.

My queries:

• Is this project works on developing custom BIOS for rpi.
• Or just port other OS for rpi.

Pardon me for the silly doubt but it will help me to understand its purpose.

many open loops/mount after build_dist

I am working the first time with CustomPiOS and I am happy it's there. I just need to understand the concept a little bit more:
I guess it is not mentioned, but it seems, that for most of the stuff you need to start either with sudo or as root because of all the loop mounts.
After mydist/src/build_dist, there are many mounts ongoing. Is this intended?
Also: build_dist does not produce a zip file, but qemu_boot.sh is looking for one. Is there a reason for that or is it just historical?
I also do only partly understand the workflow idea: in my first sight, it seemed the modules should be used for a single shot setup: this means, on subsequent calls of mydist/src/build_dist the image should be always generated from the vanilla raspian, but this seems not to be the case? Does this mean, that you intend another workflow?
If I get some enlightenment, I could at least contribute to the documentation and/or some script enhancements :-)

Python3 is required for build to succeed on Debian 8.

I had a strange issue during build.

I had to explicitly install python3 for the build to work (apt-get install python3).

I build on a Debian 8 VM installed from scratch as a headless machine, just using ssh, maybe it's just something to add in documentation, or did I miss this prereq from somewhere ?

In addition, adding some detail to build armbian variant to the main page would be helpfull ;)
I found the additionnal info in the issues/pull request, but not on the main page.

Doesn't seem to work with Stretch

Fired this up in a clean install of Ubuntu 16.04 with a Raspbian Stretch image: https://www.raspberrypi.org/downloads/raspbian/, specifically the Raspbian Stretch With Desktop.

When building the .img file, it seems to just hang at a blinking cursor when booting on a pi.
All default setups.

Missing space in test for kernel type

In CustomPiOS/src/modules/kernel/end_chroot_script, the lines 53 and 59 have badly formatted second test, instead of:
if [ "$KERNEL_TYPE" == "both" ] || ["$KERNEL_TYPE" == "v6" ]; then
it should read:
if [ "$KERNEL_TYPE" == "both" ] || [ "$KERNEL_TYPE" == "v6" ]; then
Note the space between the second [ and ".

README instructions say "qemu-arm-static" when it should be "qemu-user-static"

Sent me on a wild goose chase for 30 minutes (partially bc I'm a noob, but still). The link itself links to qemu-user-static.

Guitar Pedal distro

This is not really an issue or bug, there just isn't a good way to dm on github. I've been following your posts on Audio Injector. I have independently built a realtime version of Raspian Stretch, with intention to share as a kind of distro, or prepackaged image for people who want to jump quick into building guitar pedals. It would have the following additional features:

• Auto Wifi Hotspot for easy wireless ssh out of the box
• Seriously gutted systemd for rapid boot-time
• Jack and other audio program boot scripts, with low-latency settings already in place for the main cards (Audio Injector, etc)

I am wondering if, instead of maintaining this seperately by different tools, I should merge this effort with your project. I have not used CustomPiOS, but I can look into it if you feel that there is any benefit to combining effort.

Implement a mechanism for disabling image compression

Implement a mechanism for disabling image compression at the end of CustomPiOS process.

[ReqForInfo] Adding a suffix to DIST_VERSION in variant file?

Is it possible to either add a suffix to DIST_VERSION, or over-write DIST_VERSION completely (while referencing the module value) in a variant file (guessing config, but any of X_chroot_script would suffice)?

I've tried:

DIST_VERSION+="PE"

and

DIST_VERSION=$DIST_VERSION+"PE"

in src/variant/foo/config, but neither of them changed the image DIST_VERSION ("0.16.0").

Prusa are adding "PE" to the DIST_VERSION and it'd be nice to replicate that in my variant.

CommunityOS for Robo3D printers

CommunityOS for Robo3D printers
There are a few very resourceful people on the Robo3D forums that are less than happy that Robo3D has basically abandoned its consumer users. There has only been one single update to their operating environment for the C2 / R2 printers. These printers have a custom UI built using Python and Kivy running on top of OctoPi, with a bunch of junk added. Robo cloned all the repositories for use in their system, which meant users were fully dependent on Robo to provide updates or newer versions of all the OSS parts.

CommunityOS is our attempt to replicate the functionality of Robo's printer OS, but using code that is freely available and easily upgradeable. I based a lot of the code to how OctoPi is set up. There are a lot of additions well beyond what OctoPi does. We have included a large number of OctoPrint Plugins, originally used by Robo in the OS, preconfigured during the CustomPiOS build. We removed the Plugins Robo used that 'phoned home.' Removed CuraEngine but left the code within the module if someone wanted to re-enable its functionality (including automatically adding the new Cura Legacy Plugin). We removed HTTPS access as all modern browsers do not like self signed certs and you cannot register a .local domain with a CA. Touchscreen drivers for various size screens can be selected before building.

Currently the UI is a customized version of OctoPrint-TFT. The plan is to replace this with a look/work-alike GUI similar to Robo's familiar OS.

Even though this distribution is geared specifically toward the Robo3D R2 and C2 printers, we have left enough generic choices to make it usable on other 3D printers. I am currently using it on a self built Eustathios as well as a Trony S5. It was designed to not break if you chose to use the interface on other printers,

Issues with building Armbian images

I tried to build an Armbian image. As suggested by the variants directory, this is officially supported.

Issues I noticed:

• When picking a Debian image, there's dependencies missing which are not installed by default. Most prominently, adduser command is not available, preventing a console login as a whole. I have not invested too much time into debugging this, and am now running an Ubuntu build, which I hope will work better. But at least adduser should be installed by your scripts.
• Armbian images ship as 7-zip archives (.7z). Therefore, I replaced the unzip call with a 7za call. This should work fine for .zip archives as well. I'll create a PR soon.

Regarding the missing dependencies, someone has to invest some time into testing this, which I don't have at the moment. PRs welcome I guess.

(If the Ubuntu build shouldn't work either, I'll considering taking the time for further tests with Debian as well, but will try to fix at least the Ubuntu build.)

depend on other custompios modules

I want to make an octopi with auto-wifi-hotspot and also cnc.js. I think I'm getting there after editing the octopi repo, but I think it would be cleaner if I could define two locations for modules, then I could have my own repo next to octopi.

so my config would look something like this:

export MODULES="base(raspicam, network, node.js, disable-services(octopi, cnc.js, auto-hotspot), password-for-sudo)"

I'm really loving working on this, btw. I'll have to write the node.js and cnc.js modules. It's very well thought out.

Build fails because of line added in "start_chroot_script"

Hi there. I am very new to this, so my apologies if this is an ignorant question, but I couldn't Google my way to a solution 😅

I'm trying to build a quite simply image. I'm building it from Octopi (having forked it). Were originally gonna create a variant of OctoPi, as per suggestion by the developer, but as this image needs to be done very soon, I just went with modifying OctoPi instead.

All I have modified is the src/modules/octopi/filesystem/home folder, where I have added a folder containing some Python scripts. These are added to the image just fine, but when adding the line sudo -u pi pip install pyyaml requests python-crontab (dependencies of my scripts) in the start_chroot_script, the build fails consistantly.

Is there a better way of installing these dependencies in the CustomPiOs build? Just need the required pip packages installed, and for one of my python-scripts to be opened at first boot of the RPI.

I think all I need is being pointed in the right direction (hopefully). Thanks!

[?] Why does QEMU display error: Unknown host QEMU_IFLA type

Running a start_chroot_script that appears to build correctly. In several locations in the script QEMU displays Unknown host QEMU_IFLA type: followed by a number 40, then the same message followed by a 41. It is notable when doing anything within the script that needs to access a file on another site, such as the git repositories or googleapis, etc.

I am using debian 9 in an Oracle VirtualBox

This is not a bug report, but more of a question about why it may be happening, and maybe a suggestion on how to clean it up.

qemu-arm on an arch-linux based laptop.

Hey Guy,

I switched to using an arch derivative for my home computer, and the "native" version isn't building a custom Pi os.

For starters, the qemu-arm-static is named "qemu-arm" (and I know nothing about qemu, so I'm just thinking it's the same because it prints the same help message :D ). I switched the custompios script to look for that, but it's erroring with:

chroot: failed to run command 'usr/bin/qemu-arm': No such file or directory

So it seems like I'm not doing that right, but in fact, it is there. I added a few prints to the custompios script:

+ cp /usr/bin/qemu-arm usr/bin
+ cp /home/jeff/src/CustomPiOS/src/modules/base/start_chroot_script chroot_script
+ chmod 755 chroot_script
+ cp /home/jeff/src/CustomPiOS/src/common.sh common.sh
+ chmod 755 common.sh
+ pwd
/home/jeff/src/test/src/workspace/mount
+ ls -al usr/bin/qemu-arm
-rwxr-xr-x 1 root root 4557848 Apr 30 11:57 usr/bin/qemu-arm
+ ls -al bin/bash
-rwxr-xr-x 1 root root 912712 May 15  2017 bin/bash
+ ls -al chroot_script
-rwxr-xr-x 1 root root 1331 Apr 30 11:57 chroot_script
+ chroot . usr/bin/qemu-arm /bin/bash /chroot_script
chroot: failed to run command 'usr/bin/qemu-arm': No such file or directory

So the qemu-arm is found, copied into the mount/usr/bin folder, and chroot . usr/bin/qemu-arm says "No such file or directory"... Weird. Maybe it's something wrong with chroot?

I know arch is a rolling release, so the versions are often newer. The chroot version is 8.29 and qemu-arm is 2.11. BTW, I installed qemu using qemu-headless-arch-extra 2.11.1-2.

Here is the "full" log:
build.log

I'm hoping I don't have to use vagrant on a brand new Linux OS, but if I have to, I guess I'll try that next.

Filesystem files not available in custom OS image (burned and booted to a Pi)

Here's a (as of yet non-existent) PR showing an example of what I'm doing: https://github.com/guysoft/CustomPiOS/compare/devel...RyanBalfanz:supervisor?expand=1.

The files /etc/supervisor/conf.d/* do not exist in my build and deployed custom OS (e.g. https://github.com/RyanBalfanz/RTSPiOS/tree/master/src/modules/rtspios/filesystem/root/etc/supervisor/conf.d), but I'm not sure why.

Building on Windows

Hey,
So this weekend I was playing around with building OctoPi on windows (and hopefully after that other CustomPiOS distros).

My current work is available on the windows branch on OctoPi
and windows branch on CustomPiOS.

I managed to run a successful build and I will explain how and the limitations.

Before I start I'll mention - no native build is planned, only using the vagrant method, because its the only way.

Requirements

1. Vagrant
2. Virtualbox
3. Power shell or bash (see decision)
4. git with bash (will be needed eventually)

limitation (why does't windows work now)
The main limitation in supporting windows is no way to preform loopback mounts on synced folders in windows.
CustomPiOS mounts the img file form the workspace, and the workspace sits in a synced folder. This is supported by NFS, but not by any other method. And NFS is not supported by windows. I also tried the winnfsd plugin. But it was unstable, sometime it writes, sometimes it skips. Which means things are random and usually the build fails.

The workaround is simply - build inside the VM and them move the image outside to the syned folders when its done.
So I wrote a small script to set the CustomPiOS path. and a vagrant-windows build. If you run those too, similar to their linux/mac equivalent, then a successful build will go. The release script needs to be updated still.

Decision that need to be made
I would prefer to maintain everything using bash, but bash needs to be installed and I am not sure if windows users tend to download git for windows which I've been using. So the question is do I make it a requirement, or implement everything twice with powershell.

For now, here is picture of a successful build in windows:

Execute functions in variant config file & "pip: command not found"

Hi there :)

I have two questions/issues, but first some info on the project;
I'm building a variant for OctoPi (forked the OctoPi repository), so I am a little unsure whether I should post this here or at the OctoPi repository, but my guess is here, since it's more of a CustomPiOs question.

The variant is quite simple, some files are included in the build (which I've got working), I wanna edit the hostname and want some files to be executed upon first boot.

---

Questions;

1. In my variant I have a config file taken straight out of the CustomPiOs variant example, but I attempt to set the hostname to "static_text-{4 random characters}" like this;
BASE_OVERRIDE_HOSTNAME="SimplyPrint-$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 4 | head -n 1)"
The hostname still ends up being "octopi" though, and when just having the value be; BASE_OVERRIDE_HOSTNAME=blueberrypi it worked fine. Is it not possible to execute functions / run code in the hostname?

2. In post_chroot_script I tried doing the following;

# Install required python packages
yes | pip install pyyaml requests python-crontab

# Make sure the SimplyPrint system runs
python /home/pi/SimplyPrint/crontab_manager.py -s > /dev/null 2>&1

# Install SimplyPrint OctoPrint plugin
/home/pi/oprint/bin/python2 -m pip --disable-pip-version-check install /home/pi/SimplyPrint/SimplyPrint-OctoPrint-Plugin.zip --no-cache-dir && \\
rm -rf /home/pi/SimplyPrint/SimplyPrint-OctoPrint-Plugin.zip

right after unpacking the variant filesystem, but if any of these lines exist, the build fails (build.log). Is this the right place to do what I'm attempting to do? I just want it to install the dependencies and possibly run a script once. This script could also just run on first boot of the Pi. I am also trying to install an OctoPrint plugin on boot from a zip file included in the filesystem.

The last lines of the terminal when the build fails is;

'/tmp/unpack/./home/pi/scripts/welcome' -> '/./home/pi/scripts/welcome'
+ rm -r /tmp/unpack
+ yes
+ pip install pyyaml requests python-crontab
/chroot_script: line 11: pip: command not found
++ echo_red -e '\nBUILD FAILED!\n'
++ echo -e -n '\e[91m'
++ echo -e '\nBUILD' 'FAILED!\n'

BUILD FAILED!

++ echo -e -n '\e[0m'

with line 11 being the "yes | pip install (...)" line.

Seeing the build fails I'm thinking the post_chroot_script might not be the right place to do what I'm attempting to do, so any advice on how to proceed from here would be greatly appreciated! :)