Bug#851790: installation-reports: DNS not working

[Cyril Brulebois]

Cyril Brulebois  (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
Description: Digital signature

Bug#851790: installation-reports: DNS not working

[Cyril Brulebois]

Cyril Brulebois  (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
Description: Digital signature

Bug#851539: Stretch RC1 netinst installer prompts for additional CDs

[Josh Triplett]

On Wed, Jan 18, 2017 at 02:53:29PM +, Steve McIntyre wrote:
> On Tue, Jan 17, 2017 at 10:24:31AM +0100, Julien Cristau wrote:
> >On 01/16/2017 07:56 PM, Josh Triplett wrote:
> >> 
> >> How does it help for the firmware-included images?
> >> 
> >It makes it possible to use them to install from CD rather than from the
> >network.
> 
> Exactly.
> 
> When we first came up with the idea of the firmware-included images,
> an explicit use case was meant to be "boot off firmware netinst, add
> other discs as apt sources" to make things work well. I'd not
> understood why that wasn't working for quite a while, and then took a
> long time to get around to fixing this.

That seems entirely reasonable.  However, does the prompt make sense for
the non-firmware-included images?  Or could it go away for those, to
reduce the number of questions asked?

- Josh Triplett

Bug#851790: installation-reports: DNS not working

[Cyril Brulebois]

Steve McIntyre  (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
Description: Digital signature

Bug#851790: installation-reports: DNS not working

[Steve McIntyre]

On Wed, Jan 18, 2017 at 06:43:33PM +, 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.st...@einval.com
"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

Bug#851790: installation-reports: DNS not working

[Wookey]

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: 

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 sub...@bugs.debian.org.

removed automatic info as this report written on different machine fro install.
execve("/bin/ping", ["ping", "wookware.org"], [/* 14 vars */]) = 0
brk(NULL)   = 0xc9893000
faccessat(AT_FDCWD, "/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or 
directory)
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x86677000
faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)
openat(AT_FDCWD, "/lib/aarch64-linux-gnu/tls/aarch64/libc.so.6", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib/aarch64-linux-gnu/tls/aarch64", 0xc66b2660, 0) = 
-1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/aarch64-linux-gnu/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = 
-1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib/aarch64-linux-gnu/tls", 0xc66b2660, 0) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/aarch64-linux-gnu/aarch64/libc.so.6", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib/aarch64-linux-gnu/aarch64", 0xc66b2660, 0) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/aarch64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib/aarch64-linux-gnu", {st_mode=S_IFDIR|0755, 
st_size=360, ...}, 0) = 0
openat(AT_FDCWD, 

Bug#772901: marked as done (os-prober wrong output with grep 2.21 or later)

[Debian Bug Tracking System]

Your message dated Wed, 18 Jan 2017 16:38:24 +
with message-id <20170118163824.ga5...@riva.ucam.org>
and subject line Re: Bug#772901: os-prober wrong output with grep 2.21 or later
has caused the Debian Bug report #772901,
regarding os-prober wrong output with grep 2.21 or later
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 ow...@bugs.debian.org
immediately.)


-- 
772901: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772901
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: os-prober
Version: 1.65
Tags: patch

os-prober uses 'grep' in an unportable way, in that it assumes that the regular 
expression "." matches the NUL byte (all zero bits).  POSIX doesn't guarantee 
this, and as of grep 2.21 this might not work.  If os-prober assumes GNU grep 
the fix should be fairly straightforward; please see the attached (untested) 
patch.  If os-prober is intended to be portable to non-GNU grep, more hacking 
will be needed, as POSIX says grep has undefined behavior when given binary 
input data.


For more details about this issue please see:

https://bugzilla.redhat.com/show_bug.cgi?id=1172405
https://bugzilla.redhat.com/show_bug.cgi?id=1172804
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19348
diff -pru os-prober/os-probes/mounted/x86/20microsoft os-prober-fix/os-probes/mounted/x86/20microsoft
--- os-prober/os-probes/mounted/x86/20microsoft	2014-11-12 07:19:18.0 -0800
+++ os-prober-fix/os-probes/mounted/x86/20microsoft	2014-12-11 19:25:06.749770598 -0800
@@ -31,19 +31,19 @@ if item_in_dir -q bootmgr "$2"; then
 	for boot in $(item_in_dir boot "$2"); do
 		bcd=$(item_in_dir bcd "$2/$boot")
 		if [ -n "$bcd" ]; then
-			if grep -qs "W.i.n.d.o.w.s. .8" "$2/$boot/$bcd"; then
+			if grep -aqs "W.i.n.d.o.w.s. .8" "$2/$boot/$bcd"; then
 long="Windows 8 (loader)"
-			elif grep -qs "W.i.n.d.o.w.s. .7" "$2/$boot/$bcd"; then
+			elif grep -aqs "W.i.n.d.o.w.s. .7" "$2/$boot/$bcd"; then
 long="Windows 7 (loader)"
-			elif grep -qs "W.i.n.d.o.w.s. .V.i.s.t.a" "$2/$boot/$bcd"; then
+			elif grep -aqs "W.i.n.d.o.w.s. .V.i.s.t.a" "$2/$boot/$bcd"; then
 long="Windows Vista (loader)"
-			elif grep -qs "W.i.n.d.o.w.s. .S.e.r.v.e.r. .2.0.0.8. .R.2." "$2/$boot/$bcd"; then
+			elif grep -aqs "W.i.n.d.o.w.s. .S.e.r.v.e.r. .2.0.0.8. .R.2." "$2/$boot/$bcd"; then
 long="Windows Server 2008 R2 (loader)"
-			elif grep -qs "W.i.n.d.o.w.s. .S.e.r.v.e.r. .2.0.0.8." "$2/$boot/$bcd"; then
+			elif grep -aqs "W.i.n.d.o.w.s. .S.e.r.v.e.r. .2.0.0.8." "$2/$boot/$bcd"; then
 long="Windows Server 2008 (loader)"
-			elif grep -qs "W.i.n.d.o.w.s. .R.e.c.o.v.e.r.y. .E.n.v.i.r.o.n.m.e.n.t" "$2/$boot/$bcd"; then
+			elif grep -aqs "W.i.n.d.o.w.s. .R.e.c.o.v.e.r.y. .E.n.v.i.r.o.n.m.e.n.t" "$2/$boot/$bcd"; then
 long="Windows Recovery Environment (loader)"
-			elif grep -qs "W.i.n.d.o.w.s. .S.e.t.u.p" "$2/$boot/$bcd"; then
+			elif grep -aqs "W.i.n.d.o.w.s. .S.e.t.u.p" "$2/$boot/$bcd"; then
 long="Windows Recovery Environment (loader)"
 			else
 long="Windows Vista (loader)"
diff -pru os-prober/os-probes/mounted/x86/83haiku os-prober-fix/os-probes/mounted/x86/83haiku
--- os-prober/os-probes/mounted/x86/83haiku	2014-09-28 14:04:17.0 -0700
+++ os-prober-fix/os-probes/mounted/x86/83haiku	2014-12-11 19:32:45.177765083 -0800
@@ -13,7 +13,7 @@ case "$type" in
 	*) debug "$partition is not a BeFS partition: exiting"; exit 1 ;;
 esac
 
-if head -c 512 "$partition" | grep -qs "system.haiku_loader"; then
+if head -c 512 "$partition" | grep -aqs "system.haiku_loader"; then
 	debug "Stage 1 bootloader found"
 else
 	debug "Stage 1 bootloader not found: exiting"
--- End Message ---
--- Begin Message ---
Source: os-prober
Source-Version: 1.66

On Thu, Dec 11, 2014 at 07:45:29PM -0800, Paul Eggert wrote:
> os-prober uses 'grep' in an unportable way, in that it assumes that the
> regular expression "." matches the NUL byte (all zero bits).  POSIX doesn't
> guarantee this, and as of grep 2.21 this might not work.  If os-prober
> assumes GNU grep the fix should be fairly straightforward; please see the
> attached (untested) patch.  If os-prober is intended to be portable to
> non-GNU grep, more hacking will be needed, as POSIX says grep has undefined
> behavior when given binary input data.

Thanks.  An identical patch seems to have been applied in os-prober 1.66
in response to a later bug report, so closing this bug.

os-prober (1.66) unstable; urgency=medium

  * Add -a flag to grep -qs for Windows Vista detection. It appears the
file isn't always considered as a text file, so this should be more
robust. Thanks to Gianluigi 

Processed: forcibly merging 648208 794849

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> forcemerge 648208 794849
Bug #648208 [os-prober] os-prober: blockdev --setro affects running kvm 
instances
Bug #788062 [os-prober] os-prober corrupts LVs/partitions while being mounted 
inside a VM
Bug #806273 [os-prober] os-prober: remove or disable-per default the non 
grub-mount based probing
Bug #810121 [os-prober] linux: KVM guests randomly get I/O errors on VirtIO 
based devices
Bug #794849 [os-prober] linux: custom linux-image packages fail to install
Severity set to 'critical' from 'serious'
Marked as found in versions os-prober/1.65 and os-prober/1.42.
Added tag(s) patch.
Bug #788062 [os-prober] os-prober corrupts LVs/partitions while being mounted 
inside a VM
Bug #806273 [os-prober] os-prober: remove or disable-per default the non 
grub-mount based probing
Bug #810121 [os-prober] linux: KVM guests randomly get I/O errors on VirtIO 
based devices
Merged 648208 788062 794849 806273 810121
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
648208: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648208
788062: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788062
794849: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794849
806273: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806273
810121: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810121
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#851429: installation-reports: mounting CD fails on qemu-system-aarch64

[Steve McIntyre]

On Sun, Jan 15, 2017 at 03:05:11PM +0100, Adam Borowski wrote:
>On Sun, Jan 15, 2017 at 01:12:53AM +, Steve McIntyre wrote:
>> 
>> I think the problem is with your setup. I've just booted that exact
>> netinst image happily using
>> 
>> qemu-system-aarch64 -m 4G -cpu cortex-a57 -M virt -smp 8 -nographic
>> -pflash AAVMF_CODE.fd -pflash AAVMF_VARS.fd -drive
>> file=/scratch/iso/debian-stretch-DI-rc1-arm64-netinst.iso,id=cdrom,if=none,media=cdrom
>> -device virtio-scsi-device -device scsi-cd,drive=cdrom -k en-gb
>> -netdev user,id=eth0 -device virtio-net-device,netdev=eth0
>
>Ie, virtio vs emulating a real piece of hardware.
>
>The problem here, though, is that qemu picked a piece of hardware that's old
>crap that's not expected in any physical arm64 gardware.  I guess it'd be
>good to ask them to upgrade, like they did with the Cirrus card on x86.

Might be a good plan, yes. Fancy filing a bug? :-)

>Ordinarily I'd want you to support this "hardware" as QEMU is a major
>platform (at least the one most available), but in this case, with the
>extensive incantations required to get it running, requiring virtio might be
>acceptable.  I refuse to say "arguments" rather than "incantations" as
>the former is for specifying what the program should do and what you want
>altered from reasonable defaults, rather than a massive ritual that needs to
>be performed just to get basic functionality, with every piece involving
>lengthy research and breakage/data loss if you skip it.  Like, my line lacks
>a flash for storing EFI vars, meaning that it will install correctly (with
>mini.iso), work when rebooted, even upon multiple reboots, then fail to work
>anymore once you shut down qemu and start it again.
>
>So I wonder what's the best way to proceed.  Probably documenting what's
>needed might be a good step.

And that would be good too. Where should we put that? In the wiki
maybe, I'm thinking the installer manual is not ideal.

>> and it's running the installer right now with udebs from the
>> netinst iso. What version of qemu-efi are you using for
>> /usr/share/qemu-efi/QEMU_EFI.fd?
>
>0~20161202.7bbe0b3e-1 (current unstable and stretch).

OK, same as me. I *had* seen issues with older versions of UEFI for
arm64, hence the question.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me 

Bug#851539: Stretch RC1 netinst installer prompts for additional CDs

[Steve McIntyre]

On Tue, Jan 17, 2017 at 10:24:31AM +0100, Julien Cristau wrote:
>On 01/16/2017 07:56 PM, Josh Triplett wrote:
>> 
>> How does it help for the firmware-included images?
>> 
>It makes it possible to use them to install from CD rather than from the
>network.

Exactly.

When we first came up with the idea of the firmware-included images,
an explicit use case was meant to be "boot off firmware netinst, add
other discs as apt sources" to make things work well. I'd not
understood why that wasn't working for quite a while, and then took a
long time to get around to fixing this.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Processed: take ownership of my cam.ac.uk-submitted bugs

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> submitter 716975 matth...@chiark.greenend.org.uk
Bug #716975 [twittering-mode] Should deal with lack-of-curl gracefully
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 740347 matth...@chiark.greenend.org.uk
Bug #740347 [maven-repo-helper] mh_installpoms -n should output what it would 
have done, not just exit
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 740826 matth...@chiark.greenend.org.uk
Bug #740826 [libjgrapht0.8-java] libjgrapht0.8-java: packaging should be jar 
not pom
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 794680 matth...@chiark.greenend.org.uk
Bug #794680 [linux] drbd kernel module incompatible with drbd-utils -> kernel 
panics
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 795867 matth...@chiark.greenend.org.uk
Bug #795867 [lvm2] vgchange has at least one race condition
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 799148 matth...@chiark.greenend.org.uk
Bug #799148 [collectd] Fails to stop children on exit
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 802683 matth...@chiark.greenend.org.uk
Bug #802683 [iso-scan] Fails to automatically find iso on /dev/sdh
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 803146 matth...@chiark.greenend.org.uk
Bug #803146 [mysql-server] Upgrade fails to handle shortage of disk space
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 803148 matth...@chiark.greenend.org.uk
Bug #803148 [mysql-server] Latest security update sometimes corrupts help_topic 
table
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 808071 matth...@chiark.greenend.org.uk
Bug #808071 [icedove] attempting to sync new google calendar causes icedove to 
eat all available CPU and RAM
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 816702 matth...@chiark.greenend.org.uk
Bug #816702 [src:linux] linux-image-4.3.0-0.bpo.1-amd64: soft lockups in raid10
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 826570 matth...@chiark.greenend.org.uk
Bug #826570 [lvm2] lvm2: erroneously starts lvmetad on upgrade
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 831686 matth...@chiark.greenend.org.uk
Bug #831686 [lvm2] sorting on lv_time fails due to incorrect type
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 21758 matth...@chiark.greenend.org.uk
Bug #21758 [dselect] Dselect doesn't report an error when it doesn't find a 
package
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from '"M.C. Vernon" 
'.
> submitter 714613 matth...@chiark.greenend.org.uk
Bug #714613 [src:apache2] ap_log_perror ignores LogLevel configuration 
directives
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 740346 matth...@chiark.greenend.org.uk
Bug #740346 [maven-repo-helper] mh_installpom - will always exit non-zero if 
called with -n
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 791344 matth...@chiark.greenend.org.uk
Bug #791344 [drbd-utils] behaviour of new-current-uuid is not as documented
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 813005 matth...@chiark.greenend.org.uk
Bug #813005 [userv] userv: specifying keywords in require-fds doesn't work
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 810829 matth...@chiark.greenend.org.uk
Bug #810829 [dgit] dgit: should be possible to use with a reprepro-style small 
repo
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 829188 matth...@chiark.greenend.org.uk
Bug #829188 [icedove] SEGVs too frequently (~every other day)
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 781107 matth...@chiark.greenend.org.uk
Bug #781107 [openssh-client] ssh-keygen -F return code has changed and is not 
documented
Changed Bug submitter to 'matth...@chiark.greenend.org.uk' from 'Matthew Vernon 
'.
> submitter 812081 matth...@chiark.greenend.org.uk
Bug #812081 [libreoffice] Keyboard shortcuts 

flash-kernel_3.75_armel.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 18 Jan 2017 07:00:43 +0100
Source: flash-kernel
Binary: flash-kernel flash-kernel-installer
Architecture: source armel
Version: 3.75
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Christian Perrier 
Description:
 flash-kernel - utility to make certain embedded devices bootable
 flash-kernel-installer - Make the system bootable (udeb)
Changes:
 flash-kernel (3.75) unstable; urgency=medium
 .
   [ Vagrant Cascadian ]
   * Add machine db entry for Pine64+.
Checksums-Sha1:
 e8708cb972e469ea88344f7e5de72909bfb1ae67 1859 flash-kernel_3.75.dsc
 adb8cec77fe9b76ca37cdd3f752190dc9ff76072 68700 flash-kernel_3.75.tar.xz
 f593b371b5cc920fdfb29b3cc95d63cccfa3eba5 25708 
flash-kernel-installer_3.75_armel.udeb
 5324c41677b83324ae65529d0d47d31a18f4cf69 4914 flash-kernel_3.75_armel.buildinfo
 95cfc210634a7cce4a8e6b4f7c0efd9407677388 45336 flash-kernel_3.75_armel.deb
Checksums-Sha256:
 8cad69f1bb85419cef9fc44a80603f42f28a1a2ee5f2390d3bac9958cf8aa2d3 1859 
