What is the correct way to update VS Code? It seems it’s currently out of date. Is the OS supposed to auto update it in upcoming reboots? Let me know if there is some documentation to understand this better because I couldn’t find any info.
If you’re on latest it’ll be the day after, gts (the default) built last night and stable will build tomorrow night.
What image are you on? I can kick off a new build if it hasn’t pulled in yet. Basically it’ll hit the weekly builds after it’s out.
I’ve always hated this delay when we switched to weekly builds, but perhaps we can just rebuild gts/stable on the spot since vscode is usually monthly releases. Filed here: Kick off a build if vscode releases upstream · Issue #1657 · ublue-os/bluefin · GitHub
1 Like
I think I am on gts. Is there a way to check? Sorry I try to search the docs for stuff first but am very new to the OS. It’s super cool btw, I just wish there was more documentation so i could understand better, like why vs code is there but its also a flatpak option, etc 
Super random too, I am wondering how to enable ollama to run at startup, because the AI docs are outdated, since the webui command has changed, I figured that out.
The problem is that systemctl restart --user ollama works perfectly, but enable does not:
systemctl enable --user ollama
Failed to enable unit: Unit /run/user/1000/systemd/generator/ollama.service is transient or generated.
However the AI docs page says if you can run restart, enable is supposed to work? Thanks for the quick reply
The vscode is there because it’s part of the image so we can bundle the right extensions, etc. If MS ever publishes an official flatpak we may switch to that.
I haven’t kept track of the ollama changes, if the docs are out of date please file an issue or send a PR, thanks!
We’ll need to comb over our docs for Ollama. Quadlets leverage generated systemd units. We template one out for Ollama in our ujust recipe. Generated units can not be directly enabled with systemctl; they are triggered by other events. In the case of Ollama, it’s set as being required by the multi-user target. At that point, we trigger the service
I removed the logic for starting the service after install as I noticed they were instantly triggered after we perform a daemon reload anyway: fix(bluefin-tools): Don't explicitly start ollama after creating service by EyeCantCU · Pull Request #1659 · ublue-os/bluefin · GitHub
No further intervention should be required. It should trigger every time it hits that target like other Quadlets
If you notice any abnormal behavior, please let us know and we can get it sorted out
Thanks for the info. I’ll check it out more tomorrow but my only issue is that I can’t get ollama to start on boot. So I’m manually starting the service each time which would be nice to work around. I’m a systemd noob too.