GNU bug report logs -
#35622
Ran into a bug in the new graphical installer on WiFi setup
Previous Next
Reported by: Hugo Saavedra <hm <at> listen.systems>
Date: Tue, 7 May 2019 18:26:01 UTC
Severity: important
Merged with 35620
Done: Mathieu Othacehe <m.othacehe <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 35622 in the body.
You can then email your comments to 35622 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#35622
; Package
guix
.
(Tue, 07 May 2019 18:26:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Hugo Saavedra <hm <at> listen.systems>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Tue, 07 May 2019 18:26:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Guix team,
Thanks for your work on GuixSD. I was excited to try out the new graphical
installer, but ran into a bug while setting up WiFi.
I've uploaded photos of the stacktrace for you to take a look at. This is
running on a Dell Inspiron 11 3000 series.
https://imgur.com/a/qcwgNXr
Also, upon clicking "OK" I'm taken back to the original menu of the
installer. Going through the choices again, the installer cannot detect a
hard drive as it could before.
Let me know if I can help in any way or if you need more information.
--
*Hugo Saavedra*
Listen Systems <http://listen.systems>
c: 818-356-6664
<http://listen.systems>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35622
; Package
guix
.
(Tue, 07 May 2019 22:04:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 35622 <at> debbugs.gnu.org (full text, mbox):
Hi Hugo,
Hugo Saavedra <hm <at> listen.systems> writes:
> Thanks for your work on GuixSD. I was excited to try out the new
> graphical installer, but ran into a bug while setting up WiFi.
I'm sorry to hear it. Thanks very much for the report.
> I've uploaded photos of the stacktrace for you to take a look at. This
> is running on a Dell Inspiron 11 3000 series.
>
> https://imgur.com/a/qcwgNXr
From the backtrace, I see that 'string-null?' was applied to #f, and I
guess it was the 'string-null?' called from the 'wifi-services'
procedure in (gnu installer newt wifi), here:
(define (wifi-services)
"Return all the connman services of wifi type."
(let ((services (connman-services)))
(filter (lambda (service)
(and (string=? (service-type service) "wifi")
(not (string-null? (service-name service)))))
services)))
It seems that one of the services returned by (connman-services) had #f
as its 'service-name'. The backtrace includes a (truncated) display of
the service in question:
#<<service> name: #f type: "wifi" path: "wifi_4cbb58…>
Looking at 'connman-services', it appears that in this case, the 'keys',
as returned by 'parse-keys' in (gnu installer connman), did not have a
"Name" association, or else its right-hand side was #f.
It would be good if someone more familiar with this code would
investigate further.
Thanks,
Mark
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35622
; Package
guix
.
(Wed, 08 May 2019 13:08:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 35622 <at> debbugs.gnu.org (full text, mbox):
Hello,
Mark H Weaver <mhw <at> netris.org> skribis:
> Hugo Saavedra <hm <at> listen.systems> writes:
>
>> Thanks for your work on GuixSD. I was excited to try out the new
>> graphical installer, but ran into a bug while setting up WiFi.
>
> I'm sorry to hear it. Thanks very much for the report.
>
>> I've uploaded photos of the stacktrace for you to take a look at. This
>> is running on a Dell Inspiron 11 3000 series.
>>
>> https://imgur.com/a/qcwgNXr
>
> From the backtrace, I see that 'string-null?' was applied to #f, and I
> guess it was the 'string-null?' called from the 'wifi-services'
> procedure in (gnu installer newt wifi), here:
Could you post the image here? imgur.com says it’s “over capacity” and
I can’t see the image right now.
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35622
; Package
guix
.
(Wed, 08 May 2019 15:52:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 35622 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Sorry about that -- I just posted them on my own server here
https://topologi.es/files/d/5e38edf49f744b099d70/?p=/&mode=grid
On Wed, May 8, 2019 at 7:07 AM Ludovic Courtès <ludo <at> gnu.org> wrote:
> Hello,
>
> Mark H Weaver <mhw <at> netris.org> skribis:
>
> > Hugo Saavedra <hm <at> listen.systems> writes:
> >
> >> Thanks for your work on GuixSD. I was excited to try out the new
> >> graphical installer, but ran into a bug while setting up WiFi.
> >
> > I'm sorry to hear it. Thanks very much for the report.
> >
> >> I've uploaded photos of the stacktrace for you to take a look at. This
> >> is running on a Dell Inspiron 11 3000 series.
> >>
> >> https://imgur.com/a/qcwgNXr
> >
> > From the backtrace, I see that 'string-null?' was applied to #f, and I
> > guess it was the 'string-null?' called from the 'wifi-services'
> > procedure in (gnu installer newt wifi), here:
>
> Could you post the image here? imgur.com says it’s “over capacity” and
> I can’t see the image right now.
>
> Ludo’.
>
--
*Hugo Saavedra*
Listen Systems <http://listen.systems>
c: 818-356-6664
<http://listen.systems>
[Message part 2 (text/html, inline)]
Merged 35620 35622.
Request was from
Ludovic Courtès <ludo <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Wed, 08 May 2019 21:55:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35622
; Package
guix
.
(Wed, 08 May 2019 22:10:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 35622 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
Mark H Weaver <mhw <at> netris.org> skribis:
>>From the backtrace, I see that 'string-null?' was applied to #f, and I
> guess it was the 'string-null?' called from the 'wifi-services'
> procedure in (gnu installer newt wifi), here:
>
> (define (wifi-services)
> "Return all the connman services of wifi type."
> (let ((services (connman-services)))
> (filter (lambda (service)
> (and (string=? (service-type service) "wifi")
> (not (string-null? (service-name service)))))
> services)))
>
> It seems that one of the services returned by (connman-services) had #f
> as its 'service-name'. The backtrace includes a (truncated) display of
> the service in question:
>
> #<<service> name: #f type: "wifi" path: "wifi_4cbb58…>
>
> Looking at 'connman-services', it appears that in this case, the 'keys',
> as returned by 'parse-keys' in (gnu installer connman), did not have a
> "Name" association, or else its right-hand side was #f.
I’ve tried “connmanctl services xyz” on the bare metal with an actual
WiFi device. For me there’s always a “Name = something” property, and
the “something” appears to be the SSID of the access point.
Could it be that the access point does not advertise an SSID, and thus
its “Name” property is the empty string or is missing altogether?
It could be that changing the ‘parse-keys’ regexp as shown below would
solve the problem for cases where “connmanctl services xyz” writes
literally:
Name =
WDYT, Mathieu?
Hugo, would it be an option for you to (1) boot the installation image,
and (2) to grab the output of this command:
for s in $(connmanctl services | cut -c 25- | grep wifi) ; do connmanctl service $s ; done
Note that it will provide information about the WiFi networks around
you, which you may or may not want to share publicly.
Thanks,
Ludo’.
[Message part 2 (text/x-patch, inline)]
diff --git a/gnu/installer/connman.scm b/gnu/installer/connman.scm
index ef8cca3952..b6e3dfd909 100644
--- a/gnu/installer/connman.scm
+++ b/gnu/installer/connman.scm
@@ -170,7 +170,7 @@ to be translated."
Return the corresponding association list of '((KEY . VALUE) (KEY2 . VALUE2)
...) elements."
- (let ((key-regex (make-regexp "([^ ]+) = ([^$]+)")))
+ (let ((key-regex (make-regexp "([^ ]+) = ([^$]*)")))
(map (lambda (key)
(let ((match-key (regexp-exec key-regex key)))
(cons (match:substring match-key 1)
Information forwarded
to
bug-guix <at> gnu.org
:
bug#35622
; Package
guix
.
(Wed, 08 May 2019 22:33:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 35622 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> skribis:
> I’ve tried “connmanctl services xyz” on the bare metal with an actual
> WiFi device. For me there’s always a “Name = something” property, and
> the “something” appears to be the SSID of the access point.
>
> Could it be that the access point does not advertise an SSID, and thus
> its “Name” property is the empty string or is missing altogether?
I tried to reproduce that in a VM by running hostapd and using the neat
‘mac80211_hwsim’ kernel module.
However, hostapd’s config file doesn’t allow empty SSIDs. So I set the
SSID to “ ” (a single space), but that’s correctly handled by the
installer.
Ludo’.
Severity set to 'important' from 'normal'
Request was from
Ludovic Courtès <ludo <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Wed, 08 May 2019 22:33:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 26 Jun 2019 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 306 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.