Guix System on a GCE VM -- Success

[elaexuotee]

Attached is a minimal system configuration I have used to successfully
create a virtual machine instance on Google's Compute Engine (GCE).

The stock QEMU image [1] fails to boot under GCE, and since there is some past
interest [0], I figure it may be helpful to share the salient issues and how I
deal with them in the config.scm.

The boot problem fix boils down to this:

(initrd-modules (cons "virtio_scsi" %base-initrd-modules))

Referencing Google's documentation on operating system requirements [2], we see
that their VMs run with Virtio-SCSI controllers; however, it just so happens
that the corresponding kernel module, virtio_scsi, is not included in the
initrd by default. Would it make sense to change this default?

That should be enough to get a working GCE instance running, provided you
follow Google's requirements for importing custom images [3]. It's not
challenging, but it takes time to familiarize oneself with GCE and the
associated toolchain.

To simplify the process I created a script capable of setting up a GCE instance
from a local qcow2 image, which I am also attaching. The script is intentially
not a simple turnkey solution, since you should be somewhat familiar with the
GCE infrastructure before using it. However, feel free to ask questions if
anything is unclear.

Returning back to config.scm, the only other non-obvious pieces deal with the
bootloader setup. On GCE at boot time, our only choice of interface is a serial
console, so the following set that up in case it becomes necessary:


  (bootloader (bootloader-configuration
...
(serial-speed 115200)
(terminal-outputs '(serial))
(terminal-inputs '(serial

  (kernel-arguments '("console=ttyS0,115200"))

We set the baud rate to 115200 instead of the default 9600, for two reasons.
One it is essential that grub.cfg get populated with the following:

serial [options]
terminal_output serial
terminal_input serial

and for some reason, bootloader-configuration seems to elide these lines
without serial-speed set to something other than 9600. Secondly, baud 115200
ends up providing a better shell experience anyway.

Finally, the attached config.scm sets a bootloader timeout of 0:

  (bootloader (bootloader-configuration
...
(timeout 0)))

Since the vm is completely headless during normal bootup, anything else just
slows down boot times.


Finally, GCE allows community supported images [4]. If there is enough
interest, it might make sense to invest the few cents per month to maintain a
Guix System one. Thoughts?

Hopefully, the above is clear. I am happy to answer any questions.


[0]:https://lists.gnu.org/archive/html/guix-devel/2017-01/msg01815.html
[1]:https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.0.1.x86_64-linux.xz
[2]:https://cloud.google.com/compute/docs/images/building-custom-os
[3]:https://cloud.google.com/compute/docs/import/import-existing-image
[4]:https://cloud.google.com/compute/docs/images#community_supported_images

(use-modules (gnu))
(use-service-modules networking ssh)

(operating-system
  (host-name "guixsd")
  (timezone "Europe/Berlin")
  (locale "en_US.utf8")

  (bootloader (bootloader-configuration
(bootloader grub-bootloader)
(target "/dev/sda")
(theme (grub-theme))
(timeout 0)
(serial-speed 115200)
(terminal-outputs '(serial))
(terminal-inputs '(serial

  (kernel-arguments '("console=ttyS0,115200"))
  (initrd-modules (cons "virtio_scsi" %base-initrd-modules))

  (file-systems (cons (file-system
(device (uuid "b6a32092-b004-43ba-bab7-e4c8d5480026"))
(mount-point "/")
(type "ext4"))
  %base-file-systems))

  (users (cons (user-account
 (name "guest")
 (group "users")
 (supplementary-groups '("wheel")))
   %base-user-accounts))

  (services (append (list (service dhcp-client-service-type)
  (service openssh-service-type))
%base-services)))
#!/usr/bin/env sh
set -o errexit -o noclobber -o nounset

## GCE Custom Image
#
# This script intends to be "executable documention" for the process of setting
# up a Google Compute Engine (GCE) virtual machine from a custom image.


usage() {
cat <<-USAGE
Usage: $(basename "${0}") [options]  [ [..]]

This script aids in setting up Google Compute Engine with an instance
running a custom image.

Execute commands in order provided at the command line. The procedure
for a fresh setup follows the order listed below in Status Commands.

Setup Commands:
  mkconf  Configure files on raw image partition
  mkraw   Convert image to raw format
  

Re: Packaging Jami "progress"

[Jan]

Just tested Jami on core-updates and no magic happened, the bug is
still there.
I'm out of ideas. I'm going to upload my work somewhere tomorrow.
Someone really needs to help me with this, I'm not experienced enough
to handle this kind of bugs myself.


Jan Wielkiewicz

Re: Packaging Jami "progress"

[Leo Famulari]

On Wed, Apr 08, 2020 at 01:52:14AM +0200, Jan wrote:
> If it succeeds, I will need a way to copy contents of the store on my
> powerful machine to my potato machine. Is "guix copy" the tool I can
> use? 

Yup! You'll need to authorize the building machine's key on the potato.

https://guix.gnu.org/manual/en/html_node/Invoking-guix-copy.html

Re: Packaging Jami "progress"

[Jan]

On Wed, 08 Apr 2020 01:06:14 +0200
Marius Bakke  wrote:

> A git merge will merge all the commits, some of which are bound to
> cause conflicts.  I will try to resolve those tomorrow.
> 
> In the mean time, you should be able to "cherry-pick" your patches
> instead.  Something along the lines of:
> 
> $ git checkout core-updates
> $ git cherry-pick master..wip-jami
> 
> Does that work?

I'm currently hacking it together using "git format-patch" and "git
am" and it seems to work. I'll compile Jami and check if the bug is
present.
Will remember about this cherry-pick thing, because resolving failing
patches wasn't fun, thanks.

If it succeeds, I will need a way to copy contents of the store on my
powerful machine to my potato machine. Is "guix copy" the tool I can
use? 


Jan Wielkiewicz

Re: Syntax errors in latest guix-manual ru.po

[Julien Lepiller]

Le 7 avril 2020 16:17:49 GMT-04:00, "Ludovic Courtès"  a écrit :
>Hi,
>
>Pavlo Marianov  skribis:
>
>>> doc/contributing.ru.texi:365: @url missing closing brace
>
>This one is:
>
>  CI-системой @url{@value{SUBSTITUTE-SERVER}.
>   ^
>Julien, do we need to do anything for the non-existent node names or is
>there “something” that’ll take care of it?  (Somehow I can never
>remember how that works.)
>
>Ludo’.

You translate the menu and @node. You don't need to translate references like 
@ref, @xref or @pxref. The xref_command takes care of that (guix self) uses its 
own parser too. For references outside the guix manual, I use the English name 
too because they were not translated. It's ok to translate URLs to point to 
translated resources.

Re: Packaging Jami "progress"

[Marius Bakke]

Jan  writes:

> I get several merge conflicts when merging wip-jami into core updates.
> The wip-jami is based on the current master, rebased a minute ago.
> Is there a way to avoid this without pain?

A git merge will merge all the commits, some of which are bound to cause
conflicts.  I will try to resolve those tomorrow.

In the mean time, you should be able to "cherry-pick" your patches
instead.  Something along the lines of:

$ git checkout core-updates
$ git cherry-pick master..wip-jami

Does that work?


signature.asc
Description: PGP signature

Re: Packaging Jami "progress"

[Jan]

I get several merge conflicts when merging wip-jami into core updates.
The wip-jami is based on the current master, rebased a minute ago.
Is there a way to avoid this without pain?


Jan Wielkiewicz

RE: good practices in science

[bijan ghavami-kia]

Oh my goodness, I didn’t know who Danny Hillis was before a google search..., 
except I did because the way I heard about this project first was from him!
https://www.youtube.com/watch?v=YmF7KvsldGU
A good salesman! I’m embarrassed I brought it up!
It’s an interesting prospect, shouldn’t we be working towards this fantastical 
goal?


From: Konrad Hinsen
Sent: 07 April 2020 09:40
To: Bengt Richter
Cc: guix-devel@gnu.org
Subject: Re: good practices in science

Hi Bengt,

> (I guess I get excited reading prose that shows attention
> to the distinction between abstractions and their representations.
> Sort of like reading quotes from Plato, and thinking, "Hey, wow,
> I've had some of those thoughts." :)

There are plenty of good ideas in that project, I am not claiming the
opposite. Unfortunately, that has never been a guarantee for success.

> I hope they are not just preparing themselves for spinning off
> and becoming rich as a monopolist takeover target ;-/

With people like Danny Hillis on board, they should be aware of that
trap!

> So what makes you hopeful about guix? :)

It's so technical that politics-minded people won't even look at it.

Cheers,
  Konrad.

Re: Unencrypted boot with encrypted root

[Ludovic Courtès]

Ellen Papsch  skribis:

> Does it have to go through the store? I imagine key generation would be
> done by the installer, not guix system init.

Sure, but what happens when you reconfigure?  You still need to have
that file around so it can be added to the initrd.

Ludo’.

Re: Syntax errors in latest guix-manual ru.po

[Ludovic Courtès]

Hi,

Pavlo Marianov  skribis:

>> doc/contributing.ru.texi:365: @url missing closing brace

This one is:

  CI-системой @url{@value{SUBSTITUTE-SERVER}.
   ^
Julien, do we need to do anything for the non-existent node names or is
there “something” that’ll take care of it?  (Somehow I can never
remember how that works.)

Ludo’.

Re: Proxy settings wrt guix daemon

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

> Press  to access installation parameters.
>
> This is the installer parameters menu, please make a choice.

Maybe just: “Please choose one of the follow parameters or press ‘Back’
to go back to the installation process.”

>   * Change keyboard layout
>   * Configure network proxy
>   ...

BTW, if we agree, could you change these strings so we can do a last
round through the TP and release Thursday/Friday?

Ludo’.

Re: Proxy settings wrt guix daemon

[Ludovic Courtès]

Mathieu Othacehe  skribis:

> Another issue could be that, to make sure that we are connected to the
> internet, we check connman status (see connman-state in (gnu installer
> connman)) during the install.
>
> If there's a network HTTP proxy, I guess this may fail. So we would need
> to also call "connmanctl proxy auto PROXY_URL" or something alike.

Hmm OK.

> Is there someone here that is behind a HTTP proxy and could test that?

One could test with Privoxy as the proxy.  Do people know of other easy
to set up proxy software?

Ludo’.

Re: Proxy settings wrt guix daemon

[Ludovic Courtès]

Hello,

Mathieu Othacehe  skribis:

>> I went ahead and pushed it as 3302e03ba0edca49347c6a2b215e56bd53a6b113.
>> Another 2017 bug closed!  \o/
>
> Well done!
>
>>
>> Ideally, the installer would have a dialog box to select a proxy.
>> Do we want to do that?  Or leave it for the next release?
>
> Yes I could do that. I wonder what's the best place for such a dialog
> box, because I suspect the vast majority of people is not concerned by
> network proxy settings.
>
> Maybe from the new help menu? But then the "help" term is maybe not the
> best fit. We could make it a "parameter" menu, this way:
>
> Press  to access installation parameters.

Yes, “parameters” seems better suited than “help” in any case.

> This is the installer parameters menu, please make a choice.
>
>   * Change keyboard layout
>   * Configure network proxy
>   ...
>
> WDYT?

Sounds good!

Thanks,
Ludo’.

Re: good practices in science

[Bengt Richter]

Hi Konrad,

> > So what makes you hopeful about guix? :)
> 
> It's so technical that politics-minded people won't even look at it.

LOL :))

-- 
Regards,
Bengt Richter

Re: Proxy settings wrt guix daemon

[Mathieu Othacehe]

Another issue could be that, to make sure that we are connected to the
internet, we check connman status (see connman-state in (gnu installer
connman)) during the install.

If there's a network HTTP proxy, I guess this may fail. So we would need
to also call "connmanctl proxy auto PROXY_URL" or something alike.

Is there someone here that is behind a HTTP proxy and could test that?

Thanks,

Mathieu

Re: Unencrypted boot with encrypted root

[Vagrant Cascadian]

On 2020-04-07, Alex Griffin wrote:
> On Tue, Apr 7, 2020, at 9:46 AM, Ludovic Courtès wrote:
>> The difficulty is that any file traveling through the store is
>> world-readable.  It’s hard to avoid.
>
> If we can create the key file outside of the store, then GRUB is capable of 
> being passed multiple initrds. So we can put the key in its own initrd 
> (outside of the store), continue to generate the normal initrd in /gnu/store, 
> and pass both of them to GRUB. The key never enters the store in any way.
>
> The result is that the user only needs to enter a password into GRUB, because 
> GRUB then passes the key file to the kernel.

I believe it's also possible for grub to provide the key
derived/decrypted from the passphrase entered at run-time, obviating the
need for a separate key entirely. I don't have details on how to do
this, but I *think* that's what recent Debian installs do... it
certainly would simplify key slot management issues.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Proxy settings wrt guix daemon

[Mathieu Othacehe]

Hey,

> I went ahead and pushed it as 3302e03ba0edca49347c6a2b215e56bd53a6b113.
> Another 2017 bug closed!  \o/

Well done!

>
> Ideally, the installer would have a dialog box to select a proxy.
> Do we want to do that?  Or leave it for the next release?

Yes I could do that. I wonder what's the best place for such a dialog
box, because I suspect the vast majority of people is not concerned by
network proxy settings.

Maybe from the new help menu? But then the "help" term is maybe not the
best fit. We could make it a "parameter" menu, this way:

--8<---cut here---start->8---
Press  to access installation parameters.

This is the installer parameters menu, please make a choice.

  * Change keyboard layout
  * Configure network proxy
  ...
--8<---cut here---end--->8---

WDYT?

Mathieu

Re: Unencrypted boot with encrypted root

[Alex Griffin]

On Tue, Apr 7, 2020, at 9:46 AM, Ludovic Courtès wrote:
> The difficulty is that any file traveling through the store is
> world-readable.  It’s hard to avoid.

If we can create the key file outside of the store, then GRUB is capable of 
being passed multiple initrds. So we can put the key in its own initrd (outside 
of the store), continue to generate the normal initrd in /gnu/store, and pass 
both of them to GRUB. The key never enters the store in any way.

The result is that the user only needs to enter a password into GRUB, because 
GRUB then passes the key file to the kernel.

-- 
Alex Griffin

Re: Syntax errors in latest guix-manual ru.po

[Julien Lepiller]

Le 7 avril 2020 06:03:18 GMT-04:00, Pavlo Marianov  a écrit :
>Looks like errors like 'reference to nonexistent node' will remain
>until all text will be translated.
>
>Other errors I could not find in the source PO-file. Maybe coordinates
>are
>wrong. For example reference 'guix.texi:946' is missing in the
>https://translationproject.org/PO-files/ru/guix-manual-1.1.0-pre1.ru.po
>
>вт, 7 квіт. 2020 о 12:44 Ludovic Courtès  пише:
>
>> Hi Pavlo,
>>
>> Pavlo Marianov  skribis:
>>
>> > I uploaded a new PO-file.
>> > Hope it fixes that error.
>>
>> Thanks for the quick reply!  There’s a few issues left:
>>
>> --8<---cut here---start->8---
>> ./doc/guix.ru.texi:946: warning: accent command `@,' must not be
>followed
>> by whitespace
>> doc/contributing.ru.texi:365: @url missing closing brace
>> Wide character in warn at /home/ludo/.guix-profile/bin/makeinfo line
>632.
>> ./doc/guix.ru.texi:28262: @pxref reference to nonexistent node
>`Системы
>> сборки)'
>> Wide character in warn at /home/ludo/.guix-profile/bin/makeinfo line
>632.
>> doc/contributing.ru.texi:105: @xref reference to nonexistent node
>`Запуск
>> guix environment'
>> Wide character in warn at /home/ludo/.guix-profile/bin/makeinfo line
>632.
>> doc/contributing.ru.texi:915: @pxref reference to nonexistent node
>> `Отправка набора патчей'
>> make[2]: *** [Makefile:4236: doc/guix.ru.info] Error 1
>> --8<---cut here---end--->8---
>>
>> Does that make sense to you?
>>
>> Thanks,
>> Ludo’.
>>

During my translation I also found it was difficult to keep nodes in sync. 
That's why I added some code to the Makefile so that it will automatically 
translate node names in the file. Translate nodes, but keep references to them 
in English. The makefile will find your translation and automatically replace 
@ref etc.

Re: Unencrypted boot with encrypted root

[Ellen Papsch]

Hi,

Am Dienstag, den 07.04.2020, 11:46 +0200 schrieb Ludovic Courtès:
> Hi,
> 
> Ellen Papsch  skribis:
> 
> > Am Samstag, den 04.04.2020, 12:18 +0200 schrieb pelzflorian
> > (Florian
> > Pelz):
> > > Could key files help in passing the passphrase on to the
> > > Linux kernel?  The Arch Wiki says this: [...]
> > > 
> > 
> > If the installer would support an external medium for the file,
> > that would be best (IMHO).
> 
> The difficulty is that any file traveling through the store is
> world-readable.  It’s hard to avoid.
> 

Does it have to go through the store? I imagine key generation would be
done by the installer, not guix system init. That would be much in the
same way that the installer creates partitions, while system init (or
reconfigure) doesn't touch partitions, only uses existing references.
In that sense, the installer would create the file from /dev/random or
urandom and place the reference in operating-system.

It would also allow manual installations to retain flexibility
configuring encryption.

Best regards

Re: Feedback guix-hurd-20200401.img with qemu

[Hubert Lombard]

Le Tue, 07 Apr 2020 11:50:09 +0200,
Ludovic Courtès  a écrit :

Hi Ludo!

> Hi Hubert,
> 
> Hubert Lombard  skribis:
> 
> > root@guix-system:~# guix describe
> > Generation 413 31 2020 16:53:54(current)
> >   guix ef4b5f2
> > repository URL: https://git.savannah.gnu.org/git/guix.git
> > branch: master system! guix-system console
> > commit: ef4b5f2f
> >
> > root@guix-system:~# guix install linux-libre
> >
> > (It has worked too)  
> 
> I hope you paid attention to the output of that command.  :-)
> 
> Ludo’.

Sorry, I wanted to give a feedback too fastly!

Here:
root@guix-system:~# guix install linux-libre
The following package will be installed:
linux-libre

substitute: updating substitutes from 'https://ci-guix.gnu.org'... 100.0%
0,2 MB will be downloaded:
 /gnu/store/g70bhgkpr78i98iniiar4yw171f2h445-wishful-thinking

...
Help us achieve this dream!
We are really close to having a Guix System using the Hurd.
Join the discussion on IRC #guix on freenode.net and on the guix-devel@gnu.org
mailing list!

HTH

Hubert

Re: Proxy settings wrt guix daemon

[Ludovic Courtès]

Hello,

Ludovic Courtès  skribis:

> That’s roughly what I had in mind.  I had to give it a go to see if it
> made sense :-) and I came up with this patch.

I went ahead and pushed it as 3302e03ba0edca49347c6a2b215e56bd53a6b113.
Another 2017 bug closed!  \o/

Ideally, the installer would have a dialog box to select a proxy.
Do we want to do that?  Or leave it for the next release?

Thanks,
Ludo’.

Re: Proxy settings wrt guix daemon

[Vincent Legoll]

Hello,

On Tue, Apr 7, 2020 at 11:39 AM Ludovic Courtès  wrote:
> Vincent Legoll  skribis:
>
> > I'm not sure I understand, but isn't the setenv in
> > shepherd-set-http-proxy-action done for the whole
> > running shepherd process ?
>
> It is, but only temporarily: the environment is restored once
> ‘guix-daemon’ has been started.
>
> Also, since Shepherd 0.7.0, processes started by ‘fork+exec-command’ &
> co. do not inherit environment variables of PID 1.

OK, thanks, LGTM then

-- 
Vincent Legoll

Re: Syntax errors in latest guix-manual ru.po

[Pavlo Marianov]

Looks like errors like 'reference to nonexistent node' will remain
until all text will be translated.

Other errors I could not find in the source PO-file. Maybe coordinates are
wrong. For example reference 'guix.texi:946' is missing in the
https://translationproject.org/PO-files/ru/guix-manual-1.1.0-pre1.ru.po

вт, 7 квіт. 2020 о 12:44 Ludovic Courtès  пише:

> Hi Pavlo,
>
> Pavlo Marianov  skribis:
>
> > I uploaded a new PO-file.
> > Hope it fixes that error.
>
> Thanks for the quick reply!  There’s a few issues left:
>
> --8<---cut here---start->8---
> ./doc/guix.ru.texi:946: warning: accent command `@,' must not be followed
> by whitespace
> doc/contributing.ru.texi:365: @url missing closing brace
> Wide character in warn at /home/ludo/.guix-profile/bin/makeinfo line 632.
> ./doc/guix.ru.texi:28262: @pxref reference to nonexistent node `Системы
> сборки)'
> Wide character in warn at /home/ludo/.guix-profile/bin/makeinfo line 632.
> doc/contributing.ru.texi:105: @xref reference to nonexistent node `Запуск
> guix environment'
> Wide character in warn at /home/ludo/.guix-profile/bin/makeinfo line 632.
> doc/contributing.ru.texi:915: @pxref reference to nonexistent node
> `Отправка набора патчей'
> make[2]: *** [Makefile:4236: doc/guix.ru.info] Error 1
> --8<---cut here---end--->8---
>
> Does that make sense to you?
>
> Thanks,
> Ludo’.
>

Re: Feedback guix-hurd-20200401.img with qemu

[Ludovic Courtès]

Hi Hubert,

Hubert Lombard  skribis:

> root@guix-system:~# guix describe
> Generation 413 31 2020 16:53:54(current)
>   guix ef4b5f2
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master system! guix-system console
> commit: ef4b5f2f
>
> root@guix-system:~# guix install linux-libre
>
> (It has worked too)

I hope you paid attention to the output of that command.  :-)

Ludo’.

Re: Unencrypted boot with encrypted root

[Ludovic Courtès]

Hi,

Ellen Papsch  skribis:

> Am Samstag, den 04.04.2020, 12:18 +0200 schrieb pelzflorian (Florian
> Pelz):
>> Could key files help in passing the passphrase on to the
>> Linux kernel?  The Arch Wiki says this: [...]
>> 
>
> The key file would be another means of decrypting the master key, if I
> understand LUKS correctly. It would be independent of the passphrase.
> (In LUKS terminology, two slots are used).
>
> It would definitely help usability not having to enter a passphrase
> twice. The GUI/TUI installer should take care generating the file and
> ensuring strict permissions, so user processes cannot read it. There is
> still some risk, because root processes could read it. If the installer
> would support an external medium for the file, that would be best
> (IMHO).

The difficulty is that any file traveling through the store is
world-readable.  It’s hard to avoid.

Ludo’.

Re: Syntax errors in latest guix-manual ru.po

[Ludovic Courtès]

Hi Pavlo,

Pavlo Marianov  skribis:

> I uploaded a new PO-file.
> Hope it fixes that error.

Thanks for the quick reply!  There’s a few issues left:

--8<---cut here---start->8---
./doc/guix.ru.texi:946: warning: accent command `@,' must not be followed by 
whitespace
doc/contributing.ru.texi:365: @url missing closing brace
Wide character in warn at /home/ludo/.guix-profile/bin/makeinfo line 632.
./doc/guix.ru.texi:28262: @pxref reference to nonexistent node `Системы сборки)'
Wide character in warn at /home/ludo/.guix-profile/bin/makeinfo line 632.
doc/contributing.ru.texi:105: @xref reference to nonexistent node `Запуск guix 
environment'
Wide character in warn at /home/ludo/.guix-profile/bin/makeinfo line 632.
doc/contributing.ru.texi:915: @pxref reference to nonexistent node `Отправка 
набора патчей'
make[2]: *** [Makefile:4236: doc/guix.ru.info] Error 1
--8<---cut here---end--->8---

Does that make sense to you?

Thanks,
Ludo’.

Re: Proxy settings wrt guix daemon

[Ludovic Courtès]

Hi Vincent,

Vincent Legoll  skribis:

> I'm not sure I understand, but isn't the setenv in
> shepherd-set-http-proxy-action done for the whole
> running shepherd process ?

It is, but only temporarily: the environment is restored once
‘guix-daemon’ has been started.

Also, since Shepherd 0.7.0, processes started by ‘fork+exec-command’ &
co. do not inherit environment variables of PID 1.

Thanks,
Ludo’.

Re: 01/02: services: Allow modprobe to use "/etc/modprobe.d".

[Ludovic Courtès]

Hi,

Brice Waegeneire  skribis:

> On 2020-04-05 21:15, Ludovic Courtès wrote:
>> guix-comm...@gnu.org skribis:
>>>#~(begin
>>>(setenv "LINUX_MODULE_DIRECTORY"
>>>"/run/booted-system/kernel/lib/modules")
>>> +  ;; FIXME: Remove this crutch when the patch
>>> #40422,
>>> +  ;; updating to kmod 27 is merged.
>>> +  (setenv "MODPROBE_OPTIONS"
>>> +  "-C /etc/modprobe.d")
>>
>> [...]
>>
>>> +  (services (cons* (service kernel-module-loader-service-type
>>> +'("ddcci" "ddcci_backlight"))
>>> +   (simple-service 'ddcci-config etc-service-type
>>> +   (list `("modprobe.d/ddcci.conf"
>>> +   ,ddcci-config)))
>>> +   %base-services))
>>
>> Looking at this, I was wondering if it would be possible to not use
>> /etc/modprobe.d and instead have a way to tell the modprobe wrapper to
>> pass “-C /gnu/store/…-modprobe.d”, which would contain the right thing.
>>
>> Thoughts?
>
> What's the issue with using /etc/modrpobe.d?

In general, use of the global file system name space isn’t great: it’s
ambiguous (compare to a /gnu/store reference) and doesn’t work well upon
rollback or reconfigure (things that refer to /etc end up referring to
the “new” /etc after reconfigure, even though that might not actually
work.)

Conversely, “-C /gnu/store/…-modprobe.d” unambiguously refers to the
intended directory.

WDYT?

> As noted in the comments I thought setting MODPROBE_OPTIONS was kinda
> of a
> hack; #40422[0] was there to fix it. But if you think it's appropriate
> to
> use this environment variable it can be done in a future
> “kernel-module-configuration-service-type” we discussed with Danny[1].

Sure, no problem!

> Instead of extending “etc-service-type” we would use
> “activation-service-type”, as “%modprobe-wrapper” is currently put
> in place by a simple activation service.

Makes sense.

Thank you,
Ludo’.

Re: [Help] Adding file-system utils packages to system profile

[Brice Waegeneire]

On 2020-04-06 17:07, Brice Waegeneire wrote:
I tried implementing this in the attached patch but I'm currently stuck 
and
need some help. I've probably overlooked something basic but I can;t 
put a

finger on it... Guix compile successfully with the patch and testing
“file-system-utils” in “guix repl” returns a list of packages as 
expected.

But when I try building a system/vm the packages aren't added to the
system's profile as I expected. From what I understand, that function 
as

used in “file-system-service-type” should get as arguments the list of
file-systems defined in the operating-system and should return a list 
of

packages, themselves appended to the system's profile list of packages.


It turns out “file-system-service-type” doesn't get *all* the 
file-systems,

just the one not need for boot.

With this issue fixed I have submitted it as patch #40480[0].

[0]: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=40480

- Brice

Re: good practices in science

[Konrad Hinsen]

Hi Bengt,

> (I guess I get excited reading prose that shows attention
> to the distinction between abstractions and their representations.
> Sort of like reading quotes from Plato, and thinking, "Hey, wow,
> I've had some of those thoughts." :)

There are plenty of good ideas in that project, I am not claiming the
opposite. Unfortunately, that has never been a guarantee for success.

> I hope they are not just preparing themselves for spinning off
> and becoming rich as a monopolist takeover target ;-/

With people like Danny Hillis on board, they should be aware of that
trap!

> So what makes you hopeful about guix? :)

It's so technical that politics-minded people won't even look at it.

Cheers,
  Konrad.