Add the ability to install GuixSD offline + Add the ability to add static IP

Open

Details

3 participants

bo0od
Josselin Poiret
Giovanni Biscuolo

Owner: unassigned

Submitted by: bo0od

Severity: normal

bo0od wrote on 25 Aug 2020 20:59

Recipients:(address . bug-guix@gnu.org)

Message-ID:97bbfb6d-e712-cbc7-a809-9285cd504faf@riseup.net

Add the ability to install GuixSD offline + Add the ability to add

static IP in the installation process.

This is important as users with static IP or using VMs or Offline usage

cant use this distro.

These features are very common and its almost in every OS available,

Hope to see it here as well.

ThX!

Giovanni Biscuolo wrote on 5 Feb 18:33 +0100

Re: guix installation why internet connection required?

Recipients:(address . guix-devel@gnu.org)

Message-ID:875xz2byuo.fsf@xelera.eu

Hi Maxim and vvt@mail-on.us,

I'm including 43049@debbugs.gnu.org to keep track of the discussion on

this feature request (Add the ability to install GuixSD offline)

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (12 lines)> vvt@mail-on.us writes:
>
>> x86 x64 gnu guix system 1.4.0 iso requires internet connection in order to get
>> installed. Same goes for i686 iso.
>>
>> Why is that so? Why is there no
>> iso option for installing off line? Thanks.
>
> There's this ticket about the same: #43049.  If I remember correctly it
> may be related by the Guix binary inside the ISO image being from the
> Guix package of the Guix used to generate it, perhaps.

Sorry I don't understand the problem, could you expand please?

The guix (and daemon) versione are those of the channel used when

creating the install .iso image; booting the 1.40 installer we get a

"guix version" and "guix describe" value of 989a391...

Also, the /gnu/store (755MB on 1.4.0 installer image) have all the

software needed to run the installer; when installing the (same) linux

kernel on the target disk, for example, why the daemon would download

the same substitute when it's already in the store?

Obviously the connection to a substitute server is needed if the user

choose to install some software not already in the store, so the point

should "just" be to have all the software the installer allows the user

to be installed.

Toggle quote (2 lines)

> That seems like a tricky problem to solve.

...I feel like I'm missing something important here :-)

Thanks! Gio'

Giovanni Biscuolo

Xelera IT Infrastructures

Josselin Poiret wrote on 6 Feb 11:58 +0100

Recipients:(address . guix-devel@gnu.org)

Message-ID:878r3xn9k4.fsf@jpoiret.xyz

Hi Giovanni,

Giovanni Biscuolo <g@xelera.eu> writes:

Toggle quote (6 lines)

> Sorry I don't understand the problem, could you expand please?

> The guix (and daemon) versione are those of the channel used when

> creating the install .iso image; booting the 1.40 installer we get a

> "guix version" and "guix describe" value of 989a391...

Not exactly, to include Guix inside the installer image, it somehow
needs to refer to itself.  The way it used to be done was by using the
`guix` package, which necessarily is older than the current commit.
However, we also implemented the `current-guix` hack that basically uses
a guix checkout at the current guix version as the source for the guix
package.  In both cases though, we shouldn't see any differences in
other package's derivations…

Best,
-- 
Josselin Poiret

Giovanni Biscuolo wrote on 7 Feb 10:47 +0100

bug#43049: Add the ability to install Guix System offline

Recipients:

Message-ID:87wmrga9mw.fsf@xelera.eu

Hi Josselin,

first of all, sorry for the confusion: I'm still learning... and I'm

probably still using bad terminilogy from a Guix/Guile developer POV.

Josselin Poiret <dev@jpoiret.xyz> writes:

Toggle quote (12 lines)> Giovanni Biscuolo <g@xelera.eu> writes:
>
>> Sorry I don't understand the problem, could you expand please?
>>
>> The guix (and daemon) versione are those of the channel used when
>> creating the install .iso image; booting the 1.40 installer we get a
>> "guix version" and "guix describe" value of 989a391...
>
> Not exactly, to include Guix inside the installer image, it somehow
> needs to refer to itself.  The way it used to be done was by using the
> `guix` package, which necessarily is older than the current commit.

OK, in fact I checked starting the guix-1.4 install image in a VM and I
got an older guix in the install system (forgive me for the missing the
details, but this is not important in this context), but the verion
installed on the target was 1.4.0 (so I guess its subsitute was
downloaded from one of the build farms).

Toggle quote (4 lines)

> However, we also implemented the `current-guix` hack that basically uses

> a guix checkout at the current guix version as the source for the guix

> package.

So, since some commit, now the guix version used to build the target

system image is the one checked-out by the person/agent running the

install image build script: did I understand it correctly?

Toggle quote (3 lines)

> In both cases though, we shouldn't see any differences in other

> package's derivations…

Does this mean you consider possible to pre-populate the /gnu/store

install system (the one started using the install image) with a substet

of substitutes possibly needed in the target system?

I'm wondering if it's possible to create a custom build image (info

"(guix) Building the Installation Image") to do something like this.

Thanks! Gio'

Giovanni Biscuolo

Xelera IT Infrastructures

Josselin Poiret wrote on 10 Feb 11:13 +0100

Recipients:

Message-ID:87eddk630t.fsf@jpoiret.xyz

Hi Giovanni,

Giovanni Biscuolo <g@xelera.eu> writes:

Toggle quote (8 lines)

>> However, we also implemented the `current-guix` hack that basically uses

>> a guix checkout at the current guix version as the source for the guix

>> package.

> So, since some commit, now the guix version used to build the target

> system image is the one checked-out by the person/agent running the

> install image build script: did I understand it correctly?

Yes.

Toggle quote (7 lines)

>> In both cases though, we shouldn't see any differences in other

>> package's derivations…

> Does this mean you consider possible to pre-populate the /gnu/store

> install system (the one started using the install image) with a substet

> of substitutes possibly needed in the target system?

I think it's already meant to be the case, see the comment in
gnu/system/install.scm about keeping a reference to the bare bones os's
closure.  It wouldn't contain all graphical stuff either, but I think
there's also some trouble with grafts that forces users to still
download substitutes.

Best,
-- 
Josselin Poiret

Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 43049@debbugs.gnu.org

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date