at the moment this is designed for upgrading via USB stick, but not over the network ?

https://github.com/gokrazy/gokrazy

gokr-packer \
  -overwrite_init=$(go env GOPATH)/src/github.com/stapelberg/mediaserver/cmd/init/init.go \
  github.com/gokrazy/hello

(Note that the package must result in a binary called “init”.)

Then, edit the github.com/stapelberg/mediaserver package to your liking. When done, pack an image with your own init package:

gokr-packer \
  -init_pkg=github.com/stapelberg/mediaserver \
  -overwrite=/dev/sdb \
  github.com/gokrazy/hello

That repo is private/non-existent.

Platform

I’m using:

• gokrazy/apu2e4 (router7 on the PC Engines apu2e4, which from my understanding uses gokrazy underneath)

Observed behavior

Partition 2 and 3 on a recently created new installation of router7 use the squashfs file system.

Expected behavior

The documentation (see https://github.com/gokrazy/gokrazy#sd-card-contents) describes partition 2 and 3 to use the FAT16B file system.

Conclusion

Looking at the current implementation (see https://github.com/gokrazy/tools/blob/a11ea1b25921d1f2d990d9d2b9b398d879ce4102/cmd/gokr-packer/parttable.go#L31) I think the documentation is outdated.

https://github.com/cf-unik/unik

Really great to see this moving forward.

Please make the image use a random password generated at write time instead of a common password known to potential attackers. Default passwords are the source of multiple CVE's and seems at odds with the primary goal of reducing attack surface.

https://roughtime.googlesource.com/roughtime is not quite ready yet — the client implementation doesn’t set the system clock and Google’s servers don’t provide any uptime guarantees yet.

We should keep an eye on it and maybe switch from NTP to roughtime if roughtime proves itself.

generally you need a key chain of sorts to store a password to a DB.
In IOT world anyone can grab your device, so you need to encrypt sensitive data.
A key store allows this for use cases of:

• DB password.
• credit cards and other Sensitive info

I have not looked into how hard this is
there are go loibs out there for the basic crypto stuff.

is this something you feel is worthwhile putting effort into ?
i would like to try to get it working, but might need to hassle you a bit

OS: Archlinux (4.11.6-1-ck-broadwell)
Go: 1.8.3

$ go env                                                                                                                               
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/xengi/.go/"
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build826494141=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

Trying to follow the quickstart guide:

$ go get -u github.com/gokrazy/tools/cmd/gokr-packer
$ sudo setcap CAP_SYS_ADMIN,CAP_DAC_OVERRIDE=ep $(go env GOPATH)/bin/gokr-packer
$ gokr-packer -overwrite=/dev/mmcblk0 github.com/gokrazy/hello
2017/06/27 00:41:23 packer.go:213: installing [github.com/gokrazy/hello]
go install runtime/internal/sys: mkdir /usr/lib/go/pkg/linux_arm64: permission denied
2017/06/27 00:41:23 packer.go:458: exit status 1

The problem is that it tries to use go install which tries to put stuff in $GOROOT which it shouldn't do. Instead it should use go build and put stuff into $GOPATH. At least that is what I think is right. I'm pretty new in the go world.

Presumably, some applications might need locales. We should look into how we can generate them and include them.

As pointed out in eb8f175#commitcomment-23814128

It might a good thing, if a wifi network can be configured. The SSID and password would be used at boottime to connect to the local WLAN.

I would like to use this with robotics but also for making light hand held display terminals for controlling / programming the robotics. Its 100% golang except for its dependency on openGL via glfw.

So, Is there a standard way for me to get glfw backed into the build ?

The Raspberry Pi 4 was just released: https://www.raspberrypi.org/blog/raspberry-pi-4-on-sale-now-from-35/

I have ordered one to make sure gokrazy works on it.

Update: tracking issues that I have encountered on the Raspberry Pi 4 Model B (rpi4b):

• the UART swap dtb patch needs to be rebased onto the rpi4 dtb file
• the broadcom genet driver needs to be enabled for the eth0 network interface to show up
• The SD card reader currently ends up at /dev/mmcblk1*, but should be /dev/mmcblk0* for consistency with earlier models.
  • The Raspberry Pi kernel uses a kernel patch for mmc numbering based on devicetree aliases, but the patch has been declined for upstream inclusion.
  • Side note: this wouldn’t be a problem if we would use UUID= to specify the root device, but those require booting with an initrd, which is something I’d like to avoid for as long as possible.
  • We’re now using PARTUUID=, which is understood by the kernel and does not require an initrd: see issue #52
• network interface: interface detected and link status shown as up, but device does not respond to IPv6 link-local pings or fetch an IP address via DHCPv4
  • EEPROM version “2019-09-10 - Git f626c772” contains the only ethernet change, but it might be relevant: “Configure ethernet RGMII pins at power on. This is a minor change which which may improve reliability of ethernet for some users.”.
  • In my tests, updating to the latest rpi-eeprom (git commit a5be2ff8b15dd36cb3bb83a3f864514cd9cfcf3e) helped a bit (the device picks an IPv6 address based on router advertisements), but I still can’t get ethernet to work.
  • posted lategoodbye/rpi-zero#47
  • fixed by setting phy-mode to rgmii
• include Raspberry Pi 4 firmware files (start4*, fixup4*)
• USB ports don’t work
  • the xhci_hcd driver is enabled (CONFIG_USB_XHCI_HCD=y), but doesn’t enumerate any devices at boot
• set up an rpi4 in continuous integration
• include eeprom updates (gokrazy/rpi-eeprom for consistency? or just include in firmware?)
  • background info: https://news.ycombinator.com/item?id=21674550
  • set up GitHub actions CI to pull in new EEPROM versions
  • packer: ensure filenames match the updater pattern
  • display the eeprom version by reading pieeprom.sig and vl805.sig when RECOVERY.00* is present (= last update succeeded)
  • skip updates when the EEPROM is already up-to-date Update: I have verified that the bootloader skips EEPROM updates when the EEPROM is already up to date: https://user-images.githubusercontent.com/55506/85105058-10d47e80-b20a-11ea-8d13-5caa8ad961c3.jpg
• update issue template
• update website
• update README.md
• update gokr-packer message
• repo descriptions

With IOT devices, you want to be able to reach it, and you want to be able to collaborate with other users / Devices.
QUIC is a UDP based protocol developed by google for this.
Its 100% golang and not kernel dependent and thats part of why its so compelling for IOT.

It makes it easy to do peer to peer and it very very fast.
It also very easy to use it to standard golang Http handler.

Gokrazy can use it for talking to the RaspberryPI from anywhere, easily.
Apps built on top can use it in a myriad of ways.

Here some great URLS:
https://github.com/lucas-clemente/quic-go

• The core QUIC code.

https://github.com/marten-seemann/libp2p-quic-transport

• Using QUIC with the IPFS system. Really nice as it makes it very easy to send messages between different IOT devices or mobiles with a consensus and data store and pubsub. Its kind of go it all.
• IPFS allows any transport protocol to be used, and the addition of QUIC is very new, so dont expect this to be stable yet. But you can se where its going.

Currently, this can be done by statically compiling busybox and placing it on /perm/sh.

This is a worthwhile-enough feature that it should be included and enabled by default (with a flag to turn it off in environments where it doesn’t make sense).

• publish https://github.com/gokrazy/serial-busybox
• push commit which picks up the new well-known path
• update quickstart guide to include the package by default

I am sure there is a simpler and more elegant way of handling things than I am currently doing. And it probably should be referenced in the README.md somewhere, but what is best practice when using gokr-packer with sudo in regards to environment variables?

I tried go 1.8.0 and 1.8.1 and it does not work with the same error message
I am using raspbian on a raspberry pi 3 with
Linux raspberrypi 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux
My second sd-card is not mounted and with no partition with 32GB.
gokr-packer shows the following messages
packer.go:225: installing [github.com/gokrazy/hello]
packer.go:123: partitioning /dev/sda
packer.go:285: invalid argument

I know that it is currently not implemented, but please do support 32-bit ARM architectures. It would allow us to run this on target hardware such as the Orange Pi Zero, which costs less than a fifth of a Raspberry Pi 3 and is more than enough for many workloads.

Thanks for your consideration.

http://www.orangepi.org/orangepizero/

Apologies if this is not the correct forum; I don't see a mailing list.

I am interested in using gokrazy with a PiCam module. I don't see any cam support userland here, so I am suspecting that I would need to use raspivid and its C runtime dependencies as described in the prototyping page. Is this correct?

I've been working on a way to run OCI containers via runc in gokrazy in a way that the non-go/cgo binaries can be updated with the usual gokr tools. Unfortunately that probably means packing binaries into go byte slices. My specific use case is to enable wifi via IWD. Related: #13

I don't expect this to be officially supported as-is, however i wanted to see if there would be any interest in officially supporting the use of containers or a sandboxing tool like bubblewrap? To get runc or any code that uses libcontainer running the only cgo exception would be https://github.com/opencontainers/runc/tree/master/libcontainer/nsenter

If that small exception was made for libcontainer, gokrazy users would be able to pull container images, configure sandboxing features and run anything they like with some added safety. Perhaps it could be seen as a more sophisticated breakglass.

At least on Mac OS X 10.12.3, gokrazy

sudo -E $(which gokr-packer) -overwrite=/dev/disk2 github.com/gokrazy/hello
2017/03/25 13:53:04 packer.go:222: installing [github.com/gokrazy/hello]
2017/03/25 13:53:08 packer.go:123: partitioning /dev/disk2
2017/03/25 13:53:08 parttable.go:82: device holds 7861174272 bytes
2017/03/25 13:53:08 packer.go:131: waiting for /dev/disk2s1 to appear
2017/03/25 13:53:09 packer.go:282: open /dev/disk2s1: resource busy

My diskutil shows that the NOOBS partition is ejectable after partitioning, so it's probably being remounted by the OS immediately after it's written?

As discussed offline, it would be great, if gokrazy would support full auto-updates (driven by gokrazy itself).
It would probably require shipping a copy of the go tool and the packer, regularly checking for updates via the github API, fetching a tarball of the content (as we won't have git/mercurial/svn on the rpi) if there is one, rebuilding the image and rebooting. Most of this can probably be built as a service, though some changes to the packer are required: a) The packer needs to add a released binary of the go tool (we probably don't want to do a full recompilation?) and b) it needs to add meta-information about the build, so that the packer running on gokrazy can rebuild it.

It's probably also worth it to consider user-packages for auto-updates, though the process is probably going to be different. Most third-party things probably shouldn't be built from HEAD, so either we need to rely on some kind of versioning scheme to decide what to update to, or rely on github releases and download binaries.
Updated versions should first be written to and started from /tmp, to make sure that they start correctly. Afterwards, the packer needs to build a new image containing the updated binary.

I think in the end we'd want auto-updates both for gokrazy itself and the user-installed services, to have fully self-updating appliances.

The current logic of WaitForClock isn't particularly robust. If, for whatever reason, the NTP servers aren't reachable for one minute after boot, it will return with an unset time. This doesn't seem unrealistic to me, for example it might take a while after a power outage for the network to come up. It's also not totally harmless; if you use gokrazy for home automation and log data, you'll get nonsensical timestamps in your logs.

I think gokrazy should provide a more robust mechanism to notify for this (and maybe also a successful DHCP leases?). Solution for this could range form simple (ntp updating a file in /tmp when the time was successfully set) to more complex and extensible (init passing a file descriptor for some sort of messaging bus or whatever to child processes).

Let me know if you think this is a good idea and what you would propose.

example use-case: temporarily upload a busybox shell for debugging

• authenticate caller using passwords
• accept tarball, unpack into a tmpfs
• start SSH server which will run the command which was specified in the request

Currently, gokrazy defaults to providing a serial console on GPIO 14/15, which means the pins aren’t (cleanly) usable for an application.

We should add a --serial_console= flag with the following options:

• UART0 (default): sets enable_uart=1 in config.txt, adds console=ttyAMA0,115200 to cmdline.txt
• UART1 (not implemented until we have bluetooth support, if ever)
• disabled: sets enable_uart=0 in config.txt, removes console= parameters from cmdline.txt

Following the proposed installation procedure, the installation fails:

0. System
   $ uname -a
Darwin computer.local 15.6.0 Darwin Kernel Version 15.6.0: Mon Jan 9 23:07:29 PST 2017; root:xnu-3248.60.11.2.1~1/RELEASE_X86_64 x86_64
$ sw_vers -productVersion
10.11.6

1. Checking for correct Go version 1.8:

   $ go version
go version go1.8 darwin/amd64

2. Installing gokrazy:

   $ go get -u github.com/gokrazy/tools/cmd/gokr-packer
# github.com/gokrazy/gokrazy/internal/iface
go/src/github.com/gokrazy/gokrazy/internal/iface/iface.go:108: undefined: syscall.SIOCADDRT
go/src/github.com/gokrazy/gokrazy/internal/iface/iface.go:122: undefined: syscall.SIOCDELRT

The correct behavior would be to install without errors.

As discussed in person, to make the update process a bit safer, we’d need:

• two boot partitions. We already use 4 of 4 primary partitions in our MBR partition table, but:
  • We don’t strictly need the partition table entry, because we reference the file system using block offsets in the ASM bootloader only. Hence, we could do 2 100 MB file systems in a 200 MB partition
• a stub bootloader which mirrors the behavior we get from our ASM bootloader.

Then, we could switch between an a/b boot and a/b root partition ≈atomically (writing 2 offsets)

Are there problems with the program path to go and work directory? Does the procedure require certain rights?

bla@debian:~/go/bin$ sudo setcap CAP_SYS_ADMIN,CAP_DAC_OVERRIDE=ep $(go env GOPATH)/bin/gokr-packer

bla@debian:~/go/bin$ gokr-packer -overwrite=/dev/sdb github.com/gokrazy/hello
2017/04/16 21:45:55 packer.go:225: installing [github.com/gokrazy/hello]
go install runtime/internal/sys: mkdir /usr/local/go/pkg/linux_arm64/runtime: permission denied

Platform

I’m using:

• gokrazy/rpi3b
• gokrazy/rpi3b+
• gokrazy/rpi02w
• gokrazy/apu2c4
• gokrazy/x86-64

Observed behavior

I installed github.com/joneskoo/ruuvi-prometheus which depends on Bluetooth hardware. It failed to start.

After breaking glass, and looking at the kernel, it looks like Bluetooth is intentionally disabled.

I could not find an option to disable serial console and enable Bluetooth instead. I know they can't be enabled at the same time on the hardware UART, possibly not at all.

On Alpine Linux, I know I need to use bluez btattach to initialize the Bluetooth interface on serial port. Online, I saw pointers that it could be enabled without bluez using dts overlay: https://github.com/RoEdAl/alarm-bluetooth-raspberrypi

Expected behavior

Raspberry Pi 3B+ Bluetooth supported (as option)

We need to (?) issue the BLKRRPART ioctl for the kernel to re-read the partition table. This requires the CAP_SYS_ADMIN privilege.

Also, we need to open the SD card block device for writing, which requires to be in the group which owns the block device node (e.g. /dev/sdb).

Currently, the instructions say:

sudo adduser $USER disk
setcap CAP_SYS_ADMIN=ep ~/go/bin/gokr-packer
sg disk -c 'gokr-packer github.com/stapelberg/zkj-nas-tools/avr-x1100w'

It would be good to avoid the group permission business entirely.

I tried loginctl attach seat0 /sys/block/sdb, but that fails with Could not attach device: No such device.

https://github.com/jnjackins/cmd

Might be good for gokracy. i use these everywhere

• authentication (see issue #7)
• stream boot and root images to /dev/mmcblk0p{1,2,3} (A/B scheme)
• update /boot/cmdline.txt to refer to the other root partition
• CLI tool to automate the process

To explain the following features:

• remote syslog
• connecting to (unencrypted) WiFi networks
• updating via TLS (once that’s implemented)
• toggling a GPIO: #33 (comment)
• running popular stacks, e.g. prometheus+alertmanager+grafana
• generating and writing to the SD card an image on Windows (#16)

Platform

I’m using:

• gokrazy/rpi3b
• gokrazy/rpi3b+
• gokrazy/apu2c4
• gokrazy/x86-64

Observed behavior

i've added to the config.txt in gokrazy/kernel the following lines

dtparam=spi=on
dtoverlay=spi-bcm2835

also tried with dtoverlay=spi-bcm2708

no spi devices are available
/tmp/breakglass156884305 # ls -al /dev/sp*
ls: /dev/sp*: No such file or directory

also nothing in the kernel log
/tmp/breakglass156884305 # dmesg | grep spi

Expected behavior

something along the lines like this in dmesg
[ 4.813403] bcm2708_spi 20204000.spi: SPI Controller at 0x20204000 (irq 80)

and the corresponding devices in /dev

i want to use go krazy for basic robotic hardware

Google have a project for hardware IO in golang with no cgo dependencies.
https://periph.io/

Would this work, given that gokrazy does not allow c dependencies ?

Currently, we use a FAT file system for both boot (required) and root (convenient, because we already have an implementation).

FAT comes with a few disadvantages when used as a root file system: file names are truncated to 8.3 characters and symlinks are not supported.

The most promising candidate for a simple root file system seems to be SquashFS.

The gokrazy overview HTML page contains instructions on how to create permanent storage. These instructions currently rely on the user getting their device nodes right. Instead, we should use a path within /dev/disk/ that is unique.

In the fat/writer package documentation, the limit is 127 MB. Either the docs are wrong or there is a bug in our implementation. In any case, we should raise the limit to 500 MB (full partition size).

Currently, individual apps need to implement remote syslog themselves. It would be nice to just echo 10.0.0.76:514 > /perm/remote_syslog/target and have stdout/stderr of all apps copied to that location.

This helps with issue #48.

• include the 32-bit disk signature in the MBR (not partition table) as per https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout
• derive the ID from the hostname so that it is different but stable per device (uncouples updates of cmdline.txt on the boot partition from updates to the MBR)
• update the root device finding (and deriving) code to find the PARTUUID by probing block devices
  • introduce a helper function into internal/rootdev which returns a partition by number (and replace all string concatenation)
  • ensure update code retains PARTUUID= name in cmdline (currently uses actual device names)
• test update (including MBR) on bakeryapu2c4
• packer: don’t use PARTUUID= when -update is used and the target’s userland is too old (wouldn’t switch the active root partition correctly, resulting in an un-bootable device)

just trying this out from OSX.

Setcaps is not available, and it might be why the update to the SD card was refused ?

using diskutil to make sure i hit the right disk :)

x-MacBook-Pro:bin apple$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage Ohne Titel              250.1 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Ohne Titel             +249.8 GB   disk1
                                 Logical Volume on disk0s2
                                 3877FA65-5A90-469F-B4AD-0D12C262693B
                                 Unencrypted

/dev/disk2 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *15.9 GB    disk2
   1:             Windows_FAT_16 RECOVERY                1.3 GB     disk2s1
   2:                      Linux                         33.6 MB    disk2s5
   3:             Windows_FAT_32 boot                    69.2 MB    disk2s6
   4:                      Linux                         14.6 GB    disk2s7

x-MacBook-Pro:bin apple$ sudo setcap
Password:
sudo: setcap: command not found
x-MacBook-Pro:bin apple$ sudo setcap
sudo: setcap: command not found
x-MacBook-Pro:bin apple$ go get github.com/gokrazy/hello
x-MacBook-Pro:bin apple$ gokr-packer -overwrite=/dev/disk2 github.com/gokrazy/hello
2017/05/01 17:05:17 packer.go:225: installing [github.com/gokrazy/hello]
2017/05/01 17:05:18 gotool.go:60: getting incomplete packages [github.com/gokrazy/gokrazy/cmd/dhcp github.com/gokrazy/gokrazy/cmd/ntp]
2017/05/01 17:05:34 packer.go:123: partitioning /dev/disk2
2017/05/01 17:05:34 packer.go:285: open /dev/disk2: permission denied

Your job is great, but i only have Windows programming environment, how to overwrite the SD card in Windows? I wondered. The only way is to install virtual machine?

I'd like to use Gobot with gokrazy. I've added CONFIG_GPIO_SYSFS=y to the GPIO block in build.go to get /sys/class/gpio/export and /sys/class/gpio/unexport. However, gokrazy is not allowed to r/w.

I am neither certain on how to allow it to the user nor if it'd be a good idea.

From https://github.com/gokrazy/gokrazy

gokr-packer -update=http://gokrazy:mysecretpassword@gokrazy/ github.com/gokrazy/hello

That's a bad example, encouraging bad habits in people. You can do better than that!

This issue describes which authentication mechanisms and transport layer security configurations we’d like to support.

details:

• for all password authentication scenarios, the password which is stored in ~/.config/gokrazy the first time an image is created
• in scenario ①, we make the assumption that TLS is not necessary for wired connections (low risk of eavesdropping) or wireless connections (the wifi encryption is good enough)
• in scenario ②, users need to add the self-signed certificate to their browser (we should have instructions) (skilled users could click away the security warning when the risk of MITM is low, but we shouldn’t encourage that behavior)
• in scenario ④, we load combined PEM files, or keys/certs from separate files

discarded approaches:

• adding a self-signed certificate to the system certificate store (/etc/ssl/certificates) and/or browser-specific certificate stores (using certutil for chrome and firefox): browsers don’t pick up changes unless you cause them via their UI (see e.g. cr issue 489956#c18). Notably, on Fedora, this works better: ubuntu bug, debian bug — possibly we can revisit this approach in the future.
• https://git.daplie.com/Daplie/localhost.daplie.me-certificates or similar (publicly available key material)