[Guix Info][7.1.5] Should warn user about losing Internet or DNS connection

DoneSubmitted by Eus.
Details
2 participants
  • Eus
  • Ludovic Courtès
Owner
unassigned
Severity
normal
E
(address . bug-guix@gnu.org)
102661467893195@web4g.yandex.ru
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
L
L
Ludovic Courtès wrote on 15 Jul 2016 18:10
(name . Eus)(address . eus@member.fsf.org)(address . 23910@debbugs.gnu.org)
87inw6zxtw.fsf@gnu.org
Hi!
Eus <eus@member.fsf.org> skribis:
Toggle quote (11 lines)> 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 losingInternet connection. This is outside the scope of GuixSD, in a way.
WDYT?
However, in the past people reported that nscd, the name service cachedaemon, would sometimes fail without any good reason. If you think thatis the case, then this is definitely a bug that we should beaddressing.
Thanks,Ludo’.
E
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 23910@debbugs.gnu.org)
CAHXRqWJRUE0fKDcv947GYLZ0iNkWwqeqEVEaDP8F=hZjBS3=fw@mail.gmail.com
On Fri, Jul 15, 2016 at 11:10 PM, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (18 lines)> Hi!>> Eus <eus@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
Toggle quote (5 lines)> Internet connection. This is outside the scope of GuixSD, in a way.>> WDYT?>
I suggest that to balance the suggestion of using "--fallback" option whenguix fails to download some substitutes.So, what about if instead of warning in the installation doc, the guixsuggestion on using "--fallback" option also carries information on thepossibility of lost network connection?
However, in the past people reported that nscd, the name service cache
Toggle quote (5 lines)> 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 moreverbose?
Thanks,
Toggle quote (3 lines)> Ludo’.>
--Best regards,Eus
Attachment: file
L
L
Ludovic Courtès wrote on 16 Jul 2016 12:41
(name . Eus)(address . eus@member.fsf.org)(address . 23910@debbugs.gnu.org)
87poqdc1bz.fsf@gnu.org
Eus <eus@member.fsf.org> skribis:
Toggle quote (2 lines)> On Fri, Jul 15, 2016 at 11:10 PM, Ludovic Courtès <ludo@gnu.org> wrote:
[...]
Toggle quote (8 lines)> 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 failuresthat happened when the Internet connection was missing, which madesubsequent lookups fail even though networking was back up:
http://bugs.gnu.org/22209
I believe this was fixed by commitc96ba2cf5efc0ee5c10f0a49aeaa9a45a84de7ed.
It would be great if you could check whether the problem isreproducible, even with a stable connection.
If it is indeed reproducible, then you could try running theinstallation after turning nscd off with:
herd stop nscd
Thanks,Ludo’.
L
L
Ludovic Courtès wrote on 9 Sep 2016 16:35
(name . Eus)(address . eus@member.fsf.org)(address . 23910@debbugs.gnu.org)
87a8fh5eft.fsf@gnu.org
Hello,
ludo@gnu.org (Ludovic Courtès) skribis:
Toggle quote (33 lines)> Eus <eus@member.fsf.org> skribis:>>> On Fri, Jul 15, 2016 at 11:10 PM, Ludovic Courtès <ludo@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 stillexperience these problems?
Thanks in advance,Ludo’.
L
L
Ludovic Courtès wrote on 9 Sep 2016 16:35
control message for bug #23910
(address . control@debbugs.gnu.org)
878tv15efl.fsf@gnu.org
tags 23910 moreinfo
E
Re: bug#23910: [Guix Info][7.1.5] Should warn user about losing Internet or DNS connection
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 23910@debbugs.gnu.org)
CAHXRqW+H3o+yeEQnqhK7AqSnTAkyQQPXsHFexAVzfgYVL8N+TQ@mail.gmail.com
Hi Ludo!
Sorry for replying just now. I did not try to reproduce the bug back atthat time. So, I took the time yesterday to try to reproduce the bug. And,I cannot reproduce the problem after repeating the following rough stepstwo times with the same bootable disk and machine and network (but theexternal connection to the ISP may have changed in the mean time):
1. Format my /dev/sda82. Swapon my /dev/sda73. mount my /dev/sda8 to /mnt4. herd start cow-store /mnt5. umount /tmp6. mount --bind /mnt/tmp2 /tmp7. ifconfig, wpa_supplicant, dhclient8. guix pull9. 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 freedomdepends on the software controlling those computing devices.
Join free software movement today! It is free as in freedom, not as in freebeer!
Join: http://www.fsf.org/jf?referrer=4445
On Fri, Sep 9, 2016 at 9:35 PM, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (44 lines)> Hello,>> ludo@gnu.org (Ludovic Courtès) skribis:>> > Eus <eus@member.fsf.org> skribis:> >> >> On Fri, Jul 15, 2016 at 11:10 PM, Ludovic Courtès <ludo@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’.>
Attachment: file
L
L
Ludovic Courtès wrote on 13 Sep 2016 11:52
(name . Eus)(address . eus@member.fsf.org)(address . 23910-done@debbugs.gnu.org)
87h99k86um.fsf@gnu.org
Hello!
Eus <eus@member.fsf.org> skribis:
Toggle quote (16 lines)> 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 binariesfor the packages 0.11.0 provides.
Step #6 is also redundant with step #4 (‘herd start cow-store’ make /tmpa bind mount to /mnt/tmp; see gnu/system/install.scm:154.)
Toggle quote (2 lines)> The whole process took just about 100 minutes.
That’s a lot of time.
Toggle quote (2 lines)> So, I cannot reproduce the bug.
Great. Thanks for taking the time to verify!
Ludo’.
Closed
E
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 23910-done@debbugs.gnu.org)
CAHXRqWKcztjZ-YCie-K8VGLMV5EQDrFJ1rfZsiceKnK3dne90w@mail.gmail.com
On Tue, Sep 13, 2016 at 4:52 PM, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (25 lines)> Hello!>> Eus <eus@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 with0.10.0.I have not had the chance to try 0.11.0.

Toggle quote (4 lines)> 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.

Toggle quote (5 lines)> > 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 connectionhere is slow.

Toggle quote (5 lines)> > So, I cannot reproduce the bug.>> Great. Thanks for taking the time to verify!>
Anytime!

Toggle quote (3 lines)> Ludo’.>
--Eus
Attachment: file
Closed
L
L
Ludovic Courtès wrote on 13 Sep 2016 18:17
(name . Eus)(address . eus@member.fsf.org)(address . 23910-done@debbugs.gnu.org)
87k2ef4vwd.fsf@gnu.org
Eus <eus@member.fsf.org> skribis:
Toggle quote (2 lines)> On Tue, Sep 13, 2016 at 4:52 PM, Ludovic Courtès <ludo@gnu.org> wrote:
[...]
Toggle quote (10 lines)>> > 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 configurationyou’re building, and the available binaries.
Hopefully installing 0.11.0 with the desktop kind of config, and withrelatively good Internet connection, takes less time. I haven’t triedto measure though.
Thanks,Ludo’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send email to 23910@debbugs.gnu.org