GNU bug report logs -
#23910
[Guix Info][7.1.5] Should warn user about losing Internet or DNS connection
Previous Next
Reported by: Eus <eus <at> member.fsf.org>
Date: Thu, 7 Jul 2016 12:08:02 UTC
Severity: normal
Tags: moreinfo
Done: ludo <at> gnu.org (Ludovic Courtès)
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 23910 in the body.
You can then email your comments to 23910 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#23910
; Package
guix
.
(Thu, 07 Jul 2016 12:08:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Eus <eus <at> member.fsf.org>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Thu, 07 Jul 2016 12:08:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi!
When downloading substitutes via wireless connection, several times I encountered a case where the host name of hydra cannot be resolved. So, the "guix system init" fails and suggests the use of "--fallback" option. However, rather than continuing with "guix system --fallback init", one should actually try "dhclient -v WIRELESS_INTERFACE_NAME" first and then do "guix system init" again instead of "guix system --fallback init". My installation process is now going well with this strategy. Previously, I kept using "--fallback" that didn't solve the problem due to network connectivity error because using "--fallback" brought up built errors.
--
Best regards,
Eus (FSF member #4445)
In this digital era, where computing technology is pervasive, your freedom depends on the software controlling those computing devices.
Join free software movement today! It is free as in freedom, not as in free beer!
Join: http://www.fsf.org/jf?referrer=4445
Information forwarded
to
bug-guix <at> gnu.org
:
bug#23910
; Package
guix
.
(Fri, 15 Jul 2016 16:11:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 23910 <at> debbugs.gnu.org (full text, mbox):
Hi!
Eus <eus <at> member.fsf.org> skribis:
> When downloading substitutes via wireless connection, several times I
> encountered a case where the host name of hydra cannot be
> resolved. So, the "guix system init" fails and suggests the use of
> "--fallback" option. However, rather than continuing with "guix system
> --fallback init", one should actually try "dhclient -v
> WIRELESS_INTERFACE_NAME" first and then do "guix system init" again
> instead of "guix system --fallback init". My installation process is
> now going well with this strategy. Previously, I kept using
> "--fallback" that didn't solve the problem due to network connectivity
> error because using "--fallback" brought up built errors.
Are you installing GuixSD 0.10.0?
I would personally find it weird to warn about the possibility of losing
Internet connection. This is outside the scope of GuixSD, in a way.
WDYT?
However, in the past people reported that nscd, the name service cache
daemon, would sometimes fail without any good reason. If you think that
is the case, then this is definitely a bug that we should be
addressing.
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#23910
; Package
guix
.
(Sat, 16 Jul 2016 03:22:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 23910 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Jul 15, 2016 at 11:10 PM, Ludovic Courtès <ludo <at> gnu.org> wrote:
> Hi!
>
> Eus <eus <at> member.fsf.org> skribis:
>
> > When downloading substitutes via wireless connection, several times I
> > encountered a case where the host name of hydra cannot be
> > resolved. So, the "guix system init" fails and suggests the use of
> > "--fallback" option. However, rather than continuing with "guix system
> > --fallback init", one should actually try "dhclient -v
> > WIRELESS_INTERFACE_NAME" first and then do "guix system init" again
> > instead of "guix system --fallback init". My installation process is
> > now going well with this strategy. Previously, I kept using
> > "--fallback" that didn't solve the problem due to network connectivity
> > error because using "--fallback" brought up built errors.
>
> Are you installing GuixSD 0.10.0?
>
Yes.
I would personally find it weird to warn about the possibility of losing
> Internet connection. This is outside the scope of GuixSD, in a way.
>
> WDYT?
>
I suggest that to balance the suggestion of using "--fallback" option when
guix fails to download some substitutes.
So, what about if instead of warning in the installation doc, the guix
suggestion on using "--fallback" option also carries information on the
possibility of lost network connection?
However, in the past people reported that nscd, the name service cache
> daemon, would sometimes fail without any good reason. If you think that
> is the case, then this is definitely a bug that we should be
> addressing.
>
That is likely. How to debug nscd? Any option perhaps to make it more
verbose?
Thanks,
> Ludo’.
>
--
Best regards,
Eus
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#23910
; Package
guix
.
(Sat, 16 Jul 2016 10:42:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 23910 <at> debbugs.gnu.org (full text, mbox):
Eus <eus <at> member.fsf.org> skribis:
> On Fri, Jul 15, 2016 at 11:10 PM, Ludovic Courtès <ludo <at> gnu.org> wrote:
[...]
> However, in the past people reported that nscd, the name service cache
>> daemon, would sometimes fail without any good reason. If you think that
>> is the case, then this is definitely a bug that we should be
>> addressing.
>>
>
> That is likely.
What makes you think so?
The problem we had in the past is that nscd would cache lookup failures
that happened when the Internet connection was missing, which made
subsequent lookups fail even though networking was back up:
http://bugs.gnu.org/22209
I believe this was fixed by commit
c96ba2cf5efc0ee5c10f0a49aeaa9a45a84de7ed.
It would be great if you could check whether the problem is
reproducible, even with a stable connection.
If it is indeed reproducible, then you could try running the
installation after turning nscd off with:
herd stop nscd
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#23910
; Package
guix
.
(Fri, 09 Sep 2016 14:36:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 23910 <at> debbugs.gnu.org (full text, mbox):
Hello,
ludo <at> gnu.org (Ludovic Courtès) skribis:
> Eus <eus <at> member.fsf.org> skribis:
>
>> On Fri, Jul 15, 2016 at 11:10 PM, Ludovic Courtès <ludo <at> gnu.org> wrote:
>
> [...]
>
>> However, in the past people reported that nscd, the name service cache
>>> daemon, would sometimes fail without any good reason. If you think that
>>> is the case, then this is definitely a bug that we should be
>>> addressing.
>>>
>>
>> That is likely.
>
> What makes you think so?
>
> The problem we had in the past is that nscd would cache lookup failures
> that happened when the Internet connection was missing, which made
> subsequent lookups fail even though networking was back up:
>
> http://bugs.gnu.org/22209
>
> I believe this was fixed by commit
> c96ba2cf5efc0ee5c10f0a49aeaa9a45a84de7ed.
>
> It would be great if you could check whether the problem is
> reproducible, even with a stable connection.
>
> If it is indeed reproducible, then you could try running the
> installation after turning nscd off with:
>
> herd stop nscd
Did you have a change to try and install 0.11.0? Do you still
experience these problems?
Thanks in advance,
Ludo’.
Added tag(s) moreinfo.
Request was from
ludo <at> gnu.org (Ludovic Courtès)
to
control <at> debbugs.gnu.org
.
(Fri, 09 Sep 2016 14:36:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#23910
; Package
guix
.
(Tue, 13 Sep 2016 08:48:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 23910 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludo!
Sorry for replying just now. I did not try to reproduce the bug back at
that time. So, I took the time yesterday to try to reproduce the bug. And,
I cannot reproduce the problem after repeating the following rough steps
two times with the same bootable disk and machine and network (but the
external connection to the ISP may have changed in the mean time):
1. Format my /dev/sda8
2. Swapon my /dev/sda7
3. mount my /dev/sda8 to /mnt
4. herd start cow-store /mnt
5. umount /tmp
6. mount --bind /mnt/tmp2 /tmp
7. ifconfig, wpa_supplicant, dhclient
8. guix pull
9. guix system --no-grub --keep-failed init /mnt/etc/config.scm /mnt
The whole process took just about 100 minutes.
So, I cannot reproduce the bug.
Thanks.
--
Best regards,
Eus (FSF member #4445)
In this digital era, where computing technology is pervasive, your freedom
depends on the software controlling those computing devices.
Join free software movement today! It is free as in freedom, not as in free
beer!
Join: http://www.fsf.org/jf?referrer=4445
On Fri, Sep 9, 2016 at 9:35 PM, Ludovic Courtès <ludo <at> gnu.org> wrote:
> Hello,
>
> ludo <at> gnu.org (Ludovic Courtès) skribis:
>
> > Eus <eus <at> member.fsf.org> skribis:
> >
> >> On Fri, Jul 15, 2016 at 11:10 PM, Ludovic Courtès <ludo <at> gnu.org> wrote:
> >
> > [...]
> >
> >> However, in the past people reported that nscd, the name service cache
> >>> daemon, would sometimes fail without any good reason. If you think
> that
> >>> is the case, then this is definitely a bug that we should be
> >>> addressing.
> >>>
> >>
> >> That is likely.
> >
> > What makes you think so?
> >
> > The problem we had in the past is that nscd would cache lookup failures
> > that happened when the Internet connection was missing, which made
> > subsequent lookups fail even though networking was back up:
> >
> > http://bugs.gnu.org/22209
> >
> > I believe this was fixed by commit
> > c96ba2cf5efc0ee5c10f0a49aeaa9a45a84de7ed.
> >
> > It would be great if you could check whether the problem is
> > reproducible, even with a stable connection.
> >
> > If it is indeed reproducible, then you could try running the
> > installation after turning nscd off with:
> >
> > herd stop nscd
>
> Did you have a change to try and install 0.11.0? Do you still
> experience these problems?
>
> Thanks in advance,
> Ludo’.
>
[Message part 2 (text/html, inline)]
Reply sent
to
ludo <at> gnu.org (Ludovic Courtès)
:
You have taken responsibility.
(Tue, 13 Sep 2016 09:53:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Eus <eus <at> member.fsf.org>
:
bug acknowledged by developer.
(Tue, 13 Sep 2016 09:53:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 23910-done <at> debbugs.gnu.org (full text, mbox):
Hello!
Eus <eus <at> member.fsf.org> skribis:
> Sorry for replying just now. I did not try to reproduce the bug back at
> that time. So, I took the time yesterday to try to reproduce the bug. And,
> I cannot reproduce the problem after repeating the following rough steps
> two times with the same bootable disk and machine and network (but the
> external connection to the ISP may have changed in the mean time):
>
> 1. Format my /dev/sda8
> 2. Swapon my /dev/sda7
> 3. mount my /dev/sda8 to /mnt
> 4. herd start cow-store /mnt
> 5. umount /tmp
> 6. mount --bind /mnt/tmp2 /tmp
> 7. ifconfig, wpa_supplicant, dhclient
> 8. guix pull
> 9. guix system --no-grub --keep-failed init /mnt/etc/config.scm /mnt
Normally step #8 can be omitted because hydra.gnu.org still has binaries
for the packages 0.11.0 provides.
Step #6 is also redundant with step #4 (‘herd start cow-store’ make /tmp
a bind mount to /mnt/tmp; see gnu/system/install.scm:154.)
> The whole process took just about 100 minutes.
That’s a lot of time.
> So, I cannot reproduce the bug.
Great. Thanks for taking the time to verify!
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#23910
; Package
guix
.
(Tue, 13 Sep 2016 15:06:01 GMT)
Full text and
rfc822 format available.
Message #30 received at 23910-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Sep 13, 2016 at 4:52 PM, Ludovic Courtès <ludo <at> gnu.org> wrote:
> Hello!
>
> Eus <eus <at> member.fsf.org> skribis:
>
> > Sorry for replying just now. I did not try to reproduce the bug back at
> > that time. So, I took the time yesterday to try to reproduce the bug.
> And,
> > I cannot reproduce the problem after repeating the following rough steps
> > two times with the same bootable disk and machine and network (but the
> > external connection to the ISP may have changed in the mean time):
> >
> > 1. Format my /dev/sda8
> > 2. Swapon my /dev/sda7
> > 3. mount my /dev/sda8 to /mnt
> > 4. herd start cow-store /mnt
> > 5. umount /tmp
> > 6. mount --bind /mnt/tmp2 /tmp
> > 7. ifconfig, wpa_supplicant, dhclient
> > 8. guix pull
> > 9. guix system --no-grub --keep-failed init /mnt/etc/config.scm /mnt
>
> Normally step #8 can be omitted because hydra.gnu.org still has binaries
> for the packages 0.11.0 provides.
>
Oh, I retried everything with 0.10.0 since I had the problem back then with
0.10.0.
I have not had the chance to try 0.11.0.
> Step #6 is also redundant with step #4 (‘herd start cow-store’ make /tmp
> a bind mount to /mnt/tmp; see gnu/system/install.scm:154.)
>
Thank you for letting me know this. That will save my time in the future.
> > The whole process took just about 100 minutes.
>
> That’s a lot of time.
>
Really? What is your approximate time?
Perhaps it is because I used 0.10.0, guix pull, and my Internet connection
here is slow.
> > So, I cannot reproduce the bug.
>
> Great. Thanks for taking the time to verify!
>
Anytime!
> Ludo’.
>
--
Eus
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#23910
; Package
guix
.
(Tue, 13 Sep 2016 16:18:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 23910-done <at> debbugs.gnu.org (full text, mbox):
Eus <eus <at> member.fsf.org> skribis:
> On Tue, Sep 13, 2016 at 4:52 PM, Ludovic Courtès <ludo <at> gnu.org> wrote:
[...]
>> > The whole process took just about 100 minutes.
>>
>> That’s a lot of time.
>>
>
> Really? What is your approximate time?
>
> Perhaps it is because I used 0.10.0, guix pull, and my Internet connection
> here is slow.
Of course it’s a function of the Internet bandwidth, the configuration
you’re building, and the available binaries.
Hopefully installing 0.11.0 with the desktop kind of config, and with
relatively good Internet connection, takes less time. I haven’t tried
to measure though.
Thanks,
Ludo’.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 12 Oct 2016 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 253 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.