flash-kernel_3.75.dsc
 466b79afb0d68eeafd1bf8225f98838eaf8038e05e0a3106cfe568b507891633 68700 
flash-kernel_3.75.tar.xz
 bf78f1d1e42cdc2f99f3a901e6f92973d2221393e029d3c3205688d4c9811402 25708 
flash-kernel-installer_3.75_armel.udeb
 b411b3f2f2ea944270895ce97b959efe1ff65b75e641ec47d2dd5cff349b0b49 4914 
flash-kernel_3.75_armel.buildinfo
 c56e7f49c2a554750010612bedce1278875d713f1f35c2faec5c13a692275d00 45336 
flash-kernel_3.75_armel.deb
Files:
 39b88267c8ae38baaee79b91f3477531 1859 utils optional flash-kernel_3.75.dsc
 423efba8151001ae63b0ec58b8f59da2 68700 utils optional flash-kernel_3.75.tar.xz
 b00213ecde7d80259339e9facf689a85 25708 debian-installer standard 
flash-kernel-installer_3.75_armel.udeb
 5442e3ec4c77a55c7717bb5f62918157 4914 utils optional 
flash-kernel_3.75_armel.buildinfo
 82be8e2bb5eaf01010215f4e4e97f850 45336 utils optional 
flash-kernel_3.75_armel.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJYf2KyAAoJEIcvcCxNbiWoEuIP/11BGT92QKpaMB5ninfgHVYV
eJ+fkkb3lu/uMugM7R9TiLajH0s+vWeEMz3JcrlKh3vJHdBZfsiFM677RSvId+48
wD2Q4rBr/K79pUhL4addaFEeJxE/CU8yZfyfH+zTX47KUSB2HrNBpTLUerM/t8l3
MiF7x1+T300ug2ZPHTDV5izhpMABqR6SaQNzk3qHU4krqGidhN+VrpUGRTHOmytz
M25D02B8TfcjgTpjg+kMCvH20AvauSoWToYBstqPIOfPBiar/iJ3T4rWiEZwqfJm
25d024RMhhp2IJts6K+reevn+0liA8KvIfjQMu8yXbfMu3EuhkTJuuCRoyygK4NO
2kkN63FcBnr30iV9cBwKSkg3cV48h3zJu9mAJ8YYHWndjyGwpYGh9HvGoHyR4vy3
JCuxBPpkwj2J5qCO/zBYsc2E3dmWS2j1mi0piSv/PMG/EhpC8GMMKa54laAdlZXK
pEqpr2ovahiZS9vd0PxuLgc/kE+IppDstpgNioj331TYdXJi5vKZEoVQIbUVVS07
r2koa57Hf6F9As6zZjpQdAw4IFGUzFqtyFgi5U8WH7DoBOstZ12FAVCGRcM1Y+KV
kEFzZeP7rRrfTwsa6CQhZLdjGqhBlG5snxNvHkfRUqXz0iZU+TMGubJOBhBlShWJ
Wdep9QqhzSw7j2CgpOS/
=5vif
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of flash-kernel_3.75_armel.changes

