Installation-Protocol for GuixSD x86_64 v0.15-preview

Installation-Protocol for GuixSD x86_64 v0.15-preview

[Björn Höfling]

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

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.

Overall result: Yes, it worked, no big trouble! There are some things I
noticed I want to share here. I know you all do a good job here, so
take this just as observations. Whoever has the time might take one. And
I'm really picky when I should test something :-)

Starting point/environment Guix from git, being on commit:

6e65eb3cad1d1148eade9ed2228cdea90d531a94
From: Mon Jul 2 00:08:54 2018 +0200

Being on Ubuntu, having Qemu from Ubuntu.

Preparation of installation image went quick and without problems.
Booting it up was also no problem.

Here are my points :

1) Manual/Installing GuixSD in a VM:
https://www.gnu.org/software/guix/manual/guix.html#Installing-GuixSD-in-a-VM

It's telling to start the VM like:

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. Should we update the manual?

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

```

3) PIO_UNIMAPCLR: Input/output error

Anything to worry about?

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?

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?

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]?

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.

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

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]

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.

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

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


12) ls | less

ls has a colored output. Nice.
ls | less has ugly escape sequences. Only ls --color=no | less works.


That's it for now.

Björn


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

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

[Tobias Geerinckx-Rice]

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

(Ab?)using aliases to set ls' and others' colours

[Tobias Geerinckx-Rice]

Tobias Geerinckx-Rice wrote:
> Björn Höfling wrote:
>> 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’.

Apologies, I made a reado.

‘ls | $foo’ should indeed detect a missing tty and stop spewing 
colour automatically. At least if ‘ls’ is properly aliased to ‘ls 
--color=auto’.

Instead, it is aliased[0] to use ‘--color’ — short for ‘ls 
--color=always’ — for reasons I cannot understand. We do the same 
for ‘grep’.

Perhaps it was assumed that ‘--color’ on its own implies ‘auto’ 
instead of ‘always’ (I could see how that could happen)? Or 
‘--color=auto’ is too cautious, and disables colour in a situation 
where the author expects it? In that case I don't think the 
trade-off is worth it.

On the other hand, what I consider an obvious bug has been around 
since literal forever[1], so maybe I'm missing something obvious 
here. I've CC'd the original author. If everyone agrees or nobody 
responds, I'd like to change it to something less aggressive 
before 0.15.[2]

What? Not sure yet. I'm not even sure this should be handled by 
aliases at all. Our default ‘ls’ alias also adds a ‘-p’, which is 
probably valid [although I find it useless and annoying and 
disable it], but colours for both commands can also be controlled 
through the {LS,GREP}_COLORS variables which seems like a better 
fit for distro defaults like these. We can even change the 
colours! But let's not.

Oh, I don't know.

This is the kind of trivial bug that would've put me off a distro, 
I guess.

Kind regards,

T G-R

[0]: in gnu/system/shadow.scm
[1]: 2013, at least: 0b86a82dc7e649e4ae551edefba445690a315b83
[2]: I'm already doing so in my own .bashrc, which has drifted 
away from Guix's current upstream version, which is its own little 
annoying gotcha.

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

[Marius Bakke]

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

Björn Höfling <bjoern.hoefling@bjoernhoefling.de> writes:

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

The issue here is that the installation media has no
~/.config/guix/current: it uses the "snapshot" Guix, from (gnu packages
package-management).  Which in turn installs an even older snapshot.

It is the same reason you got an older kernel than the installation
image: when building the image, you get the latest version (from your
~/.config/guix/current); but when installing, you get the version
contained in the snapshot.

So it's Guix all the way down.  A funny side effect is that if you never
`guix pull`, but keep reconfiguring, you'll gradually downgrade your
system one snapshot at a time.

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

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

[Danny Milosavljevic]

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

Hi Björn,

thanks for testing it!

On Tue, 3 Jul 2018 10:15:53 +0200
Björn Höfling <bjoern.hoefling@bjoernhoefling.de> wrote:

> 2) The welcome screen with installation instructions is a bit
> cluttered. I had in mind that Danny already worked on this? 

Only for the serial tty init.  But it might be similar here too, I don't know.

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

According to https://elixir.bootlin.com/linux/v3.2/source/include/linux/kd.h#L70
that's trying to clear the Unicode -> font map (that is, charmap).

In Linux, ./drivers/tty/vt/vt_ioctl.c implements it.

Can't see how that ever ends up in -EIO O_o

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

Please, anything *but* 3 fractional places.

Right now, it's still possible to disambiguate "," and "." errors--that would
not be possible with 3 fractional places.

>

After this release, let's integrate an installer.

wip-installer-2 works fine.  The architecture could be more generic (it has
peculiar ideas about how any installer screen MUST look), but it's not bad
or anything.  Also, the wizard leaves something to be desired (I didn't
find the place where it does that yet: You can select any future step, but
if it requires information in a dependent step, it will instead jump to
that one - that's jarring and not what you would expect - at least not
without good visualization).

I thought about doing fully generic Guile window management library a la
Turbo Vision but it's really overkill for what we need.  Nice, sure.

I think the technical holdup for merging wip-installer-2 to master was the
modularization of guix.

Also, I've packaged Anaconda, the Red Hat installer.  It still fails some
tests (and has a lot of dependencies).  I would need some help with Guix's
gi.repository handling.

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

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

[Ludovic Courtès]

Hey Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> After this release, let's integrate an installer.
>
> wip-installer-2 works fine.  The architecture could be more generic (it has
> peculiar ideas about how any installer screen MUST look), but it's not bad
> or anything.  Also, the wizard leaves something to be desired (I didn't
> find the place where it does that yet: You can select any future step, but
> if it requires information in a dependent step, it will instead jump to
> that one - that's jarring and not what you would expect - at least not
> without good visualization).
>
> I thought about doing fully generic Guile window management library a la
> Turbo Vision but it's really overkill for what we need.  Nice, sure.
>
> I think the technical holdup for merging wip-installer-2 to master was the
> modularization of guix.

I agree, we should definitely do that!  And we can always improve it
incrementally afterwards.

Ludo’.

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

[Ludovic Courtès]

Hi Björn,

Björn Höfling <bjoern.hoefling@bjoernhoefling.de> skribis:

> 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.
>
> Overall result: Yes, it worked, no big trouble! There are some things I
> noticed I want to share here. I know you all do a good job here, so
> take this just as observations. Whoever has the time might take one. And
> I'm really picky when I should test something :-)

Thanks a lot for testing and providing detailed feedback!  I think
Tobias and Marius already commented on most issues; some can be fixed
for 0.15, others are unfortunately trickier to address.

> Starting point/environment Guix from git, being on commit:
>
> 6e65eb3cad1d1148eade9ed2228cdea90d531a94
> From: Mon Jul 2 00:08:54 2018 +0200

I made some adjustments to ‘guix system init’ later today, but it
shouldn’t make a big difference here.

Did you have troubles with substitutes?  In particular, did it hang as
described in <https://bugs.gnu.org/31925>?  (I’m still experiencing it
occasionally and I can’t believe I’m the only one.)

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

The English part comes from the C++ code base, which is not i18n’d,
whereas the other line comes from the Scheme part, which is i18n’d.

Here the Scheme code prints numbers according to your German locale;
however, there’s apparently no translation of the message itself, which
is why it still says “freed”.  Weird, I agree.

> 12) ls | less
>
> ls has a colored output. Nice.
> ls | less has ugly escape sequences. Only ls --color=no | less works.

As discussed on IRC with Tobias, that’s a mistake; we should use
--color=auto.  Tobias, are you committing this change?  :-)

Thanks!

Ludo’.

KDFONTOP/PIO_UNIMAPCLR: Input/output error

[Ludovic Courtès]

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

Hello Danny & all,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

>> PIO_UNIMAPCLR: Input/output error
>> 3) PIO_UNIMAPCLR: Input/output error
>> 
>> Anything to worry about?
>
> According to https://elixir.bootlin.com/linux/v3.2/source/include/linux/kd.h#L70
> that's trying to clear the Unicode -> font map (that is, charmap).
>
> In Linux, ./drivers/tty/vt/vt_ioctl.c implements it.
>
> Can't see how that ever ends up in -EIO O_o

Sometimes we also get:

  putfont: KDFONTOP: Input/output error

In both cases, the warning comes from the ‘setfont’ program, invoked
from ‘console-font-shepherd-services’.

I’ve looked at the code and man pages and like you, I don’t see where
EIO comes from.  Maybe it’s a generic ioctl error that’s return before
we reach the actual ioctl implementation in the VT driver, sorta like
EBADF?

Until we find out, I’d like to just silence the warnings:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 841 bytes --]

--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -754,8 +754,10 @@ to add @var{device} to the kernel's entropy pool.  The service will fail if
                         ;; systemd's vconsole support, let's not treat
                         ;; this as an error.
                         (case (status:exit-val
-                               (system* #$(file-append kbd "/bin/setfont")
-                                        "-C" #$device #$font))
+                               (with-error-to-port (%make-void-port "w")
+                                 (lambda ()
+                                   (system* #$(file-append kbd "/bin/setfont")
+                                            "-C" #$device #$font))))
                           ((0 71) #t)
                           (else #f))))
              (stop #~(const #t))

[-- Attachment #3: Type: text/plain, Size: 28 bytes --]


Sounds good?

Ludo’.

Re: KDFONTOP/PIO_UNIMAPCLR: Input/output error

[Marius Bakke]

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

ludo@gnu.org (Ludovic Courtès) writes:

> Hello Danny & all,
>
> Danny Milosavljevic <dannym@scratchpost.org> skribis:
>
>>> PIO_UNIMAPCLR: Input/output error
>>> 3) PIO_UNIMAPCLR: Input/output error
>>> 
>>> Anything to worry about?
>>
>> According to https://elixir.bootlin.com/linux/v3.2/source/include/linux/kd.h#L70
>> that's trying to clear the Unicode -> font map (that is, charmap).
>>
>> In Linux, ./drivers/tty/vt/vt_ioctl.c implements it.
>>
>> Can't see how that ever ends up in -EIO O_o
>
> Sometimes we also get:
>
>   putfont: KDFONTOP: Input/output error
>
> In both cases, the warning comes from the ‘setfont’ program, invoked
> from ‘console-font-shepherd-services’.
>
> I’ve looked at the code and man pages and like you, I don’t see where
> EIO comes from.  Maybe it’s a generic ioctl error that’s return before
> we reach the actual ioctl implementation in the VT driver, sorta like
> EBADF?
>
> Until we find out, I’d like to just silence the warnings:
>
> --- a/gnu/services/base.scm
> +++ b/gnu/services/base.scm
> @@ -754,8 +754,10 @@ to add @var{device} to the kernel's entropy pool.  The service will fail if
>                          ;; systemd's vconsole support, let's not treat
>                          ;; this as an error.
>                          (case (status:exit-val
> -                               (system* #$(file-append kbd "/bin/setfont")
> -                                        "-C" #$device #$font))
> +                               (with-error-to-port (%make-void-port "w")
> +                                 (lambda ()
> +                                   (system* #$(file-append kbd "/bin/setfont")
> +                                            "-C" #$device #$font))))
>                            ((0 71) #t)
>                            (else #f))))
>               (stop #~(const #t))
>
> Sounds good?

Less scary warnings in the first impression sounds great :-)

There should be an explaining comment with that code though.

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

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

[Björn Höfling]

[-- 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 --]

Re: (Ab?)using aliases to set ls' and others' colours

[Björn Höfling]

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

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

> Tobias Geerinckx-Rice wrote:
> > Björn Höfling wrote:  
> >> ls has a colored output. Nice.
> >> ls | less has ugly escape sequences. Only ls --color=no | less
> >> works.  

[..]

> 
> Perhaps it was assumed that ‘--color’ on its own implies ‘auto’ 
> instead of ‘always’ (I could see how that could happen)? Or 
> ‘--color=auto’ is too cautious, and disables colour in a situation 
> where the author expects it? In that case I don't think the 
> trade-off is worth it.


Just for reference: Here is what my Ubuntu has in /etc/skel/.bashrc:

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
fi

[..]

> Oh, I don't know.
> 
> This is the kind of trivial bug that would've put me off a distro, 
> I guess.

Yeah, it's one of those nasty little things that are totally silly but
on the other hand are expected to "just work".

Björn

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

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

[Björn Höfling]

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

On Tue, 03 Jul 2018 23:42:28 +0200
ludo@gnu.org (Ludovic Courtès) wrote:

[..]
> Did you have troubles with substitutes?  In particular, did it hang as
> described in <https://bugs.gnu.org/31925>?  (I’m still experiencing it
> occasionally and I can’t believe I’m the only one.)

No. But it looks like you found your example to reproduce.

Björn

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

Re: (Ab?)using aliases to set ls' and others' colours

[Ludovic Courtès]

Tobias Geerinckx-Rice <me@tobias.gr> skribis:

> Instead, it is aliased[0] to use ‘--color’ — short for ‘ls
> --color=always’ — for reasons I cannot understand. We do the same for
> ‘grep’.

I fixed this in commit 9fd877247de6efec3aec53e93db5323a97d7b05e.

Thanks for reporting the issue!

Ludo’.

Re: (Ab?)using aliases to set ls' and others' colours

[Ricardo Wurmus]

Hi Tobias,

> Tobias Geerinckx-Rice wrote:
>> Björn Höfling wrote:
>>> 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’.
>
> Apologies, I made a reado.
>
> ‘ls | $foo’ should indeed detect a missing tty and stop spewing colour
> automatically. At least if ‘ls’ is properly aliased to ‘ls
> --color=auto’.
>
> Instead, it is aliased[0] to use ‘--color’ — short for ‘ls
> --color=always’ — for reasons I cannot understand. We do the same for
> ‘grep’.

I think this is simply a mistake.  Using “--color=auto” is correct here.

> On the other hand, what I consider an obvious bug has been around
> since literal forever[1], so maybe I'm missing something obvious
> here. I've CC'd the original author. If everyone agrees or nobody
> responds, I'd like to change it to something less aggressive before
> 0.15.[2]

No objections from me.  Thank you!

--
Ricardo

Re: KDFONTOP/PIO_UNIMAPCLR: Input/output error

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> Danny Milosavljevic <dannym@scratchpost.org> skribis:
>
>>> PIO_UNIMAPCLR: Input/output error
>>> 3) PIO_UNIMAPCLR: Input/output error
>>> 
>>> Anything to worry about?
>>
>> According to https://elixir.bootlin.com/linux/v3.2/source/include/linux/kd.h#L70
>> that's trying to clear the Unicode -> font map (that is, charmap).
>>
>> In Linux, ./drivers/tty/vt/vt_ioctl.c implements it.
>>
>> Can't see how that ever ends up in -EIO O_o
>
> Sometimes we also get:
>
>   putfont: KDFONTOP: Input/output error
>
> In both cases, the warning comes from the ‘setfont’ program, invoked
> from ‘console-font-shepherd-services’.
>
> I’ve looked at the code and man pages and like you, I don’t see where
> EIO comes from.  Maybe it’s a generic ioctl error that’s return before
> we reach the actual ioctl implementation in the VT driver, sorta like
> EBADF?

I think I have a plausible explanation.  :-)  The EIO comes from
‘hung_up_tty_ioctl’ in drivers/tty/tty_io.c.  This is because mingetty
would call ‘vhangup’, and presumably, there was a time window where
‘setfont’ would find itself talking to a hung-up terminal.  QED.

Anyway, in commit a043b5b81a080c47e24298c80857919b9ea21bb2 I’ve added
--nohangup to mingetty and now ‘setfont’ is happy, and so am I.

Ludo’.