bug#36634: Virtual Machine Manager (virt-manager)

[Chris Marusich]

Chris Marusich  writes:

> This bug is consistently reproducible.  I've found an upstream bug
> report that is very similar to what we're seeing here, so I've left a
> comment telling the libvirt maintainers that Guix is also seeing a
> similar issue:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1751120

Upstream has made a patch, which supposedly fixes the issue on Fedora
systems.  However, I applied it to a local checkout of Guix and tested
it, but it didn't fix the issue for me.  Perhaps that upstream bug and
this bug are slightly different?  Anyway, I've updated the upstream bug
report with information that hopefully will be useful to them.  We'll
see how it goes.

-- 
Chris


signature.asc
Description: PGP signature

bug#37612: Markdown

[theamazed74]

Sorry, for the bad formatting. 
I hadn't used the GNU Bug reporting system before and thought it used markdown.

bug#37347: 'guix environment' fails after trying to follow the steps from "Running Guix Before It Is Installed" page

[Bengt Richter]

On +2019-10-04 09:15:56 +0200, Jelle Licht wrote:
> Bengt Richter  writes:
> 
> > [snip]
> > ...
> > [19:40 ~/bs]$ ping guix.gnu.org
> > ping: guix.gnu.org: Name or service not known
> I actually have this sometimes as well. Are you on a less-than-stellar
> WiFi-connection perhaps? I noticed the default (nscd?) configuration on
> Guix systems caches 'negative' results for quite a while.
> 
> Could you try this command again after issuing:
> `sudo herd invalidate nscd hosts'?
> 
> HTH!
> - Jelle

Hi Jelle, thanks for your reply.

I am a grateful courtesy guest sharer of internet access in
a small office complex via cat5 to their switches, so it should
not be a WiFi problem.

I get DNS automatically along with ip from their server dhcp,
but I have other options I could explore.

I can't try the herd command right now, as I am in strictly "foreign"
mode at the moment.

--Ignorable note about that:
(I am busy making a ~/.my_login_ctl.d that will contain the means
to log in with and without guix profiles visible, and PATH etc set
alternately. The idea is so I can just use touch to select features
implemented as files to be sourced from ~/.my_login_ctl.d/my_login_ctl
which I'll call from ~/.bash_profile. (~/.bashrc is also modified),
and then log in and get guix and Shepherd/herd etc -- or not.

I'm hoping this will help me debug differences between plain ArchLinux
and the latter with guix binarily installed, with and w/o Shepherd/herd also.
as I don't expect my problems of /usr vs /gnu to go away for a while :-)

BTW, I don't want to define a whole different /home/me_for_alternate_mode,
I want to switch from console to console with Alt-Fx and start a new mode
at worst by touching a file or two and logging out and logging back in.)
--Ignorable note about that:--

If the ip number to guix.gnu.org is fixed and public, maybe I
could try putting it in /etc/hosts ?

If there is no objection, I'd like to try that.
TIA if posting the ip number, or explaining why not ;-)
--
Regards,
Bengt Richter

bug#37244: Icecat Audio Issues

[sirgazil via Bug reports for GNU Guix]

I'm not sure, but this could be related to playing media files with DRM. 

If I recall correctly, last year, when I visited any news post on 
https://www3.nhk.or.jp/news/easy/ on Debian 9 using Firefox ESR, the browser 
would ask me to enable DRM. If I answered NO, then I would see the

“Your browser does not support the playback of this video. 
 Please try using a different browser.”

message (or a similar message) instead of videos, and the audio player would 
display blank (the player that should show up when clicking the big dark blue 
button that says ニュースを聞く). If I enabled DRM, the media would play fine.

Visiting the same website now that I use IceCat on the Guix system I get the 
distorted sound in videos and no audio player.

I wonder if people using IceCat in other distributions have the same problem. I 
was going to report this issue to Gnuzilla, but it seems their mailing list is 
not very active.


---
https://sirgazil.bitbucket.io/

bug#37501: [core-updates] Entropy starvation during boot

[Ludovic Courtès]

Ludovic Courtès  skribis:

> I read some of these, and our ‘urandom-seed-service-type’ has the same
> bug as .  Namely, we
> write the previous seed to /dev/urandom but we don’t credit the
> entropy.

Now that I think about it, ‘urandom-seed’ normally contributes 512 bytes
of entropy, but immediately after it *consumes* 512 bytes of entropy:

  ;; Immediately refresh the seed in case the system doesn't
  ;; shut down cleanly.
  (call-with-input-file "/dev/urandom"
(lambda (urandom)
  (let ((previous-umask (umask #o077))
(buf (make-bytevector 512)))
(mkdir-p (dirname #$%random-seed-file))
(get-bytevector-n! urandom buf 0 512)
(call-with-output-file #$%random-seed-file
  (lambda (seed)
(put-bytevector seed buf)))
(umask previous-umask

This comes from commit 71cb237a7d98dafda7dfbb5f3ba7c68463310383 by Leo.

What about deleting the seed instead of populating it right at boot
time?

That way, we would actually have entropy available at boot time.  In
case of a crash, the system may lack entropy upon reboot, but that’s
better than always lacking entropy when booting.

Marius, Leo, WDYT?

(If we wanted to go fancy, we could spawn a separate process that will
attempt to refill the seed minutes after the system has booted.)

Thanks,
Ludo’.

bug#37501: [core-updates] Entropy starvation during boot

[Ludovic Courtès]

Ludovic Courtès  skribis:

> +  (let ((bits (* 8 (stat:size (stat seed)
> +(add-to-entropy-count urandom bits)))

Oh we also need to do that below, when reading from /dev/hwrng:

(when buf
  (call-with-output-file "/dev/urandom"
(lambda (urandom)
  (put-bytevector urandom buf)
  (let ((bits (* 8 (bytevector-length buf
(add-to-entropy-count urandom bits)  ;<- here

Ludo’.

bug#37501: [core-updates] Entropy starvation during boot

[Ludovic Courtès]

Hi Marius,

Marius Bakke  skribis:

> Ludovic Courtès  writes:

[...]

>> I read some of these, and our ‘urandom-seed-service-type’ has the same
>> bug as .  Namely, we
>> write the previous seed to /dev/urandom but we don’t credit the
>> entropy.
>>
>> The attached patch fixes that, and I think it should fix the problem you
>> reported.  Could people give it a try?
>
> Good catch, LGTM.  Unfortunately it does not fix the problem.
>
>> I’m interested in seeing the value of
>> /proc/sys/kernel/random/entropy_avail with and without this patch right
>> after boot (don’t try it in ‘guix system vm’ because there’s no seed
>> there.)
>
> before -  243
> after  - 2419

Is that with or without sshd running?

Do we have strong evidence that sshd is stuck in getrandom(2)?

That seems weird to me because we use #:pid-file for sshd, and thus
either sshd produces its PID file and we’re done (‘ssh-daemon’ is
considered started and life goes on), or sshd fails to produce its PID
file within 15 seconds and we kill it and consider that ‘ssh-daemon’
failed to start.

This only way this can hang is if sshd calls getrandom(2) before
daemonizing.

Looking at ‘main’ in sshd.c, I see:

  seed_rng();
  […]
  already_daemon = daemonized();

which I think means sshd indeed calls getrandom(2) before it has forked.
That explains the situation.  :-/

(‘seed_rng’ uses ‘RAND_status’ from OpenSSL, which supports several
methods but presumably defaults to getrandom(2)?)

> I don't know why this change was insufficient.  Perhaps the kernel
> does not consider such a seed alone trustworthy enough?  I also tried to
> increase the seed size to no avail.

Can you try to do:

  (add-to-entropy-count urandom (expt 2 17))

to see if that changes anything at all?

I checked with strace and the RNDADDTOENTCNT binding seems to be passing
its argument as expected.

> I found this patch in the 5.4 kernel tree after reading the commit log
> of random.c:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f2dc2798b81531fd93a3b9b7c39da47ec689e55
>
> ...which *does* solve the problem.
>
> The comments in the merge commit suggests that it is not necessarily a
> good solution, so I think we should let it "settle" a bit upstream
> before pushing it.  It does look rather sledgehammer-y...
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f2dc2798b81531fd93a3b9b7c39da47ec689e55
>
> Thoughts?

If it has to be that way, we can use this patch and we can always remove
it later if we have a better solution.

At any rate, I’d rather not block ‘core-updates’ any longer.

Thoughts?

Thanks for investigating!

Ludo’.

bug#37616: Libgcrypt warning: missing initialization

[Hartmut Goebel]

Hi,

the system logs for guix show this error:

guile: Libgcrypt warning: missing initialization - please fix the
application

Full log:

systemd[1]: Started Build daemon for GNU Guix.
guix-daemon[28968]: accepted connection from pid 28973, user nobody
guix-daemon[28968]: accepted connection from pid 28990, user hartmut
guix-daemon[28968]: spurious SIGPOLL
guile[28999]: Libgcrypt warning: missing initialization - please fix the
application
guix-daemon[28968]: SIGPOLL
guix-daemon[28968]: unexpected build daemon error: interrupted by the user

Build like this:

$ su -
# guix environment guix
# guix pull -commit=ccbc1c5eb2
# guix package --fallback -u
# grep ExecStart= /etc/systemd/system/guix-daemon.service
ExecStart=/usr/local/sbin/guix-daemon --build-users-group=guixbuild
--substitute-urls="https://ci.guix.gnu.org;
# /usr/local/sbin/guix-daemon --version
guix-daemon (GNU Guix) 1.0.1-6.0ed97e6

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#37347: 'guix environment' fails after trying to follow the steps from "Running Guix Before It Is Installed" page

[Jelle Licht]

Bengt Richter  writes:

> [snip]
> ...
> [19:40 ~/bs]$ ping guix.gnu.org
> ping: guix.gnu.org: Name or service not known
I actually have this sometimes as well. Are you on a less-than-stellar
WiFi-connection perhaps? I noticed the default (nscd?) configuration on
Guix systems caches 'negative' results for quite a while.

Could you try this command again after issuing:
`sudo herd invalidate nscd hosts'?

HTH!
- Jelle

bug#37569: Mount does not honor 'user' option.

[Diego Nicola Barbato]

Diego Nicola Barbato  writes:

> Hello Danny,
>
> Danny Milosavljevic  writes:
>
>> Hmm, how is that solved with other distributions?  Is "mount" suid root 
>> there?
>
> Indeed, in Debian both mount and umount are suid root:
>
>   $ stat -c "%a %U:%G %n" /bin/*mount
>   4755 root:root /bin/fusermount
>   4755 root:root /bin/mount
>   4755 root:root /bin/umount

I've tried adding "mount" and "umount" to `setuid-programs' in my
operating-system config:

--8<---cut here---start->8---
(setuid-programs (cons*   
  #~(string-append #$util-linux "/bin/mount") 
  #~(string-append #$util-linux "/bin/umount")
  %setuid-programs))
--8<---cut here---end--->8---

Mounting as an unprivileged user now works as expected (even the fancy
9p stuff).  Is there any rationale for not adding "mount" and "umount"
to `%setuid-programs' by default?

Thanks,

Diego