Install `guix pull'ed Guix to target partition on system install

Install `guix pull'ed Guix to target partition on system install

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

Hi!

I just installed Guix System on a new machine:

- guix pull -C my-channels.scm
- guix system init ... /mnt 
- reboot

Now on my fresh system, the only Guix available is the one from the USB
stick, namely 1.2, and not the one from my channels.  So the first thing
I've got to do on reboot it rerun

--8<---------------cut here---------------start------------->8---
guix pull -C my-channels.scm
--8<---------------cut here---------------end--------------->8---

It seems to be a waste of time and resources.

Is there a way to get the `guix pull'ed Guix installed on the system
straight away?

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Install `guix pull'ed Guix to target partition on system install

[zimoun]

Hi Pierre,

On Sun, 20 Dec 2020 at 10:12, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> I just installed Guix System on a new machine:
>
> - guix pull -C my-channels.scm
> - guix system init ... /mnt 
> - reboot

This is done as root, right?

>
> Now on my fresh system, the only Guix available is the one from the USB
> stick, namely 1.2, and not the one from my channels.  So the first thing
> I've got to do on reboot it rerun
>
> --8<---------------cut here---------------start------------->8---
> guix pull -C my-channels.scm
> --8<---------------cut here---------------end--------------->8---

This is done as user, right?  Even maybe for all the users?


All the best,
simon

Re: Install `guix pull'ed Guix to target partition on system install

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

zimoun <zimon.toutoune@gmail.com> writes:

> On Sun, 20 Dec 2020 at 10:12, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
>
>> I just installed Guix System on a new machine:
>>
>> - guix pull -C my-channels.scm
>> - guix system init ... /mnt 
>> - reboot
>
> This is done as root, right?

Yes, since the install media has no other user.

>> Now on my fresh system, the only Guix available is the one from the USB
>> stick, namely 1.2, and not the one from my channels.  So the first thing
>> I've got to do on reboot it rerun
>>
>> --8<---------------cut here---------------start------------->8---
>> guix pull -C my-channels.scm
>> --8<---------------cut here---------------end--------------->8---
>
> This is done as user, right?  Even maybe for all the users?

As user, indeed.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Install `guix pull'ed Guix to target partition on system install

[zimoun]

Hi,

On Mon, 21 Dec 2020 at 13:26, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

>> This is done as root, right?
>
> Yes, since the install media has no other user.

[...]

>>> I've got to do on reboot it rerun
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> guix pull -C my-channels.scm
>>> --8<---------------cut here---------------end--------------->8---
>>
>> This is done as user, right?  Even maybe for all the users?
>
> As user, indeed.

Therefore, since the 2 profiles could be seen as independent, I do not
know if it is possible to really improve here; by design.

The first pull could be long and resource hungry but the second one
should be a bit quicker.  Well, it depends on how many commits are done
in the meantime (between the 2 pulls).


All the best,
simon

Re: Install `guix pull'ed Guix to target partition on system install

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

zimoun <zimon.toutoune@gmail.com> writes:

> Therefore, since the 2 profiles could be seen as independent, I do not
> know if it is possible to really improve here; by design.
>
> The first pull could be long and resource hungry but the second one
> should be a bit quicker.  Well, it depends on how many commits are done
> in the meantime (between the 2 pulls).

Maybe there is a misunderstanding: the first pull happens on the
installation media, thus it disappears when I reboot on the installed
system.

What I think we should do is that when we run `guix system init`, we
would copy the checkout to the store, and then when `guix pull` is run
the first time on the newly installed system, it would get the git repo
from the store and optionally fetch the remaining git commits if there
is any.

Thoughts?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Install `guix pull'ed Guix to target partition on system install

[zimoun]

On Mon, 21 Dec 2020 at 14:33, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
> zimoun <zimon.toutoune@gmail.com> writes:
>
>> Therefore, since the 2 profiles could be seen as independent, I do not
>> know if it is possible to really improve here; by design.
>>
>> The first pull could be long and resource hungry but the second one
>> should be a bit quicker.  Well, it depends on how many commits are done
>> in the meantime (between the 2 pulls).
>
> Maybe there is a misunderstanding: the first pull happens on the
> installation media, thus it disappears when I reboot on the installed
> system.