[Debian FTP Masters]

flash-kernel_3.75_armel.changes uploaded successfully to localhost
along with the files:
  flash-kernel_3.75.dsc
  flash-kernel_3.75.tar.xz
  flash-kernel-installer_3.75_armel.udeb
  flash-kernel_3.75_armel.buildinfo
  flash-kernel_3.75_armel.deb

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

Bug#851740: Additional infos to point 3 and maybe 2 of my report

[bkk]

Hi,

if I add break=top as kernel parameter, I come instantly to the busybox
prompt.
If I add break=modules it takes 90 seconds.

I think it has something to do with the networkdriver igb.
After a break=top, I use modeprobe igb to load it.
Then I use ifconfig -a to show the interfaces:
eth0 eth1 and lo are available.
But no link at eth0 (cable is connected)
Then after ifconfig eth0 192.168.0.111 still no link.
I start a ping and it takes 10 seconds until the link led comes active
and the ping works.

But I told you that a dist-upgrade from 8.7 to 9.0 worked.
I also copied the initrd from this working version to the clean 9.0
installation, but still 90 seconds to boot.
I have no explanation for that (why it works on the upgraded 9.0).

Best regards,

Bernd

openchrome and "Modules" section [was: Re: [Openchrome-users] How to say No!! in a polite though ridiculous way]

[Tzafrir Cohen]

On Wed, Jan 18, 2017 at 10:26:11AM +0100, Tamás Gajdos wrote:
> Hi,
> 
> I don't know if this is a packaging problem or not. But I had the same
> issue with Ubuntu 17.04 around 2017.01.10.
> 
> I solved the problem by adding some extra modules to the xorg.conf.
> 
> Section "Module"
> Load"vgahw"
> Load"shadowfb"
> Load"shadow"
> Load"exa"
> Load"fb"
> Load"drm"
> Load"ramdac"
> EndSection
> 
> Maybe not all of them is needed as I was trying to debug another issue.

OK. So just to complete the report:

With just "vgahw" and "shadow": libshadow now loads OK, and the next
error is:

[  5933.945] (EE) Failed to load 
/usr/lib/xorg/modules/drivers/openchrome_drv.so: 
/usr/lib/xorg/modules/drivers/openchrome_drv.so: undefined symbol: exaWaitSync


Next, add "exa". Now I get:

[  6218.682] (EE) Failed to load 
/usr/lib/xorg/modules/drivers/openchrome_drv.so: 
/usr/lib/xorg/modules/drivers/openchrome_drv.so: undefined symbol: fbScreenInit

If I add "fb", the openchrome_drv loads fine. Thus the following seems
to work for me:

Section "Module"
Load"vgahw"
Load"shadow"
Load"exa"
Load"fb"
EndSection

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend

Bug#851740: bug report installing 9.0 RC1

[bkk]

Package: installation-reports

Boot method: Installer bootet via USB
Image version: 
http://cdimage.debian.org/cdimage/stretch_di_rc1/amd64/iso-cd/debian-stretch-DI-rc1-amd64-netinst.iso
Date: 2017-01-18 09:45

Machine: SUPERMICRO X10SBA-L-O-P
Processor: Intel Celeron J1900 (cpu family:6, model: 55, stepping:8)
Memory: 4GB
Partitions:

Disk /dev/sda: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x51e39a8b

