Unik daemon failed to initialize on Ubuntu 18.04 #191
Comments
|
Hi, |
|
I tried again today and it seemed to work? I got output like this I guess it's because I also did some restarts during the last few days. |
|
The same problem happened again... Rebooting doesn't work any more. The problem disappeared after a system update. But after a reboot, the problem came back. I tried to update virtualbox to 6.0.8. Didn't help. |
|
Also for me the problem came back, so I had another look and saw the answer was already in the logs: I only had one free loop device left, after I added another one, it worked again. |
|
[LOOP ISSUE] All the methods for overcoming this seem to not work for me. I think part of my problem is that I am trying to do this in a GUI based Ubuntu 18.04 image that has several snap based applications installed. Snap consumes loop devices so the generally free loop devices aren't free or are free depending on the vagaries of installed app usage. Here is losetup -a If they is a free loop device, found by running losetup -f there may not be second free loop devices as mentioned above. Things I have attempted to do and that have so far not offered any relief are:
[NEXT ISSUE] Now I am stuck at: I think the issue is here but i don't know what to do. Any ideas? See there is a /dev/loop19, a /dev/loop19p1 and a /dev/loop191 (because of the fix above) but the code on in unik So, maybe the problem is you can't have more then 100 loop device? What i did next was to bring the max_loop down to 100 in grub and to uninstall unik and reinstall it from github. Yes it needs two free loop devices. In my case these were loop19, loop20. Part of my problem might be that I tried targeting xen instead of virtualbox first and never got that working so switched to virtualbox this might have hosed some configuration. I'm tempted to push loop max to 255 and to try it again. |
|
Same issue on Ubuntu 19.10, mkfs failed. Increasing loop devices does not help. Not familiar with what the code here is doing, but in my logs before the error all work with loop7 and it suddenly tries to mkfs on loop71. What's going on? |
|
Your loop7 and loop71 is very similar to my loop19 to loop191 problem. The reinstall of Unik from github, for me, was the ticket. I think the code is, at some point, appending a string “1” instead of incrementing the loop device. For some reason the reinstall fixed that problem. Not sure why? |
|
Ok, I have the same loops issue. Ubuntu 18.04. provider AWS, trying to build python3 httpd example. So I've listened to @schnorea advice, changed Nevertheless this is kind of annoying bug :< I also looked into cited file and there is indeed added + "1" but it doesn't seem like a real problem since earlier code looks like this: so rootDeviceName is in the end something like "/dev/unik-tmp/hda1" or maybe I just do not understand what this piece of code does. Link to mentioned file: https://github.com/solo-io/unik/blob/master/pkg/os/volumes.go |
|
I keep bashing my head against this one. I tried the max_loop=100 above, but of course it should be max_loop=255 because at some stage it's trying to make loop 171. Something worth pointing out and is likely part of the story around loopback device numbering is that snaps use loopbacks themselves. |
|
I have the same problem using Ubuntu 20.04 (and VirtualBox 6.1.6 if that's important). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I tried to run Unik daemon following the tutorial here, but the command
unik daemon --debugfailed with exit status 1 and the following output. Can anybody help me figure out the problems? Thank you.OS: Ubuntu 18.04
VirtualBox: 5.2.18
The content of the daemon-config.yaml file is:
The text was updated successfully, but these errors were encountered: