Bug#851790: installation-reports: DNS not working

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#851790: installation-reports: DNS not working

Wookey-2
Package: installation-reports
Severity: grave
Tags: d-i
Justification: renders package unusable

Dear Maintainer,

The current installer, with the new 4.9 kernel, is unable to resolve
domains, so is quite seriously broken.

This was noted during install on an arm64 gigabyte MP30-AR1
desktop/server, when choose-mirror failed, but it soon became clear
that DNS was not working.

Testing on an x86 VM with the same daily image (18th Jan 2017) found
the same problem. Going back to the rc1 installer image (4.8 kernel)
it works OK.

Tests showed that the network came up fine and things are pingable by IP, but not name:
# ping wookware.org                                                          
ping: bad address 'wookware.org'
# ping 93.93.131.118
PING 93.93.131.118 (93.93.131.118): 56 data bytes
64 bytes from 93.93.131.118: seq=0 ttl=50 time=19.892 ms

similarly the failing line from the choose-mirror log works if an address is inserted:
Jan 18 17:04:11 choose-mirror[31201]: DEBUG: command: wget --no-verbose http://debian-mirror.cambridge.arm.com/debian/dists/stretch/Release -O - | grep -E '^(Suite|Codename|Architectures):'                                                  
Jan 18 17:04:11 choose-mirror[31201]: WARNING **: mirror does not support the specified release (stretch)

# wget --no-verbose http://debian-mirror.cambridge.arm.com/debian/dists/stretch/Release -O - | grep -E '^(Suite|Codename|Architectures):'
wget: unable to resolve host address 'debian-mirror.cambridge.arm.com'

# wget --no-verbose http://10.1.194.51/debian/dists/stretch/Release -O - | gre
p -E '^(Suite|Codename|Architectures):'
Suite: testing
Codename: stretch
Architectures: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
2017-01-18 17:47:12 URL:http://10.1.194.51/debian/dists/stretch/Release [177979/177979] -> "-" [1]

resolv.conf is as expected:
search cambridge.arm.com
nameserver 10.1.2.24
nameserver 10.1.2.23

(adding nameserver 8.8.8.8 makes no difference)

Watching packets go by when doing a VM install it is clear that the
local DNS server returns the correct response, but this is being ignored
or lost by the D-I initrd.

attached is an strace of strace ping wookware.org > /tmp/tracelog 2>&1

That gets a response from the server OK, but then goes on to ask the
other one. a working strace then uses the provided IP address. So
there is nothing obviously going wrong there.

-- Package-specific info:

Boot method: USB
Image version: http://gemmei.acc.umu.se/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/debian-testing-arm64-netinst.iso
Date: <Date and time of the install>