Device Boot  StartEndSectors   Size Id Type
/dev/sda1  *  2048 1945382911 1945380864 927,6G 83 Linux
/dev/sda2   1945384958 19535237118138754   3,9G  5 Extended
/dev/sda5   1945384960 19535237118138752   3,9G 82 Linux swap / Solaris



Output of lspci -knn (or lspci -nn):

00:00.0 Host bridge [0600]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
Serie s SoC Transaction Register [8086:0f00] (rev 0e)
Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx Series 
 SoC Transaction Register [15d9:0816]
Kernel driver in use: iosf_mbi_pci
00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor 
Z36xx x/Z37xxx Series Graphics & Display [8086:0f31] (rev 0e)
Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx Series 
 Graphics & Display [15d9:0816]
Kernel driver in use: i915
Kernel modules: i915
00:13.0 SATA controller [0106]: Intel Corporation Atom Processor E3800 Series 
SA TA AHCI Controller [8086:0f23] (rev 0e)
Subsystem: Super Micro Computer Inc Atom Processor E3800 Series SATA 
AHC I Controller [15d9:0816]
Kernel driver in use: ahci
Kernel modules: ahci
00:1a.0 Encryption controller [1080]: Intel Corporation Atom Processor 
Z36xxx/Z3 7xxx Series Trusted Execution Engine [8086:0f18] (rev 
0e)
Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx Series 
 Trusted Execution Engine [15d9:0816]
00:1c.0 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
Exp ress Root Port 1 [8086:0f48] (rev 0e)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.2 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
Exp ress Root Port 3 [8086:0f4c] (rev 0e)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.3 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
Exp ress Root Port 4 [8086:0f4e] (rev 0e)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1d.0 USB controller [0c03]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
Se ries USB EHCI [8086:0f34] (rev 0e)
Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx Series 
 USB EHCI [15d9:0816]
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:1f.0 ISA bridge [0601]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
Series  Power Control Unit [8086:0f1c] (rev 0e)
Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx Series 
 Power Control Unit [15d9:0816]
Kernel driver in use: lpc_ich
Kernel modules: lpc_ich
00:1f.3 SMBus [0c05]: Intel Corporation Atom Processor E3800 Series SMBus 
Contro ller [8086:0f12] (rev 0e)
Subsystem: Super Micro Computer Inc Atom Processor E3800 Series SMBus 
Co ntroller [15d9:0816]
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801
02:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network 
Conne ction [8086:1533] (rev 03)
Subsystem: Super Micro Computer Inc I210 Gigabit Network Connection 
[15d 9:1533]
Kernel driver in use: igb
Kernel modules: igb
03:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network 
Conne ction [8086:1533] (rev 03)
Subsystem: Super Micro Computer Inc I210 Gigabit Network Connection 
[15d 9:1533]
Kernel driver in use: igb
Kernel modules: igb



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

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

Comments/Problems:

1. ifconfig is not available
I don't know if this is wanted or not, but I miss it

2. the renaming of the networkcards is 

Bug#800367: [Openchrome-users] How to say No!! in a polite though ridiculous way

[Tamás Gajdos]

Hi,

I don't know if this is a packaging problem or not. But I had the same
issue with Ubuntu 17.04 around 2017.01.10.

I solved the problem by adding some extra modules to the xorg.conf.

Section "Module"
Load"vgahw"
Load"shadowfb"
Load"shadow"
Load"exa"
Load"fb"
Load"drm"
Load"ramdac"
EndSection

Maybe not all of them is needed as I was trying to debug another issue.

Thomas

2017-01-18 10:14 GMT+01:00 Tzafrir Cohen :

