[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Installation-Protocol for GuixSD x86_64 v0.15-preview
|
From: |
Tobias Geerinckx-Rice |
|
Subject: |
Re: Installation-Protocol for GuixSD x86_64 v0.15-preview |
|
Date: |
Tue, 03 Jul 2018 12:49:12 +0200 |
|
User-agent: |
mu4e 1.0; emacs 26.1 |
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
address@hidden ~# [...]
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