I am not familiar with the installation process.  I miss where this
first “guix pull” writes:

 - the cached checkout
 - the store items

I am expecting that the first “pull“ writes both on the target.  If not,
i.e., it writes on the installation target, yeah it could be improved. :-)


From your initial message, my understanding was the first pull writes:

 - the cached checkout in /root/.cache/guix/checkouts
 - the store items in /gnu/store

then your second pull writes:

 - the cached checkout in /home/user/.cache/guix/checkouts
 - the store items in /gnu/store

Therefore, the repo is cloned twice and derivations are also computed
twice; but it seems hard to avoid by design.


> What I think we should do is that when we run `guix system init`, we
> would copy the checkout to the store, and then when `guix pull` is run

I do not think the checkout is in the store but in
“/root/.cache/guix/checkouts“, I guess.


Cheers,
simon

Re: Install `guix pull'ed Guix to target partition on system install

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

zimoun <zimon.toutoune@gmail.com> writes:

> On Mon, 21 Dec 2020 at 14:33, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
>> zimoun <zimon.toutoune@gmail.com> writes:
>>
>>> Therefore, since the 2 profiles could be seen as independent, I do not
>>> know if it is possible to really improve here; by design.
>>>
>>> The first pull could be long and resource hungry but the second one
>>> should be a bit quicker.  Well, it depends on how many commits are done
>>> in the meantime (between the 2 pulls).
>>
>> Maybe there is a misunderstanding: the first pull happens on the
>> installation media, thus it disappears when I reboot on the installed
>> system.
>
> I am not familiar with the installation process.  I miss where this
> first “guix pull” writes:
>
>  - the cached checkout
>  - the store items

The first "guix pull" write in memory (RAM), so it's all ephemeral.

> I am expecting that the first “pull“ writes both on the target.

Nope! :(

> If not, i.e., it writes on the installation target, yeah it could be
> improved. :-)

No, the first "guix pull" does not write on the installation target.
But I guess that's what you meant ;)

> From your initial message, my understanding was the first pull writes:
>
>  - the cached checkout in /root/.cache/guix/checkouts
>  - the store items in /gnu/store

Which is in memory.

> then your second pull writes:
>
>  - the cached checkout in /home/user/.cache/guix/checkouts
>  - the store items in /gnu/store

After rebooting, so this /gnu/store is _not the same_ as the one during
installation.

> Therefore, the repo is cloned twice and derivations are also computed
> twice; but it seems hard to avoid by design.

Maybe we could fix this by having a "base Guix clone" in the store, and
then when we run Guix pull, it first checks out this store repo, only to
run "git pull" afterwards.  This would save a lot of time.

>> What I think we should do is that when we run `guix system init`, we
>> would copy the checkout to the store, and then when `guix pull` is run
>
> I do not think the checkout is in the store but in
> “/root/.cache/guix/checkouts“, I guess.

Yes, which is a problem I think.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Install `guix pull'ed Guix to target partition on system install

[zimoun]

Hi,

On Mon, 21 Dec 2020 at 15:47, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

>> I am not familiar with the installation process.  I miss where this
>> first “guix pull” writes:
>>
>>  - the cached checkout
>>  - the store items
>
> The first "guix pull" write in memory (RAM), so it's all ephemeral.
>
>> I am expecting that the first “pull“ writes both on the target.
>
> Nope! :(
>
>> If not, i.e., it writes on the installation target, yeah it could be
>> improved. :-)
>
> No, the first "guix pull" does not write on the installation target.
> But I guess that's what you meant ;)
>
>> From your initial message, my understanding was the first pull writes:
>>
>>  - the cached checkout in /root/.cache/guix/checkouts
>>  - the store items in /gnu/store
>
> Which is in memory.
>
>> then your second pull writes:
>>
>>  - the cached checkout in /home/user/.cache/guix/checkouts
>>  - the store items in /gnu/store
>
> After rebooting, so this /gnu/store is _not the same_ as the one during
> installation.