Machine: Gigabyte MP30-AR1, (and x86 VM)
Partitions: (default guided LVM, with separate /home chosen)


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:           [O]
Detect network card:    [O]
Configure network:      [O]
Detect CD:              [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:    [O]
Detect hard drives:     [O]
Partition hard drives:  [O]
Install base system:    [E]
Install tasks:          [ ]
Install boot loader:    [ ]
Overall install:        [ ]

Comments/Problems:

Worked as expected until DNS needed

--

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to [hidden email].

removed automatic info as this report written on different machine fro install.

strace.log (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#851790: installation-reports: DNS not working

Steve McIntyre
On Wed, Jan 18, 2017 at 06:43:33PM +0000, Wookey wrote:
>Package: installation-reports
>Severity: grave
>Tags: d-i
>Justification: renders package unusable
>
>Dear Maintainer,
>
>The current installer, with the new 4.9 kernel, is unable to resolve
>domains, so is quite seriously broken.

hosts, not domains, but yes...

>This was noted during install on an arm64 gigabyte MP30-AR1
>desktop/server, when choose-mirror failed, but it soon became clear
>that DNS was not working.
>
>Testing on an x86 VM with the same daily image (18th Jan 2017) found
>the same problem. Going back to the rc1 installer image (4.8 kernel)
>it works OK.
>
>Tests showed that the network came up fine and things are pingable by IP, but not name:
># ping wookware.org                                                          
>ping: bad address 'wookware.org'
># ping 93.93.131.118
>PING 93.93.131.118 (93.93.131.118): 56 data bytes
>64 bytes from 93.93.131.118: seq=0 ttl=50 time=19.892 ms
>
>similarly the failing line from the choose-mirror log works if an address is inserted:
>Jan 18 17:04:11 choose-mirror[31201]: DEBUG: command: wget --no-verbose http://debian-mirror.cambridge.arm.com/debian/dists/stretch/Release -O - | grep -E '^(Suite|Codename|Architectures):'                                                  
>Jan 18 17:04:11 choose-mirror[31201]: WARNING **: mirror does not support the specified release (stretch)
>
># wget --no-verbose http://debian-mirror.cambridge.arm.com/debian/dists/stretch/Release -O - | grep -E '^(Suite|Codename|Architectures):'
>wget: unable to resolve host address 'debian-mirror.cambridge.arm.com'
>
># wget --no-verbose http://10.1.194.51/debian/dists/stretch/Release -O - | gre
>p -E '^(Suite|Codename|Architectures):'
>Suite: testing
>Codename: stretch
>Architectures: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
>2017-01-18 17:47:12 URL:http://10.1.194.51/debian/dists/stretch/Release [177979/177979] -> "-" [1]
>
>resolv.conf is as expected:
>search cambridge.arm.com
>nameserver 10.1.2.24
>nameserver 10.1.2.23
>
>(adding nameserver 8.8.8.8 makes no difference)
>
>Watching packets go by when doing a VM install it is clear that the
>local DNS server returns the correct response, but this is being ignored
>or lost by the D-I initrd.

For the sake of completeness, I can confirm that the same problem
shows up when running on a different network too. I also see this
using the oldest amd64 daily I can grab (from 2017-01-17) which has
the 4.9 kernel too.

I'll see if I can debug this, but I'm not sure where to look straight
away.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"Managing a volunteer open source project is a lot like herding
 kittens, except the kittens randomly appear and disappear because they
 have day jobs." -- Matt Mackall

Reply | Threaded
Open this post in threaded view
|

Bug#851790: installation-reports: DNS not working

Cyril Brulebois-4
Steve McIntyre <[hidden email]> (2017-01-18):
> For the sake of completeness, I can confirm that the same problem
> shows up when running on a different network too. I also see this
> using the oldest amd64 daily I can grab (from 2017-01-17) which has
> the 4.9 kernel too.
>
> I'll see if I can debug this, but I'm not sure where to look straight
> away.

You can try downgrading the kernel, but I'd usually look at glibc first
for DNS related issues.


KiBi.

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#851790: installation-reports: DNS not working

Cyril Brulebois-4
Cyril Brulebois <[hidden email]> (2017-01-19):
> You can try downgrading the kernel, but I'd usually look at glibc first
> for DNS related issues.

Summing up things from IRC:
 - in an uptodate sid chroot (both development version and minimal one
   with daily-build script): no DNS issues with the generated mini.iso
   (amd64, tested within stable's kvm on amd64). My image was also
   tested successfully by Steve, so not a setup issue.

 - I can reproduce the issue with dailies from 2017-01-18, and from
   2017-01-19 (I picked it in advance during its build on barriere).

 - I can reproduce the issue in the above mentioned sid chroot if
   I downgrade these packages to testing's version (-9 → -8):
     sudo apt-get install libc6:amd64=2.24-8 libc6-dev:amd64=2.24-8 libc-dev-bin=2.24-8

 - The older set of libc* packages is installed in barriere's current
   amd64 sid chroot, too.

 - Steve could only produce broken images when building locally, until
   he upgraded his libc* packages as well.


→ Copying glibc@packages for the time being, even I suspect this will
  likely disappear entirely once -9 propagates…


KiBi.

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#851790: installation-reports: DNS not working

Cyril Brulebois-4
Cyril Brulebois <[hidden email]> (2017-01-19):

> Summing up things from IRC:
>  - in an uptodate sid chroot (both development version and minimal one
>    with daily-build script): no DNS issues with the generated mini.iso
>    (amd64, tested within stable's kvm on amd64). My image was also
>    tested successfully by Steve, so not a setup issue.
>
>  - I can reproduce the issue with dailies from 2017-01-18, and from
>    2017-01-19 (I picked it in advance during its build on barriere).
>
>  - I can reproduce the issue in the above mentioned sid chroot if
>    I downgrade these packages to testing's version (-9 → -8):
>      sudo apt-get install libc6:amd64=2.24-8 libc6-dev:amd64=2.24-8 libc-dev-bin=2.24-8
>
>  - The older set of libc* packages is installed in barriere's current
>    amd64 sid chroot, too.
>
>  - Steve could only produce broken images when building locally, until
>    he upgraded his libc* packages as well.
And since Steve was wondering how we could release something for Stretch
RC 1 with that… I've just confirmed that using -8 .deb with a -8 .udeb
(reversioned as -9+hack so that its being dropped under localudebs makes
it take precedence over sid's .udeb) leads to an image that's working
fine. And AFAICT that's the combination we had at the time.

I suspect the implementation change through the following patch in -9:
    glibc-2.24/debian/patches/any/cvs-resolv-internal-qtype.diff

plus 283e7a294275a7da53258600deaaafbbec6b96c1 in debian-installer.git is
what is triggering the issue? (Explaining why host's libc .deb have an
impact on the built images.)

It's been a while since I last looked at/understood mklibs stuff though,
feel free to fix my suspicions/conclusions.


KiBi.

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#851790: installation-reports: DNS not working

Aurelien Jarno
On 2017-01-19 01:53, Cyril Brulebois wrote:

> Cyril Brulebois <[hidden email]> (2017-01-19):
> > Summing up things from IRC:
> >  - in an uptodate sid chroot (both development version and minimal one
> >    with daily-build script): no DNS issues with the generated mini.iso
> >    (amd64, tested within stable's kvm on amd64). My image was also
> >    tested successfully by Steve, so not a setup issue.
> >
> >  - I can reproduce the issue with dailies from 2017-01-18, and from
> >    2017-01-19 (I picked it in advance during its build on barriere).
> >
> >  - I can reproduce the issue in the above mentioned sid chroot if
> >    I downgrade these packages to testing's version (-9 → -8):
> >      sudo apt-get install libc6:amd64=2.24-8 libc6-dev:amd64=2.24-8 libc-dev-bin=2.24-8
> >
> >  - The older set of libc* packages is installed in barriere's current
> >    amd64 sid chroot, too.
> >
> >  - Steve could only produce broken images when building locally, until
> >    he upgraded his libc* packages as well.
>
> And since Steve was wondering how we could release something for Stretch
> RC 1 with that… I've just confirmed that using -8 .deb with a -8 .udeb
> (reversioned as -9+hack so that its being dropped under localudebs makes
> it take precedence over sid's .udeb) leads to an image that's working
> fine. And AFAICT that's the combination we had at the time.
>
> I suspect the implementation change through the following patch in -9:
>     glibc-2.24/debian/patches/any/cvs-resolv-internal-qtype.diff
Indeed, I haven't done any test, but looking at the code, it shows that
the changes assume that libresolv.so.2 and libnss_dns.so.2 stay in sync.

> plus 283e7a294275a7da53258600deaaafbbec6b96c1 in debian-installer.git is
> what is triggering the issue? (Explaining why host's libc .deb have an
> impact on the built images.)

Indeed this has been done to avoid crashes when libc6-udeb is
re-installed at the beginning if the installer process, often causing
crashes in case of version mismatch (because the libnss* libraries were
in a different package).

Now libc6-udeb is unpacked while building the image, but given we still
have half a dozen of libraries without the corresponding udeb,
mklibs copy them on the image, as well as the dependencies, which
presumably includes libresolv.so.2.

> It's been a while since I last looked at/understood mklibs stuff though,
> feel free to fix my suspicions/conclusions.

The long term solution is to package all the libraries into udeb
packages. That way we can simply get rid of the mklibs pass.

The workaround are to make sure the chroots are up-to-date (which should
be the case now on the build daemons). An other alternative would be to
avoid copying a library in mklibs if it is already present in the image.
That might break if some very strict dependencies are used, though
I guess the way the udebs are downloaded, they should always have the
same or a newer version than in the chroot.

Aurelien

--
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
[hidden email]                 http://www.aurel32.net

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#851790: installation-reports: DNS not working

Steve McIntyre
On Thu, Jan 19, 2017 at 08:57:54AM +0100, Aurelien Jarno wrote:

>On 2017-01-19 01:53, Cyril Brulebois wrote:
>
>> It's been a while since I last looked at/understood mklibs stuff though,
>> feel free to fix my suspicions/conclusions.
>
>The long term solution is to package all the libraries into udeb
>packages. That way we can simply get rid of the mklibs pass.
>
>The workaround are to make sure the chroots are up-to-date (which should
>be the case now on the build daemons). An other alternative would be to
>avoid copying a library in mklibs if it is already present in the image.
>That might break if some very strict dependencies are used, though
>I guess the way the udebs are downloaded, they should always have the
>same or a newer version than in the chroot.

Thanks for the explanation - it's appreciated!

Is there anything we could do to fail the build if versions are out of
sync, rather than let a broken build through?

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
< Aardvark> I dislike C++ to start with. C++11 just seems to be
            handing rope-creating factories for users to hang multiple
            instances of themselves.

Reply | Threaded
Open this post in threaded view
|

Bug#851790: installation-reports: DNS not working

Cyril Brulebois-4
Steve McIntyre <[hidden email]> (2017-01-19):

> On Thu, Jan 19, 2017 at 08:57:54AM +0100, Aurelien Jarno wrote:
> >On 2017-01-19 01:53, Cyril Brulebois wrote:
> >
> >> It's been a while since I last looked at/understood mklibs stuff though,
> >> feel free to fix my suspicions/conclusions.
> >
> >The long term solution is to package all the libraries into udeb
> >packages. That way we can simply get rid of the mklibs pass.
> >
> >The workaround are to make sure the chroots are up-to-date (which should
> >be the case now on the build daemons). An other alternative would be to
> >avoid copying a library in mklibs if it is already present in the image.
> >That might break if some very strict dependencies are used, though
> >I guess the way the udebs are downloaded, they should always have the
> >same or a newer version than in the chroot.
>
> Thanks for the explanation - it's appreciated!
Yeah, thanks for the confirmation.

> Is there anything we could do to fail the build if versions are out of
> sync, rather than let a broken build through?

Well, I think Aurélien mentioned it: ensure chroots are up-to-date.
Tweaking the buildscript might do the trick, I suppose. AFAIUI, the
build isn't broken every time there's a divergence in versions anyway;
you're sometimes (un)lucky.

Can't really devote time right now to investigating the “let's not copy
stuff over if it's already present” suggestion…


KiBi.

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#851790: installation-reports: DNS not working

wookey-4
On 2017-01-19 11:04 +0100, Cyril Brulebois wrote:

> Steve McIntyre <[hidden email]> (2017-01-19):
> > On Thu, Jan 19, 2017 at 08:57:54AM +0100, Aurelien Jarno wrote:
> > >
> > >The workaround are to make sure the chroots are up-to-date (which should
> > >be the case now on the build daemons). An other alternative would be to
> > >avoid copying a library in mklibs if it is already present in the image.
> > >That might break if some very strict dependencies are used, though
> > >I guess the way the udebs are downloaded, they should always have the
> > >same or a newer version than in the chroot.
> >
> > Thanks for the explanation - it's appreciated!
>
> Yeah, thanks for the confirmation.
OK. I tested today's image (2017-01-23 04:56) and the install went
through OK, so we are back in sync and this issue is gone for now. It should
probably be retitled to something about library sync/using host libs
and left open until it's fixed propoerly.

Wookey
--
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#851790: installation-reports: DNS not working

Aurelien Jarno
On 2017-01-23 17:30, Wookey wrote:

> On 2017-01-19 11:04 +0100, Cyril Brulebois wrote:
> > Steve McIntyre <[hidden email]> (2017-01-19):
> > > On Thu, Jan 19, 2017 at 08:57:54AM +0100, Aurelien Jarno wrote:
> > > >
> > > >The workaround are to make sure the chroots are up-to-date (which should
> > > >be the case now on the build daemons). An other alternative would be to
> > > >avoid copying a library in mklibs if it is already present in the image.
> > > >That might break if some very strict dependencies are used, though
> > > >I guess the way the udebs are downloaded, they should always have the
> > > >same or a newer version than in the chroot.
> > >
> > > Thanks for the explanation - it's appreciated!
> >
> > Yeah, thanks for the confirmation.
>
> OK. I tested today's image (2017-01-23 04:56) and the install went
> through OK, so we are back in sync and this issue is gone for now. It should
> probably be retitled to something about library sync/using host libs
> and left open until it's fixed propoerly.
I have pushed a patch a few days ago that should fix the issue. Well I
don't know if it should be considered as a fix or a hack, but at least
it looks less a hack than the existing code...

The longterm solution is clearly to fully get rid of mklibs. That should
wait for after stretch though, as it requires new udebs from some
packages and thus some coordination.

Aurelien

--
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
[hidden email]                 http://www.aurel32.net

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#851790: marked as done (installation-reports: DNS not working)

Debian Bug Tracking System
In reply to this post by Wookey-2
Your message dated Fri, 27 Jan 2017 23:33:31 +0000
with message-id <[hidden email]>
and subject line Bug#851790: fixed in debian-installer 20170127
has caused the Debian Bug report #851790,
regarding installation-reports: DNS not working
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [hidden email]
immediately.)


--
851790: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851790
Debian Bug Tracking System
Contact [hidden email] with problems

Package: installation-reports
Severity: grave
Tags: d-i
Justification: renders package unusable

Dear Maintainer,

The current installer, with the new 4.9 kernel, is unable to resolve
domains, so is quite seriously broken.

This was noted during install on an arm64 gigabyte MP30-AR1
desktop/server, when choose-mirror failed, but it soon became clear
that DNS was not working.

Testing on an x86 VM with the same daily image (18th Jan 2017) found
the same problem. Going back to the rc1 installer image (4.8 kernel)
it works OK.

Tests showed that the network came up fine and things are pingable by IP, but not name:
# ping wookware.org                                                          
ping: bad address 'wookware.org'
# ping 93.93.131.118
PING 93.93.131.118 (93.93.131.118): 56 data bytes
64 bytes from 93.93.131.118: seq=0 ttl=50 time=19.892 ms

similarly the failing line from the choose-mirror log works if an address is inserted:
Jan 18 17:04:11 choose-mirror[31201]: DEBUG: command: wget --no-verbose http://debian-mirror.cambridge.arm.com/debian/dists/stretch/Release -O - | grep -E '^(Suite|Codename|Architectures):'                                                  
Jan 18 17:04:11 choose-mirror[31201]: WARNING **: mirror does not support the specified release (stretch)

# wget --no-verbose http://debian-mirror.cambridge.arm.com/debian/dists/stretch/Release -O - | grep -E '^(Suite|Codename|Architectures):'
wget: unable to resolve host address 'debian-mirror.cambridge.arm.com'

# wget --no-verbose http://10.1.194.51/debian/dists/stretch/Release -O - | gre
p -E '^(Suite|Codename|Architectures):'
Suite: testing
Codename: stretch
Architectures: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
2017-01-18 17:47:12 URL:http://10.1.194.51/debian/dists/stretch/Release [177979/177979] -> "-" [1]

resolv.conf is as expected:
search cambridge.arm.com
nameserver 10.1.2.24
nameserver 10.1.2.23

(adding nameserver 8.8.8.8 makes no difference)

Watching packets go by when doing a VM install it is clear that the
local DNS server returns the correct response, but this is being ignored
or lost by the D-I initrd.

attached is an strace of strace ping wookware.org > /tmp/tracelog 2>&1

That gets a response from the server OK, but then goes on to ask the
other one. a working strace then uses the provided IP address. So
there is nothing obviously going wrong there.

-- Package-specific info:

Boot method: USB
Image version: http://gemmei.acc.umu.se/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/debian-testing-arm64-netinst.iso
Date: <Date and time of the install>

Machine: Gigabyte MP30-AR1, (and x86 VM)
Partitions: (default guided LVM, with separate /home chosen)


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:           [O]
Detect network card:    [O]
Configure network:      [O]
Detect CD:              [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:    [O]
Detect hard drives:     [O]
Partition hard drives:  [O]
Install base system:    [E]
Install tasks:          [ ]
Install boot loader:    [ ]
Overall install:        [ ]

Comments/Problems:

Worked as expected until DNS needed

--

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to [hidden email].

removed automatic info as this report written on different machine fro install.

Source: debian-installer
Source-Version: 20170127

We believe that the bug you reported is fixed in the latest version of
debian-installer, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [hidden email],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Cyril Brulebois <[hidden email]> (supplier of updated debian-installer package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [hidden email])


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Fri, 27 Jan 2017 23:23:37 +0100
Source: debian-installer
Binary: debian-installer
Architecture: source
Version: 20170127
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team <[hidden email]>
Changed-By: Cyril Brulebois <[hidden email]>
Description:
 debian-installer - Debian Installer documentation
Closes: 851790
Changes:
 debian-installer (20170127) unstable; urgency=medium
 .
   [ Cyril Brulebois ]
   * Bump Linux kernel version from 4.8.0-2 to 4.9.0-1.
   * Update translation-status for the release.
 .
   [ Martin Michlmayr ]
   * Drop armel/versatile flavour since kernel support was removed.
 .
   [ Aurelien Jarno ]
   * Also copy *.so files in udeblibs (Closes: #851790).
   * mips*: install all NIC modules in the netbood initrd.
Checksums-Sha1:
 56b1b281d193cab71e85cccb606fb68d47a2cc00 3553 debian-installer_20170127.dsc
 1222f473d2038a51c35029f1eb134bdbe48cf163 1385371 debian-installer_20170127.tar.gz
Checksums-Sha256:
 15778676c7cacd9f33b8bd3b2358148b960b8073ae7b4849a7c4be3867c97391 3553 debian-installer_20170127.dsc
 39b1a824a07333ab8ec085e0f3f6fc6249b5ad48a3de899c1851d945c8631352 1385371 debian-installer_20170127.tar.gz
Files:
 fc4b066086b553b963ac58c585fd0766 3553 devel optional debian-installer_20170127.dsc
 d73ece4d936056e224adf6a64834cebe 1385371 devel optional debian-installer_20170127.tar.gz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJYi9SLAAoJEP+RSvDCs1UgbKoQAK5SS/SMs1mIikH8py8TzKqD
GUDTP0NwrxeXBr/FjfvZ+JYosOGaljYne+tFNrZbZq7/LZ3DZRdd/trzDYuVGhW4
MAfndluanBm+eD1o2zKFFzPNKSENvyQD8+NlfkYcdXMQk5S/0aGqqAv8pZooW4yJ
BY3+Le8J/2tPzXP8Ag06zUN3KpKiS81nEgyOvfgVHsyvP0H4s2ydWKbK4pYufOaZ
fXXYP7DahT5FHdGjxGj1VALHjxXiHYNAvBzkNM/fo+KB0/OTMy2yDBB6x7XGpcYD
il97O3IKAwZ3nKHRV8zLNNBtZjoDGUG3Gxm3iJ1CIiCaqHrmzNFD0LXX2Y8oyL/4
A0NMC8+SdskCd7Mwrt4tDyhu5a4a6SU3O+tcn9rWsbJoZ37iN7wdh346Dy6vFNjD
JdKV3f/4qRG80UT3AyRB5XX9/AVPEA8ItCaomGHCLT5cBs8HF+HH+AGJbZYGXYli
9XiZZAF0XH1qZHGoecKddXqBckSnOixrDTTKXeWTxKwW5LKqKGcgUdF5x+TknCfk
OhXVnp9e2uWNiN6fGuBuWBtOkvfBNqqg0G1t4gqnG+O8TpaFdhEenN7JKrtcl/HN
YE+AlnnrR/0kvDQLOMtLtTYagk7WSHdZZ3zJg75FdPI84HhRGTxm02HxXj4SnAKK
OfOgtr9Jba1DGw2GXFMe
=OX2C
-----END PGP SIGNATURE-----

strace.log (14K) Download Attachment