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

[Tobias Geerinckx-Rice <me@tobias.gr>]

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).

> 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.

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 
  ...)

> 2) The welcome screen with installation instructions is a bit
> cluttered. I had in mind that Danny already worked on this? 
> There might
> be some interesting things in case of fatal errors. But this is 
> not very
> nice for new users who can't read the instructions between the 
> lines:
>
> It's something like that:
>
> ```
> You have been warned ...
> [8.47... ] shephard[1]: Service console-font-tty1 has been 
> started.
> ... Service term-tty2 has been started.
> ..
> PIO_UNIMAPCLR: Input/output error
> root@gnu ~# [...]
> error in finalization thread: Bad file descriptor
> [49.] random: crng init done
> [49]  random: 4 urandom warning(s) missed due to ratelimiting
>
> ```

Yeah. This is horrible.

> 3) PIO_UNIMAPCLR: Input/output error
>
> Anything to worry about?

I can't find this in any logs on any box so I can't say.

> 3a) POSITIVE: Colors work. GPM works. Alt-F2, Docu works.
>
> 4) Network setup. Then: `ping -c gnu.org`
>
> That did not work. It took me a while to realize that DNS worked 
> but
> ping not. Probably due to QEMU NAT?

Not NAT, but yes, it's due to QEMU's ‘user networking’ not 
actually emulating all OSI layers IIRC.

> 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!)

We *could* include our own simple CLI HTTP client in Guile, if one 
doesn't already exist. I don't think that it's a very good option, 
but it is one.

> 5) I think the partition part in the manual is quite 
> confusing. For me,
> it's not clear what's the difference between DOS and this other
> partitioning scheme. Which one should I choose in which 
> situation [OK,
> is this something GuixSD has to care about? I think at least a 
> bit]?

It's something the user has to care about, because their computer 
does and GRUB does. Unless we (again) write our own magic wrapper 
somehow. Then GRUB breaks, the user shows up in #guix, and it's 
even harder to help them.

I think it would be most helpful to add something like:

  If /sys/firmware/efi exist on your system, jump to Partitioning 
  under UEFI.
  Otherwise, see Partitioning with DOS or BIOS or whatever we 
  choose to call it.

Would this have been enough to help you through?

[I prefer this to a ‘Welcome to the installer! (UEFI mode)’ 
message as proposed elsewhere because it keeps all knowledge in 
the manual, doesn't scroll off the screen ;-), isn't 
GuixSD-specific, and allows the user to get started quickly 
without hiding anything, but that's obviously all in my opinion.]

> Anyway, I continued with a DOS, one partition, no swap.
>
> 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?

> 7) Zile/Umlauts problem:
> I wantet do write "Björn" as my user comment in the config but I
> couldn't.
> Althogh I did `loadkeys de-latin1` and could write umlauts on 
> the
> shell, within Zile I get this error:
>
> <b6> is undefined
>
> 7a) GOOD: guix system init took only 10 minutes. Where's my 
> break?
>
> 8) No keymap in new system:
>
> One of the first steps in the installation is to load the 
> keymaps. But
> when I reboot into the newly system, I'm left with the default
> US-keyboard again. Luckily root has no password yet. Nobody 
> mentioned I
> should set that up in my configuration, no example in the 
> configuration
> file [I used the plain one]

Another good point. I can't imagine anyone not merging a patch 
adding this to all relevant spots.

> 8a) GOOD: That title 'label thing is no longer in the config, 
> although
> it is still mentioned on the homepage docs [Needs to be updated]

I assume that will happen once (and as soon as) 0.15 is out. There 
are still people installing 0.14 and using the manual on 
gnu.org/s/guix to do so. Changing it now would give them 
unintelligible error messages.

[Once the reason for the gnu.org/guix.info split has been solved, 
we could offer both the latest release and a ‘live’ version of the 
manual.]

> 9) Old guix version:
>
> Being in the newly booted system:
>
>  which guix:
> --> /run/current-system/profile/bin/guix
>   -> /gnu/store/111i...-guix-0.14.0-12.77a1aac/bin/guix
>
> That commit 77a1aac is from 2018-06-09. Why so old?
>
> After guix pull [quite fast!], I get it correctly from 
> ~/.config/...
>
> Ah, whait, a `which guix` is correctly pointing to there, and 
> that is finally pointing to 
> `/gnu/store/496...guix-6e65eb3a/bin/guix` But guix --version 
> reports still the old one ...
>
> So why is there this guix-0.14.0-12.77a1aac from one month ago? 
> After a
> fresh installation, I want the newest Guix!
>
> BTW: After reboot (I think a logout/in would have been 
> sufficent), guix
> --version reported the new commit-id.

This is probably the most important point, and I have no idea 
what's going on. Maybe after I've seen it in action.

> 10) Old kernel?
>
> I'm pretty sure about that, but now a bit confused. Probably due 
> to 9)?
>
> Installation ISO welcomes with:
>
> "GNU with Linux-Libre 4.17.3 (beta)"
>
> After 'guix system init', I'm at 4.17.2 (Yes, I have this old 
> generation in my GRUB startup screen).
>
> Only after guix pull && guix system reconfigure I'm at 4.17.3 
> again.
>
> So, if you start your system newly and don't do a guix pull 
> directly ["This is so complicated, let's do that later..."], you 
> are one kernel behind...

It also means that you're downloading a *lot* more during ‘guix 
system init’ than you should be, if you didn't run ‘guix pull’ 
from the installer.

A bright corollary:

7b) ‘guix system init’ will take even less than 10 minutes if this 
can be fixed.

> 11) guix gc and locale confusion:
>
> I configured my system with locale 'de_DE.utf8'. Note in Germany 
> the comma (',') is used a a decimal separator. guix gc gives me 
> at the end:
>
> ...
> note: currently hard linking saves 206.08 MiB
> guix gc: freed 91,50781 MiBs
>
> The first line is written in English with a decimal point. The 
> last line is written in English, although the decimal separator 
> is German [Furthermore, It's more confusing to report the 
> 0.00081 MiBs, i.e. about 80KiB saved space. Rounding should be 
> done after 3 places].

Agreed. I have an old patch (from 2017) that did somethings to 
improve that output and might address your comments.

> 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.

Thanks again!

T G-R