Therefore, the missing store items from the RAM store could be
transferred to installation target via ‘guix archive’.  But I am
surprised that after rebooting this /gnu/store misses items that you
need when you run “guix pull” as root.

Well, I am missing something on how all the installation process works… :-)


>> Therefore, the repo is cloned twice and derivations are also computed
>> twice; but it seems hard to avoid by design.
>
> Maybe we could fix this by having a "base Guix clone" in the store, and
> then when we run Guix pull, it first checks out this store repo, only to
> run "git pull" afterwards.  This would save a lot of time.

What I miss in your problem is:

  # guix pull # writes in memory (1)
  # guix system init 
  # reboot                       
  # guix pull # writes in disk   (2)
  $ guix pull # writes in disk   (3)

(The steps (2) and (3) are not necessary done chronologically.)


(1) is slow,  (2) should not clone.  Is (2) cloning?

What you are proposing is to improve (3), right?  Instead of cloning
from Savannah and so populate ~/.cache/guix/checkouts, you are proposing
that between (1) and (3), «something» creates a store item with the full
clone from Savannah, then (3) copies from this store item to
~/.cache/guix/checkouts if it does not exist, and run “git pull” there.
But I do not think the “cloning” part is the consuming one here; even if
it obviously depends on the network.

And it is does only once in life. ;-)

Example with a poor network via my smartphone:

--8<---------------cut here---------------start------------->8---
$ time guix pull
Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix      https://git.savannah.gnu.org/git/guix.git	5ecc0b1
Computing Guix derivation for 'x86_64-linux'... -
nothing to be done

real	0m56.022s
user	1m16.139s
sys	0m0.887s

$ rm -fr ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq 
$ time guix pull
Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix      https://git.savannah.gnu.org/git/guix.git	5ecc0b1
Computing Guix derivation for 'x86_64-linux'... -
nothing to be done

hint: After setting `PATH', run `hash guix' to make sure your shell refers to `/home/simon/.config//guix/current/bin/guix'.


real	4m15.202s
user	3m8.522s
sys	0m5.010s
--8<---------------cut here---------------end--------------->8---


All the best,
simon

Re: Install `guix pull'ed Guix to target partition on system install

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 2827 bytes --]

zimoun <zimon.toutoune@gmail.com> writes:

> Therefore, the missing store items from the RAM store could be
> transferred to installation target via ‘guix archive’.

But I don't think `guix pull' looks for a repository in the store.

> But I am
> surprised that after rebooting this /gnu/store misses items that you
> need when you run “guix pull” as root.

This is not surprising: when you run "guix pull" from an installation
media, there is no /gnu/store on the disk since Guix hasn't been
installed to the disk yet.

> What I miss in your problem is:
>
>   # guix pull # writes in memory (1)
>   # guix system init 
>   # reboot                       
>   # guix pull # writes in disk   (2)
>   $ guix pull # writes in disk   (3)

No need for 3.

> (1) is slow,  (2) should not clone.  Is (2) cloning?

1: yes.
2: It would be nice if it could reuse the checkout from 1.

> What you are proposing is to improve (3), right?

No, 2.

> Instead of cloning
> from Savannah and so populate ~/.cache/guix/checkouts, you are proposing
> that between (1) and (3), «something» creates a store item with the full
> clone from Savannah, then (3) copies from this store item to
> ~/.cache/guix/checkouts if it does not exist, and run “git pull”
> there.

Correct but with (2) instead of (3).

> But I do not think the “cloning” part is the consuming one here; even if
> it obviously depends on the network.

On a 6 Mbit/s connection and a modest laptop, this took about 30
minutes!
The Guix checkout is huge.

Maybe a shallow clone could fix this, but since we've added the
introduction commit I don't think it's possible.

> And it is does only once in life. ;-)

Do you mean installation is something done only once?
I beg to differ, I've been using Guix for 2.5 years and already
installed it a dozen of times.

> Example with a poor network via my smartphone:
>
> --8<---------------cut here---------------start------------->8---

> [...]

> $ rm -fr ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq 
> $ time guix pull
> Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
> Building from this channel:
>   guix      https://git.savannah.gnu.org/git/guix.git	5ecc0b1
> Computing Guix derivation for 'x86_64-linux'... -
> nothing to be done
>
> hint: After setting `PATH', run `hash guix' to make sure your shell refers to `/home/simon/.config//guix/current/bin/guix'.
>
>
> real	4m15.202s
> user	3m8.522s
> sys	0m5.010s
> --8<---------------cut here---------------end--------------->8---

I wouldn't call this a poor network ;)
You can go much worse than that, in my case it took around half an hour.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Install `guix pull'ed Guix to target partition on system install

[zimoun]

Hi,

Well, I do not understand what is your issue.  Because I am probably not
enough familiar with the installation process.


On Mon, 21 Dec 2020 at 17:49, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

>> But I do not think the “cloning” part is the consuming one here; even if
>> it obviously depends on the network.
>
> On a 6 Mbit/s connection and a modest laptop, this took about 30
> minutes!
> The Guix checkout is huge.

I should miss something:

--8<---------------cut here---------------start------------->8---
$ cd /tmp/
$ time git clone https://git.savannah.gnu.org/git/guix.git
Cloning into 'guix'...
remote: Counting objects: 417391, done.
remote: Compressing objects: 100% (89208/89208), done.
remote: Total 417391 (delta 327950), reused 416613 (delta 327364)
Receiving objects: 100% (417391/417391), 151.40 MiB | 1.77 MiB/s, done.
Resolving deltas: 100% (327950/327950), done.

real    2m30.963s
user    2m22.166s
sys     0m6.906s

$ du -sh guix
230M    guix
--8<---------------cut here---------------end--------------->8---


> I wouldn't call this a poor network ;)
> You can go much worse than that, in my case it took around half an hour.

I do not know if 1.8Mbits/s is poor or not but it is less than
yours. ;-)


Cheers,
simon

Re: Install `guix pull'ed Guix to target partition on system install

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

zimoun <zimon.toutoune@gmail.com> writes:

> Well, I do not understand what is your issue.  Because I am probably not
> enough familiar with the installation process.

It's actually quite simple: The "guix pull" done when running the
installation media is not persisted on the target disk.

> --8<---------------cut here---------------start------------->8---
> $ cd /tmp/
> $ time git clone https://git.savannah.gnu.org/git/guix.git
> Cloning into 'guix'...
> remote: Counting objects: 417391, done.
> remote: Compressing objects: 100% (89208/89208), done.
> remote: Total 417391 (delta 327950), reused 416613 (delta 327364)
> Receiving objects: 100% (417391/417391), 151.40 MiB | 1.77 MiB/s, done.
> Resolving deltas: 100% (327950/327950), done.
>
> real    2m30.963s
> user    2m22.166s
> sys     0m6.906s
>
> $ du -sh guix
> 230M    guix
> --8<---------------cut here---------------end--------------->8---
>
>
>> I wouldn't call this a poor network ;)
>> You can go much worse than that, in my case it took around half an hour.
>
> I do not know if 1.8Mbits/s is poor or not but it is less than
> yours. ;-)

Maybe there is something else.  Could it be slow hardware?  I'm not
sure, but it took hell of a long time to fetch check out the repository.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Install `guix pull'ed Guix to target partition on system install

[zimoun]

On Mon, 21 Dec 2020 at 18:12, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
> zimoun <zimon.toutoune@gmail.com> writes:
>
>> Well, I do not understand what is your issue.  Because I am probably not
>> enough familiar with the installation process.
>
> It's actually quite simple: The "guix pull" done when running the
> installation media is not persisted on the target disk.

The “guix pull” done by root.  But then you run “guix pull” as user;
your words. :-)

Anyway, the consuming part should not be the cloning but the computing
and building derivations.

As I said, maybe what is done on the installation media could be
transferred to the target installation via “guix archive --export” and
“guix archive --import”, probably via piping.


> Maybe there is something else.  Could it be slow hardware?  I'm not
> sure, but it took hell of a long time to fetch check out the repository.

I do not know what you are doing but in this half an hour, the cloning
part is nothing, or you have a network at 125Kbits/s and not at
6Mbits/s.  Well, by default the repo is 230Mbits or I miss something.
It is not nothing but not huge neither; compared to video streaming for
example.  (I speak for French network infrastructures, because I lived
in place where 125Kbits/s is a dream.)

Maybe your roommates or neighbor are enjoying the connection. ;-)

Or maybe, you had bad luck with Savannah.

Cheers,
simon

Re: Install `guix pull'ed Guix to target partition on system install

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

zimoun <zimon.toutoune@gmail.com> writes:

> The “guix pull” done by root.  But then you run “guix pull” as user;
> your words. :-)

Yes, this is expected.  The installation media has a root user, none of
the users that are going to end up on the installed system.

On a related topic, if 2 users "guix pull", is the whole checkout cloned
twice?
If so, we could optimize this, since it's a significant waste of resources.


-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Install `guix pull'ed Guix to target partition on system install

[zimoun]

Hi Pierre,

On Mon, 21 Dec 2020 at 20:39, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> On a related topic, if 2 users "guix pull", is the whole checkout cloned
> twice?

From my understanding yes, as I explained before.

Well, I have never timed when installing in a WM a complete Guix System
with the installer.  So I did with Xfce selected; it downloads some
pieces, and it took me around 40 minutes with my connection at less than
2Mbits/s, from selecting language to the reboot.  Then I boot the
installed VM image, open a terminal with the regular user and hit “guix
pull”.  The clone part is fast, couple of minutes, but then it downloads
a lot of substitutes and computes derivations.  This first “guix pull”
as regular user takes 20 minutes on my machine, mainly downloading
substitutes.

However, from my understanding, it is unavoidable because I used the
v1.2 image installer, therefore somehow, I fetched all the substitutes
from v1.2, then this first “guix pull” as user fetched the substitutes
corresponding to origin/master.  But you did not do that and instead
did:

        - guix pull -C my-channels.scm
        - guix system init ... /mnt 
        - reboot

Did you use Tor or something?  And what does “guix describe” as root
say?

Note that the first “guix pull” for another user (right after) takes
only 6 minutes, mainly cloning the repo.  Basically, on this first “guix
pull” for another user, the cloning+authenticating takes on my machine
~5 minutes.

This part could be improved but it is done only once, take less than 5
minutes with less than 2Mbits/s, so currently I am not convinced that it
is really the bottleneck when pulling the first time from a release
image.  Well, it is for sure an issue with low-bandwith network but Guix
is hard to use with low-material though and cloning is maybe the fastest
part. ;-)


Cheers,
simon

Re: Install `guix pull'ed Guix to target partition on system install

[Ricardo Wurmus]

zimoun <zimon.toutoune@gmail.com> writes:

> Hi Pierre,
>
> On Mon, 21 Dec 2020 at 20:39, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
>
>> On a related topic, if 2 users "guix pull", is the whole checkout cloned
>> twice?
>
> From my understanding yes, as I explained before.

On multi-user systems it does seem like a good idea to have a central
copy of the git repository and let individual users check out different
commits in their own worktree.

Not sure exactly how this would work and if it’s really worth the
effort, though.

-- 
Ricardo