> On Sun, Jan 15, 2017 at 08:51:06PM +0100, Tzafrir Cohen wrote:
> > On Fri, Jan 13, 2017 at 11:47:40PM +0100, Kevin Brace wrote:
> > > Hi Andreas,
> > >
> > > Throw this in your xorg.conf
> > >
> > > 
> > > Section "Module"
> > > Load"vgahw"
> > > EndSection
> > > 
> > >
> > > Other than that, your xorg.conf can be empty.
> > > I hope it works.
> >
> > Thanks. Works for me.
>
> Err... almost. It works. Only not using the openchrome module. Preiously
> the openchrome module probably failed the whole load and had to be moved
> aside. Now it merely fails to load but I can use vesa or whatever as a
> fallback.
>
> Without any extra config:
>
>   [  1618.153] (EE) Failed to load 
> /usr/lib/xorg/modules/drivers/openchrome_drv.so:
> /usr/lib/xorg/modules/drivers/openchrome_drv.so: undefined symbol:
> vgaHWFreeHWRec
>
> vgaHWFreeHWRec indeed comes from vgahw. So add it. Now I get:
>
> [  1747.417] (EE) Failed to load 
> /usr/lib/xorg/modules/drivers/openchrome_drv.so:
> /usr/lib/xorg/modules/drivers/openchrome_drv.so: undefined symbol:
> shadowRemove
>
> Grepping further, I see shadowRemove comes from libshadow.so. So I try
> adding it. Now I get:
>
> [  1830.755] (EE) LoadModule: Module libshadow does not have a
> libshadowModuleData data object.
> [  1830.756] (II) UnloadModule: "libshadow"
>
>  ...
>
> [  1830.768] (EE) Failed to load 
> /usr/lib/xorg/modules/drivers/openchrome_drv.so:
> /usr/lib/xorg/modules/drivers/openchrome_drv.so: undefined symbol:
> shadowRemove
>
> Anyone else have this issue of the openchrome driver not loading at all?
> Is this a packaging issue?
>
> --
> Tzafrir Cohen | tzaf...@jabber.org | VIM is
> http://tzafrir.org.il || a Mutt's
> tzaf...@cohens.org.il ||  best
> tzaf...@debian.org|| friend
> ___
> Openchrome-users mailing list
> openchrome-us...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/openchrome-users
> Main page: http://www.openchrome.org
> Wiki: http://www.openchrome.org/trac/wiki/TOC
>

Re: [Openchrome-users] How to say No!! in a polite though ridiculous way

[Tzafrir Cohen]

On Sun, Jan 15, 2017 at 08:51:06PM +0100, Tzafrir Cohen wrote:
> On Fri, Jan 13, 2017 at 11:47:40PM +0100, Kevin Brace wrote:
> > Hi Andreas,
> > 
> > Throw this in your xorg.conf
> > 
> > 
> > Section "Module"
> > Load"vgahw"
> > EndSection
> > 
> > 
> > Other than that, your xorg.conf can be empty.
> > I hope it works.
> 
> Thanks. Works for me. 

Err... almost. It works. Only not using the openchrome module. Preiously
the openchrome module probably failed the whole load and had to be moved
aside. Now it merely fails to load but I can use vesa or whatever as a
fallback.

Without any extra config:

  [  1618.153] (EE) Failed to load 
/usr/lib/xorg/modules/drivers/openchrome_drv.so: 
/usr/lib/xorg/modules/drivers/openchrome_drv.so: undefined symbol: 
vgaHWFreeHWRec

vgaHWFreeHWRec indeed comes from vgahw. So add it. Now I get:

[  1747.417] (EE) Failed to load 
/usr/lib/xorg/modules/drivers/openchrome_drv.so: 
/usr/lib/xorg/modules/drivers/openchrome_drv.so: undefined symbol: shadowRemove

Grepping further, I see shadowRemove comes from libshadow.so. So I try
adding it. Now I get:

[  1830.755] (EE) LoadModule: Module libshadow does not have a
libshadowModuleData data object.
[  1830.756] (II) UnloadModule: "libshadow"

 ...

[  1830.768] (EE) Failed to load 
/usr/lib/xorg/modules/drivers/openchrome_drv.so: 
/usr/lib/xorg/modules/drivers/openchrome_drv.so: undefined symbol: shadowRemove

Anyone else have this issue of the openchrome driver not loading at all?
Is this a packaging issue?

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend