https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# rancher-desktop
a
This message was deleted.
f
It is very well possible that this is the same issue. If that is the case, then the workaround would be to switch to using QEMU for now.
m
although there is the idea that qemu may be affected as well
f
Rancher Desktop 1.12.0 will use Lima 0.19, but is still being tested. Hopefully it will be released in early January
m
is it possible to test an early version of limia 0.19.1 with RD?
while i have qemu 8.2.0 RC4 running as alternative, the qemu-user-static setup is much slower than rosetta of course
Hopefully it will be released in early January
I look forward to that again if you like me to stress test the VM part ... 馃檪
f
m
I do not have qemu facts for real .. just saw people talking about it
f
You can test the latest CI builds from https://github.com/rancher-sandbox/rancher-desktop/actions/runs/7254120924 if you want to give them a try.
They are not signed/notarized, but are the builds we are using in release testing right now.
m
that uses 0.19.0 or 0.19.1 of lima?
f
Keep in mind that we do still see problems with those builds, which is why we didn't release them yet... (sometimes the guestagent doesn't start in a timely manner when Rancher Desktop needs to restart the VM)
m
probably better than disk corruption
f
It includes Lima 0.19.0 plus one commit adding logging for the guestagent
I think this is related to guest agent communication having switched from ssh to virtio (QEMU) or vsock (VZ) in Lima 0.19, but we don't know yet
m
while I "have you", when is cgroups V2 coming?
f
Because it looks like the guest agent is running; it is just that the host agent cannot connect
I can't say anything about cgroup v2 right now. We did make some changes, so buildkit should be working fine, as should k3d. The only remaining issue I'm aware of is 
kind
m
right
kind is the reason why I am asking ... 馃檪
f
I know some people use 
kind
via 
helm-kind
in CI, but for local usage 
k3d
should provide all the same functionality already
m
(I am tempted to do some CI pipelines using kind for quick tests and am not able to test that locally)
f
I would like to figure out the 
kind
problem, but honestly don't know when we will get time to pick it up again
m
that is ok
much less important at this time
(although cgroup V2 is important for our db product)
f
I notice that nobody seems to be running 
kind
on OpenRC systems; they all use 
systemd
. Which makes it harder to figure out, as we are on our own on this.
And hybrid mode doesn't work for your DB?
m
anyhow .. is there a workaround for the current vsock problem with agent communication? restarting RD and look if it works?
f
Yes, restarting seems to fix it. And I'm not sure if it happens with VZ, at least I don't have any log files for this with VZ, but only from QEMU.
m
I can run and report on both
f
And the error only happens during a backend restart, not during normal operations
Ok, thanks! Please let me know if the disk corruption is gone. I really hope it is, but otherwise we would need a Github issue with exact repro instructions
m
yes, we would need a repro, I understand
as you do not support pre GA builds ... would my RD instance be a throw away or do you believe I could eventually update that to the GA RD release?
I will give it a try (I have rsync (& time machine) backups)
(yes I use rsync -avS to not impact the sparseness)
f
I think you will be able to continue your VM with 1.12. But if you go back to 1.11.* then you need to do a factory-reset in between because we don't support downgrading the VM
m
sure
(so rsyncing would not suffice I guess)
f
We have the snapshot feature now. If you take a snapshot with the older version, you should be able to restore to it. And snapshots are not deleted by a factory-reset
m
I will start to (attempt) use that but rsync is an old friend
f
Also snapshots (on macOS) use 
clonefile
, so multiple incremental snapshots from the same VM take up little space (it is just copy-on-write)
Sorry, meetings now...
m
(I am in process to restore (and verify) the pre-corrupt state ... and will then do a snapshot)
thanks so much for the attention and answers, bye for now
f
Looks like there are reports of disk corruption with QEMU as well 馃槥 Disk corruption on ARM64 (Apple Silicon) Linux VMs (#1997) 路 Issues 路 QEMU / QEMU 路 GitLab
m
the first smoke test of RD 
1.11.1-496-g2f3e101e
did not corrupt the filesystem.
Open in Slack
PreviousNext
Powered by