Re: Install `guix pull'ed Guix to target partition on system install

[zimoun]

Hi Ricardo,

On Tue, 22 Dec 2020 at 13:28, Ricardo Wurmus <rekado@elephly.net> wrote:

> On multi-user systems it does seem like a good idea to have a central
> copy of the git repository and let individual users check out different
> commits in their own worktree.
>
> Not sure exactly how this would work and if it’s really worth the
> effort, though.

The effort saves ~230MiB of download, did once.

And for multi-users context, it often means a sysadmin is around.  So,
the first pull could done with:

   guix pull --url=/home/simon/src/guix

where the path is a shared local repo created by the sysadmin.

Well, it could be imagined that the root repo is under say
/var/guix/checkouts/ and then if ~/.cache/guix/checkouts does not exist,
it tries first to clone from this local repo.

For sure, it is better the planet. ;-)

All the best,
simon

Re: Install `guix pull'ed Guix to target partition on system install

[zimoun]

Hi Pierre,

Re-reading all the thread.

On Sun, 20 Dec 2020 at 10:12, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> I just installed Guix System on a new machine:
>
> - guix pull -C my-channels.scm

Did you really do this “guix pull”?  Because it is…

> - guix system init ... /mnt 
> - reboot
>
> Now on my fresh system, the only Guix available is the one from the USB
> stick, namely 1.2, and not the one from my channels.

…in contradiction with this.  So bug?


It looks as you are doing:

    guix system init … # use guix v1.2

so you download all the substitutes corresponding to this v1.2.  Then
you reboot and log as regular user, run:

    guix pull

This ’guix’ clones the repo and fetches all the substitutes at version
origin/version to be able to run the last ’guix’, i.e., create:

  ~/.config/guix/current


If you really did:

   guix pull
   guix system init …
   reboot
   login as regular user
   guix pull

and it took twice half an hour (for each “guix pull”) in addition to all
required by your config, I miss something.  Because, the second pull
should not be so long.

Well, one way to fix is, before the reboot, run “guix archive --export
-r $(readlink -f /path/to/default/guix/profile)” and then after the
login run “guix archive --import”.  This should avoid to fetch twice the
same substitutes (used by Guix).  I thought that something like that was
included by “guix system init”.

In conclusion, the problem here does not seem cloning the repo, but
fetching all the substitutes twice.

Cheers,
simon

Re: Install `guix pull'ed Guix to target partition on system install

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

> Did you really do this “guix pull”?  Because it is…
>
>> - guix system init ... /mnt 
>> - reboot
>>
>> Now on my fresh system, the only Guix available is the one from the USB
>> stick, namely 1.2, and not the one from my channels.
>
> …in contradiction with this.  So bug?

It's not a contradiction.

> In conclusion, the problem here does not seem cloning the repo, but
> fetching all the substitutes twice.

There is a misunderstanding: the Guix live system is not the same OS
(nor the same store) as the installed system.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Install `guix pull'ed Guix to target partition on system install

[zimoun]

Hi Pierre,

On Tue, 22 Dec 2020 at 10:44, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
>> Did you really do this “guix pull”?  Because it is…
>>
>>> - guix system init ... /mnt 
>>> - reboot
>>>
>>> Now on my fresh system, the only Guix available is the one from the USB
>>> stick, namely 1.2, and not the one from my channels.
>>
>> …in contradiction with this.  So bug?
>
> It's not a contradiction.

It is.  If you do:

  (live) guix pull
  (live) guix system init

then it appears expected to install what the system describes *and* the
current guix used to install them.  Therefore, after reboot, the first
“guix pull” will not fetch all the substitutes Guix requires, because
you already did.

Other said,

  (live) guix pull
  (live) guix describe
  (live) guix system init
  (live) reboot
  (real) login as root
  (real) guix describe 
  
The 2 ’describe’ should be the same commit and apparently they are not.


>> In conclusion, the problem here does not seem cloning the repo, but
>> fetching all the substitutes twice.
>
> There is a misunderstanding: the Guix live system is not the same OS
> (nor the same store) as the installed system.

I do not see where there is a misunderstanding.

If you really did:

   (live) guix pull
   (live) guix system init …
   (live) reboot
   (real) login as regular user
   (real) guix pull

Then the issue is not the cloning part (’git clone
https://git.savannah.gnu.org/git/guix.git’) displaying «Updating channel
'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...» but the fact that you
are downloading twice the substitutes used by “guix pull”.

Please re-read these messages:
  <https://yhetil.org/guix/86y2hq90sm.fsf@gmail.com>
  <https://yhetil.org/guix/86tuse8yzh.fsf@gmail.com>


Cheers,
simon

Re: Install `guix pull'ed Guix to target partition on system install

[Carlo Zancanaro]

Hi Simon!

On Tue, Dec 22 2020, zimoun wrote:
> It is.  If you do:
>
>   (live) guix pull
>   (live) guix system init
>
> then it appears expected to install what the system describes 
> *and* the current guix used to install them.  Therefore, after 
> reboot, the first “guix pull” will not fetch all the substitutes 
> Guix requires, because you already did.

Part of the issue here is that "guix system init" installs into 
the system the version of Guix that the "guix" package refers to, 
which is always older than the version that you are using to do 
the installation. The "guix" package points to a specific commit 
(4f621a2b003e85d480999e4d0630e9dc3de85bc3 in my current guix 
version) which must have come prior to the commit of the guix that 
is running (which for me is 
5795f566fae85023c6be86fe62388c29e6ac5c51).

This also means that the installed system doesn't include the 
installed channels in the system Guix, as the Guix version 
referenced by the "guix" package does not include any external 
channels.

> Other said,
>
>   (live) guix pull
>   (live) guix describe
>   (live) guix system init
>   (live) reboot
>   (real) login as root
>   (real) guix describe
>
> The 2 ’describe’ should be the same commit and apparently they 
> are not.

This expectation is wrong. The two "describe"s should return 
different commits, and the second one should be earlier than the 
first.

Unfortunately, I am not aware of a solution to the issue Pierre 
has raised.

Carlo

Re: Install `guix pull'ed Guix to target partition on system install

[zimoun]

Hi Carlo,

On Tue, 22 Dec 2020 at 22:51, Carlo Zancanaro <carlo@zancanaro.id.au> wrote:

> On Tue, Dec 22 2020, zimoun wrote:
>> It is.  If you do:
>>
>>   (live) guix pull
>>   (live) guix system init
>>
>> then it appears expected to install what the system describes 
>> *and* the current guix used to install them.  Therefore, after 
>> reboot, the first “guix pull” will not fetch all the substitutes 
>> Guix requires, because you already did.
>
> Part of the issue here is that "guix system init" installs into 
> the system the version of Guix that the "guix" package refers to, 
> which is always older than the version that you are using to do 
> the installation. The "guix" package points to a specific commit 
> (4f621a2b003e85d480999e4d0630e9dc3de85bc3 in my current guix 
> version) which must have come prior to the commit of the guix that 
> is running (which for me is 
> 5795f566fae85023c6be86fe62388c29e6ac5c51).

We are describing the same issue but worded differently; or I am sorry
but I cannot express differently.  Well, IIUC, you are explaining why it
is not as I expect.  So bug?

(And if it is not, I am going to take a break because then I do not
understand what you and I are both saying.)

>>   (live) guix pull
>>   (live) guix describe
>>   (live) guix system init
>>   (live) reboot
>>   (real) login as root
>>   (real) guix describe
>>
>> The 2 ’describe’ should be the same commit and apparently they 
>> are not.
>
> This expectation is wrong. The two "describe"s should return 
> different commits, and the second one should be earlier than the 
> first.

Your description is the current situation.  And that’s why the first
“guix pull” after the first log is so long.  It should not work like
that.  Because I did my homework, let reuse your own words ;-) «I don't
think "expected" is the right way to put this. I think "explainable" is
more accurate.»

Even if the second “describe” return an earlier commit than the first,
all the store items should be already in the final store because they are
in the live store.

Otherwise, the same substitutes are pulled twice.


> Unfortunately, I am not aware of a solution to the issue Pierre 
> has raised.

One way is to transfer the store items from the live store to the disk
store somehow via “guix archive --export -r” then “guix archive
--import”.  IMHO.


All the best,
simon