On 2023-08-30 19:19:25 +0200, Jakub Skokan wrote:
Thanks for the feedback!
On 8/30/23 18:45, wolf wrote:
On 2023-08-30 17:00:07 +0200, Jakub Skokan wrote: [...] Comments regarding the "known issues" section:
guix system reconfigure requires –allow-downgrades, why? Something is fishy with the channels.
Guix after fresh install is a bit funny sometimes. If one runs `guix pull' before trying the reconfigure, the --allow-downgrades is no longer necessary.
That didn't work for me. I ran guix pull and system reconfigure from the same shell, but system reconfigure still used some older commit. No idea why.
Hm, maybe you did not run `hash guix'?
Actually I re-created the VPS on staging, and, from fresh deploy, this is sufficient to run the reconfigure without --allow-downgrades:
ssh root@37.205.14.33 -t '. /etc/profile; guix pull; hash guix; guix system reconfigure --no-bootloader /etc/config/system.scm'
I wanted to put it here, maybe it will be of use to someone.
I was able to workaround it with:
guix describe -f channels > /etc/guix/channels.scm guix system reconfigure [...] rm -f /etc/guix/channels.scm guix pull
...since then it works, but it doesn't make sense to me.
If it worked for you out of the box, I guess I'm fine with it x)
I did however run into different issue:
/ssh:root@37.205.14.33:/etc/config $ guix system reconfigure --no-bootloader system.scm The following derivation will be built: /gnu/store/fb4i299scqpgczwgphjmh85k0z0qgmwc-grub.cfg.drv building /gnu/store/fb4i299scqpgczwgphjmh85k0z0qgmwc-grub.cfg.drv... /gnu/store/255b46p2w1b06shnh4wjfz2fzs7r3p8h-system /gnu/store/9nlha7hybazc09bqgrxplq5w480r02pp-grub.cfg activating system... making '/gnu/store/255b46p2w1b06shnh4wjfz2fzs7r3p8h-system' the current system... setting up setuid programs in '/run/setuid-programs'... populating /etc from /gnu/store/xz25p33mwywcwv4xnpg2jkr39hci71hg-etc... shepherd: Starting service host-name... shepherd: Service host-name started. shepherd: Service host-name running with value #<unspecified>. shepherd: Service host-name has been started. shepherd: Starting service user-homes... shepherd: Service user-homes has been started. shepherd: Starting service sysctl... shepherd: Service sysctl could not be started. shepherd: Starting service vpsadminos-networking... guix system: warning: exception caught while executing 'start' on service 'vpsadminos-networking': Throw to key `%exception' with args `("#<&invoke-error program: \"/gnu/store/m6c5hgqg569mbcjjbp8l8m7q82ascpdl-bash-5.1.16/bin/bash\" arguments: (\"/ifcfg.add\") exit-status: 2 term-signal: #f stop-signal: #f>")'. guix system: warning: some services could not be upgraded hint: To allow changes to all the system services to take effect, you will need to reboot.There is /ifcfg.del, however (@ (vpsadminos) vpsadminos-networking) does not use it as #:stop, and even if it did, I do not think that (#:one-shot?) services do invoke #:stop. I will send a patch for this in due time (turning the service into "sleep inf", so that #:stop will start to work).
I'd prefer if we could e.g. prevent the service from being restarted. Or make the script idempotent, so that it wouldn't fail. It makes no sense to bring down the network just because bash in shebang was updated. While /ifcfg.del exists, there's no real reason to call it, ever.
There is #:transient?, but I do not know how well/if it interacts with #:one-shot and system reconfiguration. The script being idempotent is the correct solution, you are right.
halt (graceful shutdown) has been observed to sometimes hang, please report in case it's still a problem.
This is sadly sometimes problem on actual physical machines as well, so it might not be an issue with the template itself. Just FYI.
This part was pretty annoying. Unlike other init systems, shepherd does not accept signals to properly shutdown. All it can do is respond to SIGINT by restarting itself. There's no way to halt using a signal, e.g. SIGPWR. So we invoke halt from inside the VPS, but even that is sometimes problematic as you say.
cgroups v1 are not mounted. cgroups do not seem to be needed by the base system, contact us in case it's a problem for some service or submit a patch to the template.
The only high-profile package that explicitly depends on the cgroup v1 is currently docker afaik, which in a world where podman exists is not that important. I plan to try to produce a patch moving guix to v2, which should solve this issue.
The available cgroup version depends on the host. So far we have cgroups v1 everywhere, migration to v2 is planned:
https://kb.vpsfree.org/manuals/vps/cgroups
Guix works with cgroups v2, I use it on my dev machine.
You mean in foreign mode or in the GuixSD setup? I did not figure out easy built-in way to switch GuixSD to v2, so if there is one, I would love to know.
Jakub
PS: Please do not CC: news list, it is only for annoucements.
Sorry about that, I am used to reply-all on mailing lists, and did not notice that news were CCed.
Community-list mailing list -- community-list@lists.vpsfree.cz To unsubscribe send an email to community-list-leave@lists.vpsfree.cz