Re: Installation-Protocol for GuixSD x86_64 v0.15-preview

["Björn Höfling" <bjoern.hoefling@bjoernhoefling.de>]

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

Hi Tobias,

On Tue, 03 Jul 2018 12:49:12 +0200
Tobias Geerinckx-Rice <me@tobias.gr> wrote:

> Hullo Bj<b6>rn,
> 
> Björn Höfling wrote:
> > Hi people,
> >
> > as Ludo "requested", today I freshly installed GuixSD in a QEMU
> > environment (x86_64 on both host and virtual env) to check the
> > installation process of the upcoming release.  
> 
> Wow. Thanks!
> 
> You've motivated me to try it on a headless server (if that 
> works).

Are you doing that with QEMU? I would be interested in improving my
Q-foo and know how to create a headless, SSH-only QEMU-server.

 
> > qemu-system-x86_64 -m 1024 -smp 1 \
> >   -net user -net nic,model=virtio -boot menu=on \
> >   -drive file=guixsd-install-0.14.0.system.iso \
> >   -drive file=guixsd.img
> >
> > I prefered writing the disk like this:
> >
> >  -drive readonly,media=cdrom,\
> > file=/gnu/store/70p7140n5igrqsfl989cxfzx6q3czc9a-image.iso
> >
> > In that way, I can use the RO store entry and QEMU will not 
> > complain
> > about not being able to write to.  
> 
> My QEMU-FU is, to say the least, rusty.
> 
> Do I parse this correctly as two separate (but related) 
> suggestions: adding ‘readonly,media=cdrom’ to silence the 
> complaint and ‘file=/gnu/store/...’ to use an image from the 
> store?
> 
> > Should we update the manual?  
> 
> ...if so: +1 to the first suggestion.

Yes, that is what I mean. Maybe the "readonly" is superfluous with
"media=cdrom", I have to read/try that.

I can write a docs-patch by the end of the week.

 
> The second one seems to depend on your situation. The manual 
> assumes you've downloaded the image (probably not using ‘guix 
> download’) instead of building it from scratch, but we could 
> document both. Especially since the latter can be written as one 
> easy command:
> 
>   qemu-system-x86_64 [...] -drive readonly,media=cdrom,file=$(guix 
>   ...)

Yes, we should take that as a separate thing.

AFAIK the combination might be a bit dangerous: Building the
installation media is not (yet?) reproducible, so the $(guix ...)
command will produce every time a new image, not just a reference on
the existing store item as would be the case for reproducibly-stable
package builds.

[...]

> > I tried instead wget or curl. But both are not there. Do we have
> > "HTTP client" tools in the installer package to test the network 
> > this
> > way? Or is this too heavy in size for the installer? Do we have
> > anything else to give the user at it's hand besides ping?  
> 
> ‘guix download’. (Hey, if we include a static example and its hash 
> in the manual you'll even know when your being MITM'd by an 
> incompetent!)

Of cause. Cool!

 
[..]

> > 6) Editors: When it comes about editing the standard config, 
> > there are
> > three editors mentioned: zile, nano, nvi. The first ones are 
> > fired up as
> > named, for "nvi" the command is "vi". This is not obvious for 
> > everyone.  
> 
> Thorough testing :-) Good catch! Do you have time to submit a 
> patch?

Yes. This week.

 
[..]

> > 12) ls | less
> >
> > ls has a colored output. Nice.
> > ls | less has ugly escape sequences. Only ls --color=no | less 
> > works.  
> 
> I'd be surprised if ‘ls | less -R’ didn't (and that would be a 
> bug).
> 
> Otherwise, this is standard behaviour for both ‘ls’ and ‘less’. If 
> other distributions wrap it in magick, it would be interesting to 
> know how, and where, and if it's clean enough for us to copy.

I saw your discussions on IRC and look forward for a patch :-)

Björn

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]