anethema

EDIT: Pinning to the 1.5.1 tag made it stop happening so it is definitely an issue in the latest update. Mine stopped working. invokeai just seems to do some reinstall loop then the container stops. Any idea? (I've made no other changes. My config is here: And here is the last log before the container stops:

Hey just looked at the issue and it appears that someone did make a few basic changes and got it working with the GPU. https://github.com/serge-chat/serge/issues/43#issuecomment-1792070396 Any idea if it would be possible for you to add that into your template etc to make it work ?

Ya the host access option makes no difference in my setup. It has been off for me from day 1 and if I put the unifi controller or pihole on a br0 to get their own ip, I lock up within 12-24 hours.

I'm running 6.9.2 now. Let's see if it freezes.

Awesome I also still cannot run docker containers on br0 either. It will start causing macvlan errors in syslog and eventually kernel panic. The problem also followed me from my R510 to my R720 if that helps at all.

Well just reporting back that mounting as rclone works MUCH better. Restores at full speed. The checking files and anything folder related is pretty slow, but the transfer itself is fast. So it seems like its a problem with cloudberry itself, in their B2 implementation.

I'm not holding out hope for it to be much faster, as just the repository sync is on track to take two full days. I will see about the restore once the sync is done, but it really does seem like something is broken with cloudberry itself. Maybe some setting or something, but it DOES transfer for me, just horribly slowly, and I've now verified on the unraid machine itself that it works very quickly in unraid itself.

I'm actually trying another route now. I have my B2 bucket mounted as a folder in unraid using rclone. I can copy files out of the FUSE folder at full line speed of my network, so it is def not backblaze being slow. The folder structure is just synchronizing now in cloudberry so we will see how a restore works with that.

Maybe but it is taking like 5mins to download a 100kb .png file. It really seems to be just going very slow.

It does not even create a VM for me. I get this from the helper script after I got the notification it was ready: It does not create any VM for me. EDIT: Removing the entire macinabox appdata, app, and the /mnt/user/system/custom_ovmf folder fixed this for me.

My server also crashing. The same nf_conntrack_core.c macvlan errors. It will usually handle a couple of them then kernel panic. I will try disabling all custom IPs, but is it really expected that we cannot set a static IP or the server will crash every 4-6 hours? This bug continues for my in 6.9RC2. Not sure how having the containers on a separate VLAN will help since I set them as a static IP because they need to be accessible to my normal network (unifi controller, pihole, etc)

I'm having absolutely abysmal speeds using cloudberry to pull from B2. Tried a download of files from the backblaze website myself and it goes full line speed of my internet. 2kb/s Anyone have any idea why this would be happening? Lost my plex folder but it will be a long long time restoring at this pace heh.

Just wondering if the steamcache is using an odd region? I am only getting 3-4MB/sec rather than the normal 16 on the first download(to SSD). My Steam is set to Canada - Edmonton on the downloading machine. When I download for the first time through the steamcache i get: 10.3.3.171 / - - - [14/Nov/2019:15:25:49 -0700] "GET /depot/583952/chunk/6fe88c8bc485c906703424d6dc8be0f20168823b HTTP/1.1" 200 103152 "-" "Valve/Steam HTTP Client 1.0" "MISS" "cache1-sea1.steamcontent.com" "-" So using a seattle server rather than the one I have set in steam?

My filebot has also long ago stopped scanning for folder changes. Is there any way to fix this?

I tried installing it with no luck. The following error happened: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='telegraf' --net='host' --privileged=true -e TZ="America/Phoenix" -e HOST_OS="Unraid" -e 'HOST_PROC'='/rootfs/proc/' -e 'HOST_SYS'='/rootfs/sys/' -e 'HOST_ETC'='/rootfs/etc/' -e 'HOST_MOUNT_PREFIX'='/rootfs/' -v '/var/run/utmp':'/var/run/utmp':'ro' -v '/var/run/docker.sock':'/var/run/docker.sock':'ro' -v '/':'/rootfs':'ro' -v '/sys/':'/rootfs/sys':'ro' -v '/etc/':'/rootfs/etc':'ro' -v '/proc/':'/rootfs/proc':'ro' -v '/mnt/user/appdata/telegraf/telegraf.conf/':'/etc/telegraf/telegraf.conf':'rw' -v '/mnt/user/appdata/':'/appdata/':'rw' 'telegraf:alpine' e61de4249ea43e396f7c28f26e28a357977118ad2e80763cafd8763d9fce51fd /usr/bin/docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "process_linux.go:402: container init caused "rootfs_linux.go:58: mounting \"/mnt/user/appdata/telegraf/telegraf.conf\" to rootfs \"/var/lib/docker/btrfs/subvolumes/bc257a35e85fcd9052cd8506e712ca66b6e3ef3c1d9a0eea3132ca5537ad630a\" at \"/var/lib/docker/btrfs/subvolumes/bc257a35e85fcd9052cd8506e712ca66b6e3ef3c1d9a0eea3132ca5537ad630a/etc/telegraf/telegraf.conf\" caused \"not a directory\""": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type. The command failed. Any idea? EDIT: Ah, the default container config looks like it tries to map to /etc/telegraf.conf instead of /etc/telegraf. Fixed it.