Currently, ramfs.go uses log for errors and does not return them ex:

if config.Go == "" { log.Fatalf("Can't find a go binary! Is GOROOT set correctly?") }

when I use cp - r I get error: flag provided but not defined: -r

similar to rm errors

Disclaimer

At least on my machine (386), the ramfs.go now really take a good time to get into a u-root shell, about minutes. The debug mode has a lot of information, but is really annoying use this for anything instead debug.

Idea

How about create a -v option to put on stdout few information about what u-root are doing on ramfs.go? Is really scary don't know what he's doing on the normal mode. I think we don't need do too much, like a progressbar of compiling. Just print the sections of procedures to get into the ramfs would be good... searching libs,local variables, compiling source, preparing chroot and etc.

A minimal verbose mode. What you do think, guys?

Important for tcz command

When sort is not yet compiled by installcommand, the output is:

% sort --help
Usage of sort:
  -ludicrous
    	print out ALL the output from the go build commands
  -v	print all build commands
wait: exit status 2:

The expect output is:

% sort --help
Usage of sort:
  -o string
    	Output file
  -r	Reverse
wait: exit status 2:

The flag.Parse() statement in installcommand exits early. Instead, if installcommand is accessed through symlink, we want to proceed as normal and pass --help into the compiled command.

cmds/mv/*.go currently uses path instead of filepath. It needs to be changed.

ps command does not show appropriate output when I run ps aux (without a flag)

We have a /init already. We could describe dependencies in JSON files, have it compute the dependencies, and execute commands.

wget_test.go depends on being able to connect to "http://example.com". If example.com is down or the tests are run offline, it results in a false negative.

Preferably, you would test wget by running a mini webserver on an occupied port in a separate goroutine. Access the webserver via 127.0.0.1. Only then will the test pass rain or shine.

The current build failure is a result of this flakyness: https://travis-ci.org/u-root/u-root/builds/194928679

The script to start sshd included by tinycore openssh relies on an id command. Since other packages may rely on this command as well, we should implement it.

We need a kexec implementation in Go.

At the moment, some of our tests with coverage are reported as 0% (ex: sort_test.go and uniq_test.go). The problem results from executing a process within the test via "go run" or "go build". The coverage tools aren't smart enough to descend into the child processes to count their coverage. Additionally, the child processes are not built with the proper instrumentation.

While a bit dated, the post here gives some useful background on the issue: https://blog.golang.org/cover

Things I've tried so far:

• Executing the test within the test to create a subprocess. This technique is used by some tests in the go standard library. Unfortunately, the coverage array is not copied to the parent process.
• Use the Go cover tool when building the child process's binary. Unfortunately, the coverage array is not copied to the parent process.

The only way I see of fixing this is using a function call rather than spawning a child process.

Relevant research:

• http://stackoverflow.com/questions/40615641/testing-os-exit-scenarios-in-go-with-coverage-information-coveralls-io-goverall
• https://talks.golang.org/2014/testing.slide
• https://www.elastic.co/blog/code-coverage-for-your-golang-system-tests

Some tests doesn't needs building to test. The proposal of this issue is rewrite the tests with these conditions, like:

• uniq_test.go
• wc_test.go
• freq_test.go (without tests at repo yet)
• grep_test.go

https://github.com/u-root/u-root/blob/master/scripts/ramfs.go#L478

Not sure about it. Trying it with and without Cgo.

As per @rminnich:

• I wanted to serve files over http

• I ran srvfiles with the following arguments: srvfiles -d .. -h ananyajoshi

• I then ran wget with the following arguments and nothing happened: wget http://localhost:8080/cat/cat.go

• I should have seen the file downloaded over http from srvfiles

What it should do, given a package name, e.g. /5.x/x86/tcz/vim, is stat
/tcz/5.x/x86/tcz/vim

and if it is there, not fetch it.

There's a problem with what to do about conflicting packages from different architectures, but one problem at a time.

They need to be looked at by someone with a fresh perspective and any errors fixed.

Many cases are not covered by rm_tests including - deleting empty directories - deleting files you do not have permission to and -deleting files that do not exist

Now we are working on utilities that get ipv4 or ipv6 address with dhcp. But do we need to add utilities so that we are able to flush out the address we add?

This is a big job but we really need it.

Travis build is currently failing on the master branch: https://travis-ci.org/u-root/u-root/builds/196068822 . The cause is printenv_test.go.

The test works on my machine, but by taking a closer look, it is susceptible to a problem:

• Environment variables containing a newline:

    export UHOH=$'ha\nha'
    go test
  

  This is guaranteed to fail the test.

This may not be the cause of the test failure under Travis, but is my best hunch.

Things to fix:

• Verbose output in Travis
• To ensure consistency, the test should unset all unwanted environment variables.
• Using newlines as a separator is part of a much larger problem.

for both NiChrome and just in general.

Hi, I was trying to run the RUN_ME_FIRST file but I got these errors.

This is the output
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 318 0 0 0 0 0 0 --:--:-- 0:00:06 --:--:-- 0 100 4682 100 4682 0 0 450 0 0:00:10 0:00:10 --:--:-- 2428 2016/06/07 23:41:45 Using /usr/local/go from the environment as the GOROOT 2016/06/07 23:42:23 Go get failed: err exit status 1, output [103 111 32 105 110 115 116 97 108 108 32 114 117 110 116 105 109 101 47 105 110 116 101 114 110 97 108 47 115 121 115 58 32 111 112 101 110 32 47 117 115 114 47 108 111 99 97 108 47 103 111 47 112 107 103 47 108 105 110 117 120 95 97 109 100 54 52 47 114 117 110 116 105 109 101 47 105 110 116 101 114 110 97 108 47 115 121 115 46 97 58 32 112 101 114 109 105 115 115 105 111 110 32 100 101 110 105 101 100 10] 2016/06/07 23:44:33 Go get failed: err exit status 1, output [103 111 32 105 110 115 116 97 108 108 32 114 117 110 116 105 109 101 47 105 110 116 101 114 110 97 108 47 115 121 115 58 32 111 112 101 110 32 47 117 115 114 47 108 111 99 97 108 47 103 111 47 112 107 103 47 108 105 110 117 120 95 97 109 100 54 52 47 114 117 110 116 105 109 101 47 105 110 116 101 114 110 97 108 47 115 121 115 46 97 58 32 112 101 114 109 105 115 115 105 111 110 32 100 101 110 105 101 100 10]

Can you guide me to solve this?

Thanks.

See summary. A cursory look at init-tools source indicates that it may be enough to just wrap SYS_INIT_MODULE and SYS_DELETE_MODULE. lsmod should only need to look at /proc/modules.

Joining u-root.slack.com indicates one must have a Princeton or MIT email address. Can this be opened?

Sometimes when process disappears at the middle of operations in walking and reading stats, we got that weird error:

2016/03/09 19:53:37 /proc/7020: lstat /proc/7020: no such file or directory
--- FAIL: TestPsExecution (0.01s)
    ps_test.go:18: Loading Table fails on some point; lstat /proc/7020: no such file or directory
FAIL
FAIL    github.com/u-root/u-root/cmds/ps    0.008s

The most probable functions whose may be the guilty of this are:

• ProcessTable.readStats
• ProcessTable.LoadTable

You have to split up flags ex: ls -l -R, not ls -lR

We don't want to add too many features, but people want command completion. We don't want to recreate bash, however.

I wanted to remove multiple files

I ran rm -r to remove all files in a directory and got the following error: flag provided but not defined: -r
Usage: rm [-Rrvi] file...:
wait:exit status 2
NOTE: this is going to fail right now

TCZ will fail when two packages try to make the same link. This should not fail, but be ignored.

We need just this to enable our website and get visible.

mv website docs

And activate gh-pages by:

I think we can create a more friendly documentation on README.md too.

1. An error is not thrown if there is an error in lexical parsing
2. Multiple whitespaces between the arguments are not condensed
3. A space in a filename is counted as two different files

We should include a feature of TCZ or a command that will mount all the existing TCZ packages.

This would prevent us from having to individually tcz each package by name between each power on. Adding this functionality would make the time from boot to running packages much quicker. Furthermore, it would be a useful feature to include in a future library of init scripts.

Now the DHCPv6 client just handles the first DHCPv6 packet it gets after it sends out a request. even if there are multiple DHCPv6 servers in the same network. It is okay if both servers reply with a valid IPv6 address.

However, if one server does not have available address for the client whereas the other has, and the former one replies faster than latter, the client will miss the DHCPv6 address that is assigned to it.

I don't know how possible such scenario happens in real world. If so then perhaps we have to fix it right away.

A possible solution would be: keep client in the loop until it receives a DHCPv6 reply that has a valid IPv6 address, or time runs out.

the scripts/ and bb/ directories are historical. To fit Go guidelines, we need a
cmd/bb
cmd/ramfs
cmd/whatever

directory layout, so that go get builds the commands when we do a go get.

Doing this right is a little tricky and you want to do it one command at a time, not all commands at once. Consider starting with making scripts/ramfs.go be cmd/ramfs/ramfs.go instead.

dhclient waits 300 seconds to hear back if the packet is received

If no interfaces match the re it needs to print a message and quit. As it is it panics.

Right now, the rm command does not have a force flag. This could come in handy when you may not have permissions needed to remove a file without prompting.

1. It downloads tcz packages that already exist
2. It will mount on top of older versions
3. It does not create tcloop directories correctly
   • It spltis on "." instead of removing ".tcz" from the command names
   • This causes packages to be mounted in the same place i.e. "Xorg-7.7.tcz" and "Xorg-7.7-bin.tcz" both mount to "Xorg-7"
4. It needs a debug flag "-d" to enable/disable print statements

2016/10/16 12:44:57 exit status 1
2016/10/16 12:44:57 External cpio is done
2016/10/16 12:44:57 Done all cpio operations
2016/10/16 12:44:57 Creating initramf file
2016/10/16 12:44:57 Run &{/usr/bin/sudo [sudo cpio -H newc -o -A -F /tmp/initramfs.linux_386.cpio] [] /tmp/u-root247321542 0x1862c748 0x185260e0 0x185260e8 [] <nil> <nil> <nil> <nil> <nil> false [] [] [] [] <nil> <nil>} @ /tmp/u-root247321542
2016/10/16 12:44:57 Finished sending file list for initramfs cpio
sudo: cpio: command not found
2016/10/16 12:44:57 exit status 1
2016/10/16 12:44:57 cpio for initramfs is done
2016/10/16 12:44:57 Run &{/usr/bin/sudo [sudo cpio -i] [] /tmp/u-root247321542 0x1862c870 0x185260e0 0x185260e8 [] <nil> <nil> <nil> <nil> <nil> false [] [] [] [] <nil> <nil>} @ /tmp/u-root247321542
sudo: cpio: command not found
2016/10/16 12:44:57 exit status 1
exit status 1

I got this after execute go run scripts/ramfs.go -test -d. Maybe we need put cpio as dependency on docs?

I got tipped off by this comment: https://www.reddit.com/r/golang/comments/476pae/how_to_speed_up_go_compiler_and_many_other_go/

The idea is to run the compiler's garbage collector less frequently because we know the compiler is alive for only a few seconds and all the piled-up memory can be quickly freed at the end.

I tested it out on the busybox (with go1.7.4):

~/go/src/github.com/u-root/u-root/bb$ /usr/bin/time -p go run *.go
real 3.88s
user 7.95s
sys 0.81s
maxresident 95088KiB

~/go/src/github.com/u-root/u-root/bb$ GOGC=2000 /usr/bin/time -p go run *.go
real 3.29s
user 4.29s
sys 0.66s
maxresident 151800KiB

By setting this flag, bb can be compiled 15% faster, but at the cost of 56712KiB of memory (60% increase). Testing various individual commands shows an increase of 10%-30%.

I propose it is reasonable to increase the value of GOGC passed into go build by installcommand. The environment variable affects the compilation time and not the compiled binary. When the environment variable is not set, its value defaults to 100. Any concerns?

Side note: I've already started implementing a Go version of time, so we can measure the value within the ramfs.

I've been using the wrong one for 6 years now. I have no idea why there are two. But filepath has been in there since 2009 at least, so it's my mistake.

Currently there is no "switch_root" command that allows u-root to switch from the RAM file system to another device.

Hey @rminnich, what do you think about this one? I think a code review system like gerrit is very nice, but BarKeep seems is more pragmatic.

I put it in as zaolin ran out of time. It would be nice if someone could pick it up.

What we'd like is an easy to use qemu setup. You'll need to find a good place to get a kernel (remember, this test should work on OSX, so using /boot/whatever is not fair!). The steps would be something like

1. go run script/initramfs.go for the architecture you want to test on
2. get a kernel for that architecture that has network, and graphics
3. run qemu-xx-yy with the right arguments

This script should be written in Go, not bash, zsh, or whatever.