Thanks Tobias. It worked for the python issue but I came back to the error which I had in the first place a few days ago. After building guix (?) it run some tests. It fails at tests/store.scm. I cannot find any logs anywhere, I asked about that on the #guix few days ago and noone could help. There are 61 tests, 2 are skipped and 1 is failed. It prints message to see ./test-suite.log but this file doesn’t exist. Actually one of the logs asks me to report a bug on the mailing list. ;) All I did was killing the process (Ctrl-C) after seeing the well known “killing process / no such process” message after running the following command: # guix system init /mnt/etc/config.scm /mnt Then I re-run the system init with fallback flag: # guix system init /mnt/etc/config.scm /mnt —fallback As I wrote - it helped for the python issue and proceed further. After failed test I tried to run again the first command (without —fallback) to download guix rather than building it from the source, however it didn’t helped. Maybe there is some cache which tells guix “hey - I have the source files and I already build the project, maybe we should build it again rather than download anything?” - no idea... I cannot copy-paste the log so please see few screenshots on imgur. http://imgur.com/a/5fsQG Thanks once again. dptd > On 19 Mar 2016, at 15:37, Tobias Geerinckx-Rice wrote: > > Hallo, > > On 19/03/2016, dptdescribe wrote: >> We all know that hydra is being overloaded all the time. The guix system >> init process is failing on random packages due to the network issues. I am >> rerunning the command every time. However something strange happens at >> python package. Every time after downloading 15.3M the process is being >> killed but is it? > > It's not you, it's Hydra. > > I got the same error (also consistently at 15.3M) yesterday. I suspect > an incompletely cached file in the front end, but that's just a guess. > Maybe someone else knows. > > The good news: adding a ‘--fallback’ switch to build Python locally > should do the trick. It did here. Just be prepared to wait a while on > a slower VM. > > Kind regards, > > T G-R