exit status 1

Question

exit status 1

rgl opened this issue 4 years ago · comments

Exits with exit status 1 without any clue of what might be wrong:

$ gokr-packer -overwrite_boot=/tmp/boot.fat -overwrite_root=/tmp/root.fat github.com/gokrazy/hello
2020/06/20 09:23:36 packer.go:345: installing [github.com/gokrazy/hello]
2020/06/20 09:23:36 gotool.go:68: getting incomplete packages [github.com/gokrazy/gokrazy/cmd/dhcp github.com/gokrazy/gokrazy/cmd/ntp github.com/gokrazy/hello github.com/gokrazy/gokrazy github.com/gokrazy/kernel github.com/gokrazy/firmware]
2020/06/20 09:26:00 write.go:149: writing boot file system
2020/06/20 09:26:00 packer.go:793: exit status 1

My go environment is:

$ go version
go version go1.14.2 linux/amd64

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/rgl/.cache/go-build"
GOENV="/home/rgl/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/rgl/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/rgl/Applications/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/rgl/Applications/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build478674939=/tmp/go-build -gno-record-gcc-switches"

Michael Stapelberg · Answer 1 · Sat Jun 20 2020 16:50:52 GMT+0800 (China Standard Time)

Can you update to commit 09a065c and try again please?

Rui Lopes · Answer 2 · Sat Jun 20 2020 16:59:47 GMT+0800 (China Standard Time)

Its now:

$ gokr-packer   -overwrite_boot=/tmp/boot.fat   -overwrite_root=/tmp/root.fat   github.com/gokrazy/hello
2020/06/20 09:58:43 packer.go:345: installing [github.com/gokrazy/hello]
2020/06/20 09:58:46 write.go:149: writing boot file system
2020/06/20 09:58:46 packer.go:793: [go list -f {{ .Dir }} github.com/gokrazy/rpi-eeprom]: exit status 1

Michael Stapelberg · Answer 3 · Sat Jun 20 2020 17:01:32 GMT+0800 (China Standard Time)

Are you not using Go module mode yet? If no, you may need to manually go get github.com/gokrazy/rpi-eeprom first.

Rui Lopes · Answer 4 · Sat Jun 20 2020 17:03:45 GMT+0800 (China Standard Time)

go 1.14 shouldn't use that mode automatically?

note that I'm not using git clone for getting the repo, as that's not mentioned at https://github.com/gokrazy/gokrazy readme.

Michael Stapelberg · Answer 5 · Sat Jun 20 2020 17:26:28 GMT+0800 (China Standard Time)

Please see https://gokrazy.org/quickstart/ for instructions.

Rui Lopes · Answer 6 · Sat Jun 20 2020 17:29:53 GMT+0800 (China Standard Time)

Maybe you should also include the command outputs in 09a065c?

Michael Stapelberg · Answer 7 · Sat Jun 20 2020 17:33:43 GMT+0800 (China Standard Time)

Done in commit faba15f

Rui Lopes · Answer 8 · Sat Jun 20 2020 19:12:37 GMT+0800 (China Standard Time)

Its kinda odd putting that directly into gokr-packer stderr because stdout does not have the same treatment. What I meant was, it should be in go error somehow. Something like (warn: I didn't try this):

	b, err := cmd.Output()
	if err != nil {
		return "", fmt.Errorf("%v: %v output: %v", cmd.Args, err, b)

Or even wrapped in a second error using go1.13-errors wrap?

BTW, the quick start guide should be integrated in the https://github.com/gokrazy/gokrazy repo README or should be explicitly mentioned from there, as it makes the first time user experience a lot smoother.

The quick start guide starts with a somewhat cryptic command to initialize a go.mod. As a first time user I have no idea of what I'm doing and the quick start / readme should put me in the happy path as fast as possible. I would modify the quick start to something alike:

install go
mkdir hello && cd hello && go mod init hello
go get -u github.com/gokrazy/tools/cmd/gokr-packer (or download from the github releases page?)
gokr-packer -overwrite=gokrazy.img -target_storage_bytes=1153441792 github.com/gokrazy/hello github.com/gokrazy/serial-busybox
burn gokrazy.img to an sd-card
boot the pi and watch its serial port (having a text message in the hdmi port would be nice too)

IMHO, having it generate an image instead of directly burning to the sd-card device is a more normal approach for pi users (and it does not require root). After seeing gokrazy working, the user will read the rest of the documentation and will figure out the other ways to create the sd-card.

Can we also have a target_storage_size argument that accepts human sizes (e.g. 2g)?

Michael Stapelberg · Answer 9 · Sat Jun 20 2020 19:30:38 GMT+0800 (China Standard Time)

Its kinda odd putting that directly into gokr-packer stderr because stdout does not have the same treatment

And it shouldn’t. But stderr is something we plumb through in all the other exec calls, too, so this change just makes that consistent. I think it’s perfectly fine to do.

BTW, the quick start guide should be integrated in the https://github.com/gokrazy/gokrazy repo

Done.

I updated the quickstart guide in commit 5dbb7728250939c7db3744bca41ea7394f6aff91, thanks for your suggestions.

IMHO, having it generate an image instead of directly burning to the sd-card device is a more normal approach for pi users (and it does not require root)

Having a single command to fully overwrite an SD card is an explicit goal of gokrazy. At least one of the various ways the packer can do privilege elevation tends to work in practice, and I really prefer this process over dealing with SD card images yourself.

Can we also have a target_storage_size argument that accepts human sizes (e.g. 2g)?

It’s easy enough in any shell to specify e.g. $((2*1024*1024*1024)), and that nicely documents whether 2 GiB or 2 GB are meant.

Rui Lopes · Answer 10 · Sat Jun 20 2020 21:22:36 GMT+0800 (China Standard Time)

Go it working :-)

But for some reason ntp is failing with:

  1970/01/01 01:00:03 gokrazy: attempt 0, starting [/gokrazy/ntp]
  1970/01/01 01:00:03 ntp.go:51: setting time failed: lookup 0.gokrazy.pool.ntp.org on [::1]:53: read udp [::1]:55262->[::1]:53: read: connection refused
  1970/01/01 01:00:03 privdrop.go:87: exit status 1
  1970/01/01 01:00:03 gokrazy: exit status 1
  1970/01/01 01:00:04 gokrazy: attempt 1, starting [/gokrazy/ntp]
  1970/01/01 01:00:04 ntp.go:51: setting time failed: lookup 0.gokrazy.pool.ntp.org on [::1]:53: read udp [::1]:41891->[::1]:53: read: connection refused
  1970/01/01 01:00:04 privdrop.go:87: exit status 1
  1970/01/01 01:00:04 gokrazy: exit status 1

Michael Stapelberg · Answer 11 · Sun Jun 21 2020 00:04:54 GMT+0800 (China Standard Time)

Glad to hear you got it working! Does ntp not eventually recover after the network becomes available?

You should see the timestamps start working at some point in the hello world process.

Rui Lopes · Answer 12 · Sun Jun 21 2020 01:02:25 GMT+0800 (China Standard Time)

Ah it does recover! The ntp service never writes a message with the correct date (maybe it should the first time it updates the time?), but hello world does!

Rui Lopes · Answer 13 · Sun Jun 21 2020 01:16:31 GMT+0800 (China Standard Time)

Have you noticed the Kernel parameter elevator= does not have any effect anymore. warning?

[    0.000000] Kernel command line: earlyprintk console=tty1 video=HDMI-A-1:1680x1050M@60 dma.dmachans=0x71f5 bcm2709.boardrev=0xc03111 bcm2709.serial=0xf2c24e9c bcm2709.uart_clock=48000000 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:27:F5:46 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  console=ttyAMA0,115200 root=PARTUUID=2e18c40c-02 init=/gokrazy/init elevator=deadline rootwait panic=10 panic_on_oops=1
[    0.000000] Kernel parameter elevator= does not have any effect anymore.

Michael Stapelberg · Answer 14 · Sun Jun 21 2020 13:46:57 GMT+0800 (China Standard Time)

Ah it does recover! The ntp service never writes a message with the correct date (maybe it should the first time it updates the time?), but hello world does!

ntp now logs a message since gokrazy/gokrazy@546057a

Have you noticed the Kernel parameter elevator= does not have any effect anymore. warning?

Thanks, removed in gokrazy/kernel@a472ddd