The manual is quite clear that LVM support is missing:
https://guix.gnu.org/manual/en/html_node/Limitations.html
This held me back from using guix as the OS for my virtualization
servers since I use LVM for virtual machines. However, one evening I
was curious how difficult it would be to fix t
Marius Bakke writes:
> Simon Josefsson writes:
>
>> The manual is quite clear that LVM support is missing:
>>
>> https://guix.gnu.org/manual/en/html_node/Limitations.html
>>
>> This held me back from using guix as the OS for my virtualization
>> se
Michael Rohleder writes:
> Hey Simon!
>
> Simon Josefsson writes:
>> I'm thinking that having the root file system on LVM may be unsupported,
>> so that manual could say that, but I'm not even sure that is true. I
>> haven't tried it though. Per
Christopher Lemmer Webber writes:
> I'm very excited to see the MNT Reform launch:
>
> https://www.crowdsupply.com/mnt/reform
> https://www.crowdsupply.com/mnt/reform/updates/the-campaign-is-live
>
> Completely hackable laptop; all the designs (that are possible) are
> libre, and you can even
Thank you for unattended-upgrades! Something like it has been my main
concern preventing deploying Guix on Internet-facing production
machines.
After using it for a while two things strikes me as useful improvements:
1) Automatically restarting all services.
I manually specified mcron, ntpd and
Hi. I have a machine that have been running Guix for a couple of years
and since November I rely on unattended-upgrades to keep it updated. I
have stopped doing manual upgrades but may have done it on reflex a
couple of times since November. Now when I run 'guix pull' the errors
below are shown.
Hi. I have a machine that have been running Guix for a couple of years
and since November I rely on unattended-upgrades to keep it updated. I
have stopped doing manual upgrades but may have done it on reflex a
couple of times since November. Now when I run 'guix pull' the errors
below are shown.
Simon Josefsson via writes:
> Hi. I have a machine that have been running Guix for a couple of years
> and since November I rely on unattended-upgrades to keep it updated. I
> have stopped doing manual upgrades but may have done it on reflex a
> couple of times since November. No
Andreas Enge writes:
>> I am still curious what happened before, in case the previous error
>> appears again.
>
> Other people have experienced the same problem; apparently it was a bug
> that has been fixed in the meantime. So as "guix pull" finally succeeded,
> you should not see it again.
Oka
Hi! Since some time, 'guix reconfigure' on my machine fails:
building /gnu/store/chilbs792mqssmi726zmvff5zg49gija-provenance.drv...
building /gnu/store/9skvgwsl0vxccv5sbgvqimkhk3938v8y-rsnapshot-1.4.4.drv...
\ 'check' phasebuilder for
`/gnu/store/9skvgwsl0vxccv5sbgvqimkhk3938v8y-rsnapshot-1.4.4.
br...@waegenei.re writes:
> First we go back to our failing build² and have a look in its log⁷. At the
> end of it there is 2 failing tests t/backup_exec/backup_exec.t and
> t/cmd-post_pre-exec/cmd-post_pre-exec.t. That's what we need to repair or
> disable. Now we need to build it locally and ins
Hi. Reconfiguring my machine lately fails with:
root@hamster ~# guix system reconfigure /etc/config.scm
guix system: error: glibc-utf8-locales: unknown package
guix system: error: failed to load '/etc/config.scm':
srfi/srfi-1.scm:586:17: In procedure map1:
Throw to key `quit' with args `(1)'.
roo
tis 2022-03-08 klockan 10:28 + skrev Tobias Geerinckx-Rice:
> Hullo Simon,
>
> Simon Josefsson via wrote:
> > First, I wonder if this is optimal. There must be many machines
> > (servers and embedded) where having all locales installed on is
> > wasteful, but whe
.git/config
and re-running both commands made it work, but this feels a bit unsafe.
5) The implementation seems confused by PGP subkeys. Verifying the
initial commit after adding .guix-authenticate works fine:
jas@kaka:~/src/libntlm$ git log -1 -p
commit 2e6e8027c75942450a0e4ae0f58e876715782cae (HE
Simon Josefsson via writes:
> jas@kaka:~/src/libntlm$ guix git authenticate
> guix git: successfully authenticated commit
> a94c085b17dd72904d8913411e1e85477e12
> jas@kaka:~/src/libntlm$ git commit -m"maint: Mention guix git introductory
> commit." README.md
All,
I am trying to get a Guix container usable in GitLab, and thought I'd
share my status. I have established working networking in the resulting
Guix container, which seems like progress (whoohoo!). tl;dr:
https://gitlab.com/debdistutils/guix/container/-/jobs/8652014833
The problem seems to
Ludovic Courtès writes:
>> What is really weird is this root directory:
>>
>> Using docker image
>> sha256:57160f1c13ce56799d6e3e83dd97da4c929993ac008404ac38c67317cded25d1
>> for registry.gitlab.com/debdistutils/guix/container:pack with digest
>> registry.gitlab.com/debdistutils/guix/container@sh
Andreas Enge writes:
> Hello Simon,
>
> Am Mon, Dec 16, 2024 at 11:42:34AM +0100 schrieb Simon Josefsson via:
>> I am trying to get a Guix container usable in GitLab, and thought I'd
>> share my status. I have established working networking in the resulting
>>
I am happy to announce Guix container images:
https://gitlab.com/debdistutils/guix/container/
They are suitable for use in GitLab pipelines.
There are many things to continue discuss and resolve. However it is
now possible to start a GitLab pipeline job that uses an 'image:'
pointing to a conta
Ludovic Courtès writes:
>> - guix package -i fails: `guix perform-download: error: refusing to
>> run with elevated privileges (UID 0)`
>
> Should be fixed by running guix-daemon with
> “--build-users-group=whatever” so that downloads run as one of the build
> users, not as root.
Yes, I discov
All,
Here are some updates about Guix container images for GitLab pipelines
or local podman usage. I'm declaring this v1.0.
tl;dr: https://gitlab.com/debdistutils/guix/container
Final images are built from a pure Guix container now. Everything is
done on public shared GitLab runners in the pip
I believe the GitLab CI entrypoint behaviour boils down to OCI
configuration, compare Debian's image:
skopeo inspect --config docker://debian:12
...
"config": {
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Cmd": [
Simon Josefsson via writes:
> I didn't test now but I think Debian images handle all three entrypoint
> values, but the 'guix pack' image doesn't.
That was not true! Here the situation:
https://gitlab.com/debdistutils/guix/container/-/pipelines/1600726433
Debian
Simon Josefsson via writes:
>>> Re /etc=etc it seems GitLab's docker setup bind-mounts things below
>>> /etc/ and it cannot handle the root /etc symlink. A workaround is to
>>> use `lndir` which I use in the `test-amd64-package-install` job. This
>>>
Kay Plößer writes:
> To try things out, I installed the ISO image to a local VM, which
> worked. However, the SSH server didn't start after boot, despite being
> selected in the installation and ending up in the config.scm. I got it
> running after updating the config and starting the server man
Gary Johnson writes:
> $ guix shell -CN iproute2 -- ip route add 12.34.56.78 dev wls6
> RTNETLINK answers: Operation not permitted
What I think would be useful is a way to give a container certain Linux
capabilities. I think this is a missing feature, and one that I suspect
may be the "righ
Gary Johnson writes:
> This is the reason that /etc in the Guix shell container is polluted
> with the iproute2 package's config files. The error that I originally
> reported is happening because /etc/iproute2/group is being placed in
> /etc/group, thus conflicting with the real /etc/group file t
27 matches
Mail list logo
