Bug#1039576: mt76x2u 4-6:1.0: Direct firmware load for mt7662_rom_patch.bin failed with error -2
Am 2023-06-27 15:15, schrieb Salvatore Bonaccorso: Hi, On Tue, Jun 27, 2023 at 01:35:51PM +0200, Wolfgang Walter wrote: Package: firmware-misc-nonfree Version: 20230515-1 Severity: important After upgrading firmware-misc-nonfree to 20230515-1 my usb-wlan adapter stopped working. The kernel logs: mt76x2u 4-6:1.0: Direct firmware load for mt7662_rom_patch.bin failed with error -2 Downgrading to 20230404-1 fixed the problem. This is likely due to an oversight in packaging of mine done in the last upload. Some old Mediatek WiFi firmware got moved, upstream has compatiblity symlinks but those were not installed in the Debian produced binary packages. Please test with -2 once it enters the archive (will upload shortly). Works again. Thanks -- Wolfgang Walter Studierendenwerk München Oberbayern Anstalt des öffentlichen Rechts
Bug#1039576: mt76x2u 4-6:1.0: Direct firmware load for mt7662_rom_patch.bin failed with error -2
Package: firmware-misc-nonfree Version: 20230515-1 Severity: important After upgrading firmware-misc-nonfree to 20230515-1 my usb-wlan adapter stopped working. The kernel logs: mt76x2u 4-6:1.0: Direct firmware load for mt7662_rom_patch.bin failed with error -2 Downgrading to 20230404-1 fixed the problem. Regards -- Wolfgang Walter Studierendenwerk München Oberbayern Anstalt des öffentlichen Rechts
Bug#1012567: openvpn --mktun --dev-type tap --dev tap2 fails
Am 2022-07-06 22:00, schrieb Bernhard Schmidt: Hi Wolfgang, Since 2.6.0~git20220518+dco-2 the following command fails: openvpn --mktun --dev-type tap --dev tap2 with Assertion failed at dco_linux.c:442 (tt-type == DEV_TYPE_TUN) Exit due to fatal error I don't have dco support in the linux kernel. openvpn --disable-dco --mktun --dev-type tap --dev tap2 works as a workaround, but I think --mktun --dev-type tap should continue to work without it. Upstream is thinking about removing that feature, see https://sourceforge.net/p/openvpn/mailman/message/37677365/ I already migrated to ip tuntap ... But I'm still unhappy with 2.6 being incompatible with 2.5 in rather many subtile ways. This is just another one. But of course this is an upstream decision. --- Hi, we are discussing to remove support for openvpn --mktun / --rmtun options in the upcoming 2.6 release - because it complicates the code, and we think there is no actual *need* for it anymore (and it's Linux only, etc). With "ip", there is a submode "ip tuntap", which does the same thing, so # openvpn --mktun --dev tun4 becomes # ip tuntap add mode tun name tun4 and similar for tap stuff, "user / group" settings, etc. So, this message is intended to do two things - raise awareness "this will come in 2.6!" - and also gather feedback: *if* you use openvpn --mktun today, please test "ip tuntap..." and let us know if it gets the job done properly, or of something is missing. The code is not removed yet, but will be, unless there are strong reasons to keep it. gert --- Bernhard -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#1012567: openvpn --mktun --dev-type tap --dev tap2 fails
Package: openvpn Version: 2.6.0~git20220518+dco-2 Severity: important Since 2.6.0~git20220518+dco-2 the following command fails: openvpn --mktun --dev-type tap --dev tap2 with Assertion failed at dco_linux.c:442 (tt-type == DEV_TYPE_TUN) Exit due to fatal error I don't have dco support in the linux kernel. openvpn --disable-dco --mktun --dev-type tap --dev tap2 works as a workaround, but I think --mktun --dev-type tap should continue to work without it. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#1011473: 2.5 clients cannot connect to a 2.6 server
Am 2022-05-25 15:40, schrieb Bernhard Schmidt: Am 25.05.22 um 13:39 schrieb Wolfgang Walter: Hi, Could you please check the release notes at https://github.com/OpenVPN/openvpn/blob/dco/Changes.rst for relevant changes and post logs/redacted config to this bug? I read them and I found nothing problematic. There is no problem with a 2.5.6 server and a 2.6 + openssl3 client, but a 2.5.6 client and a 2.6 + openssl3 server seem not to work together. Mai 23 19:13:31 server gu6[8334]: 1 variation(s) on previous 2 message(s) suppressed by --mute Mai 23 19:13:31 server gu6[8334]: NOTE: --mute triggered... Please downgrade verb to 2 and drop the mute option. Then show the logs of both sides connecting. Will do that tomorrow. But I found that dropping opt-verify on the server side allows 2.5.6 clients to connect again. So it seems that 2.5 and 2.6 disagree on tun-mtu (as the warning is not logged if both sides are either 2.5.6 or 2.6). Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#1011473: 2.5 clients cannot connect to a 2.6 server
6[8334]: 2a01:a:b:c::1234 peer info: IV_PLAT=linux Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_PROTO=6 Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_CIPHERS=AES-256-GCM Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_LZ4=1 Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_LZ4v2=1 Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_LZO=1 Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_COMP_STUB=1 Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_COMP_STUBv2=1 Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_TCPNL=1 Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532' Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 NOTE: --mute triggered... Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 1 variation(s) on previous 2 message(s) suppressed by --mute Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 NOTE: --mute triggered... Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 1 variation(s) on previous 2 message(s) suppressed by --mute Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 NOTE: --mute triggered... Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 1 variation(s) on previous 2 message(s) suppressed by --mute Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 NOTE: --mute triggered... Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 1 variation(s) on previous 2 message(s) suppressed by --mute Mai 23 19:13:31 server gu6[8334]: 2a01:a:b:c::1234 [r1h8PXRwkObqqyvcysUeFsK9bUMCpt7f] Peer Connection Initiated with [AF_INET6]2a01:a:b:c::1234:54365 = another try: = Mai 23 19:13:36 server gu6[8334]: 2a01:a:b:c::1234 NOTE: --mute triggered... Mai 23 19:13:37 server gu6[8334]: 1 variation(s) on previous 2 message(s) suppressed by --mute Mai 23 19:13:37 server gu6[8334]: NOTE: --mute triggered... Mai 23 19:13:37 server gu6[8334]: 5 variation(s) on previous 2 message(s) suppressed by --mute Mai 23 19:13:37 server gu6[8334]: NOTE: --mute triggered... Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 1 variation(s) on previous 2 message(s) suppressed by --mute Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 NOTE: --mute triggered... Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 1 variation(s) on previous 2 message(s) suppressed by --mute Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 NOTE: --mute triggered... Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 2 variation(s) on previous 2 message(s) suppressed by --mute Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 NOTE: --mute triggered... Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 2 variation(s) on previous 2 message(s) suppressed by --mute Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 NOTE: --mute triggered... Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 2 variation(s) on previous 2 message(s) suppressed by --mute Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 NOTE: --mute triggered... Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 10 variation(s) on previous 2 message(s) suppressed by --mute Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_VER=2.5.6 Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_PLAT=linux Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_PROTO=6 Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_CIPHERS=AES-256-GCM Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_LZ4=1 Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_LZ4v2=1 Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_LZO=1 Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_COMP_STUB=1 Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_COMP_STUBv2=1 Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 peer info: IV_TCPNL=1 Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532' Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 NOTE: --mute triggered... Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 1 variation(s) on previous 2 message(s) suppressed by --mute Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 NOTE: --mute triggered... Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 1 variation(s) on previous 2 message(s) suppressed by --mute Mai 23 19:13:37 server gu6[8334]: 2a01:a:b:c::1234 NOTE: --mute triggered... ===== Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#1011473: 2.5 clients cannot connect to a 2.6 server
Package: openvpn Version: 2.6.0~git20220518+dco-1 Severity: important openvpn 2.5.6 with openssl 1.1 seem unable to establish a connection to a sid openvpn-server upgraded to 2.6.0~git20220518+dco-1. I checked the configs. They work if both sides are 2.5.6 or both sides are 2.6 with openssl 3. I also see the following warning message in this case: "WARNING: tun-mtu is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'" Also in peer-mode 2.5.6 and 2.6 (both debian sid) do not work together. Maybe this very new patch fixes the issue: https://github.com/OpenVPN/openvpn/commit/88342ed8277c579704c0e67feb4278aeaa544027 I did not tested this hypothesis yet, though. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#1011127: [Pkg-openssl-devel] Bug#1011127: libssl3 breaks systems vith VIA Nehemiah cpu
Am 2022-05-17 15:34, schrieb Sebastian Andrzej Siewior: On 2022-05-17 12:53:07 [+0200], Wolfgang Walter wrote: Systems with VIA Nehemiah cpu break after upgrading unstable. All commands using libssl3 fail with … lscpu shows: Architecture:i686 CPU op-mode(s): 32-bit … Flags: fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse cpuid rng rng_en ace ace_en My guess is that your CPU lacks sse2, which in turn doesn't support multi-byte nops, which in turn does not support the endbr opcode / CET. I built i386 packages without endbr and uploaded everything to https://people.debian.org/~bigeasy/openssl-3-noendbr/ Could you please give a try report if this is correct? Sebastian Yes, with libssl3_3.0.3-4.noendbr_i386.deb this is fixed. Thanks -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#1011127: libssl3 breaks systems vith VIA Nehemiah cpu
Package: libssl3 Version: 3.0.3-4 Severity: grave Systems with VIA Nehemiah cpu break after upgrading unstable. All commands using libssl3 fail with traps: modprobe[2002] trap invalid opcode ip:b7c14700 sp:bfed3238 error:0 in libcrypto.so.3[b7ac+24f000] traps: sshd[1969] trap invalid opcode ip:b7b9c700 sp:bfedeaf8 error:0 in libcrypto.so.3[b7a48000+24f000] lscpu shows: Architecture:i686 CPU op-mode(s): 32-bit Address sizes: 32 bits physical, 32 bits virtual Byte Order: Little Endian CPU(s): 1 On-line CPU(s) list: 0 Vendor ID: CentaurHauls BIOS Vendor ID: VIA Model name: VIA Nehemiah BIOS Model name: Eden ESP CPU @ 1.0GHz BIOS CPU family: 13 CPU family: 6 Model: 9 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 1 Stepping:8 BogoMIPS:1995.89 Flags: fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse cpuid rng rng_en ace ace_en Vulnerability Itlb multihit: Processor vulnerable Vulnerability L1tf: Vulnerable Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled Vulnerability Meltdown: Vulnerable Vulnerability Spec store bypass: Vulnerable Vulnerability Spectre v1:Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2:Mitigation; Retpolines, STIBP disabled, RSB filling Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Systems with a VIA Eden Processor do not show this problem (flags are fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx cpuid pni est tm2 xtpr rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en). Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#1003574: segfault in libc-2.33.so during i386 boot ofde QEMU VM
Am 2022-01-15 11:26, schrieb Aurelien Jarno: control: reopen -1 control: merge 1003610 -1 control: severity -1 serious control: found -1 glibc/2.33-1 control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=28784 On 2022-01-12 14:08, Christian Kastner wrote: Hi Aurelien, thank you for the quick reply. On 2022-01-12 11:45, Aurelien Jarno wrote: >> # Boot image. -enable-kvm assumes that this is being tested on amd64 >> # Optionally use -nographic for terminal output instead of GUI >> $ qemu-system-i386 \ >>-machine q35 \ >>-enable-kvm \ > > You might also want to try without -enable-kvm Indeed, this fixed the issue. So sorry for the noise. I was 120% sure that I had tried that. My turn to be sorry, it appears to be a genuine issue on the GNU libc side, and changing the CPU definition in QEMU, either with -cpu or by disabling kvm) just hide the bug. I was not able to reproduce the issue as you need a non-Intel CPU to get the issue with the command line your provided. This bug also affects via C7 CPUs. I have reported the issue upstream and provided a patch, currently waiting for review. Regards, Aurelien I built the libc6 deb-package for i386 with your patch applied. It fixes the problem for VIA C7 and VIA Eden. Thanks a lot for your help. I hope upstream will include this fix soon. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#1003610: libc6 crashes with VIA C7 and VIA Eden processors starting with 2.33
Am 2022-01-13 23:07, schrieb Aurelien Jarno:
On 2022-01-13 14:20, Wolfgang Walter wrote:
Am 2022-01-12 16:46, schrieb Aurelien Jarno:
> On 2022-01-12 16:14, Wolfgang Walter wrote:
> > Package: libc6
> > Version: 2.33-2
> > Severity: important
> >
> > After upgrading from libc6 2.32 to 2.33 all machines with a VIA C7
> > or VIA
> > Eden show segfaults in libc (i.e. hostname fails to work, or rebooting
> > fails). Machines with VIA Nehemiah work fine.
>
> Could you please provide more details? At least the content of dmesg
> when it happens or ideally a core dump or a backtrace.
Not easy. These machines just boot into a initramfs (which is a very
minimal
debian sid) from an usb-stick and nothing survives a reboot. /bin/sh
points
to bash.
The system does not use systemd but sysv.
The login prompt is:
(none) login:
I cannot log into the machine, login seems also be broken, it always
says
"login incorrect".
If I try to reboot by entering ctrl-alt-del the reboot fails with:
INIT: Switching to runlevel: 6
INIT: No inittab.d directory found
INIT: Sending processes configured via /etc/inittab the TERM signal
[ 305.550677][ T1235] rc[1235]: segfault at 1c81000 ip b7ebf634 sp
bfb5ce78
error 6 in libc-2.33.so[b7d8e000+158000]
[ 305.550791][ T1235] Code: 95 04 00 03 1c 8b 01 ca ff e3 29 d9 8d b4
26 00
00 00 00 8d 76 00 0f 18 8a c0 03 00 00 0f 18 8a 80 03 00 00 81 eb 80
00 00
00 <66> 0f 7f 02 66 0f 7f 42 10 66 0f 7f 42 20 66 0f 7f 42 30 66 0f 7f
Give root password for maintenance
(or press Control-D to continue):
Thanks. This codes corresponds to memset_sse2:
14e607: 81 c3 69 95 04 00 add$0x49569,%ebx
14e60d: 03 1c 8badd(%ebx,%ecx,4),%ebx
14e610: 01 ca add%ecx,%edx
14e612: ff e3 jmp*%ebx
14e614: 29 d9 sub%ebx,%ecx
14e616: 8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi
14e61d: 8d 76 00lea0x0(%esi),%esi
14e620: 0f 18 8a c0 03 00 00prefetcht0 0x3c0(%edx)
14e627: 0f 18 8a 80 03 00 00prefetcht0 0x380(%edx)
14e62e: 81 eb 80 00 00 00 sub$0x80,%ebx
=>14e634: 66 0f 7f 02 movdqa %xmm0,(%edx)
14e638: 66 0f 7f 42 10 movdqa %xmm0,0x10(%edx)
14e63d: 66 0f 7f 42 20 movdqa %xmm0,0x20(%edx)
14e642: 66 0f 7f 42 30 movdqa %xmm0,0x30(%edx)
14e647: 66 0f 7f 42 40 movdqa %xmm0,0x40(%edx)
But I cannot login (Login incorrect). If I enter control-d instead, I
get
"sulogin: cannot read /dev/tty1: Operation not permitted".
The very same usb stick boots just fine with non VIA 7 / VIA Eden
processors.
I modified it a bit an set --autologin for one getty. This did not
worḱ, I
get a lot of things like
[ ..][ T1231] login[1231]: segfault at bfd3d000 ip b7eb5656 sp
bfd36978 error 6 in libc-2.33.so[b7d84000+158000]
or
[ ][ T1241] sh[1241]: segfault at 12ac000 ip b7e03638 sp
bff99ff8
error 6 in libc-2.33.so[b7cd2000+158000]
Now I tried getty -n -l /bin/dash. This worked.
If I try to start bash, bash crashes with a segmentation fault. I have
no
debugger and no debugging symbols in this image at the moment, only
strace
If I strace -f bash I get:
The last thing done is reading the first line of passwd, closing the
file.
Then there is a SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
si_addr=0x12d9000}
When I do a strace -f bash 2> /tmp/blub the last system call is
uname(),
then again a SEGV_MAPPERR
When bash segfaults I get no log that it crashed in libc6.
ls, rm, mount etc seem to work.
But vim crashes in libc6, again at +158000 and with Code "1c 8b 01 ca
ff e3
29 d9 8d b4 26 00 00 00 00 8d 76 00 0f 18 8a c0 03 00 00 0f 18 8a 80
03 00
00 81 eb 80 00 00 00 <66> 0f 7f 02 66 0f 7f 42 10 66 0f 7f 42 20 66 0f
7f 42
30 66 0f"
Also ip link ls crashes, again in libc6, again at +158000 and with
Code "0f
18 8a 80 03 00 00 81 eb 80 00 00 00 00 66 0f 7f 02 66 0f 7f 42 10 66
0f 7f
42 20 66 0f 7f 42 30 66 0f 7f 42 40 66 0f 7f 42 50 <66> 0f 7f 02 66 0f
7f 42
70 71 c2 80 00 00 00 81 fb 80 00 00 00"
or ip addr ls
or less, perl, ssh, sshd, rsyslogd
The Code is not always the same, but <66> 0f 7f 42 seems to be and the
crash
in libc-2.33.so[x+158000]
The above crashes are in memset_sse2 or bzero_sse2, I do not have
enough
details to confirm, but that's not that important.
Thanks a lot for those details, they definitely help to understand
things a bit better, although things are not fully clear yet.
The memset_sse2 and bzero_sse2 are called only on a SSE2 capable CPU,
which is the case of the VIA C7, and that matches the fact the crash is
a segmentation fault and not an illegal instruction. The addresses
seems to be correctly aligned as required by S
Bug#1003610: libc6 crashes with VIA C7 and VIA Eden processors starting with 2.33
Am 2022-01-12 16:46, schrieb Aurelien Jarno:
On 2022-01-12 16:14, Wolfgang Walter wrote:
Package: libc6
Version: 2.33-2
Severity: important
After upgrading from libc6 2.32 to 2.33 all machines with a VIA C7 or
VIA
Eden show segfaults in libc (i.e. hostname fails to work, or rebooting
fails). Machines with VIA Nehemiah work fine.
Could you please provide more details? At least the content of dmesg
when it happens or ideally a core dump or a backtrace.
Not easy. These machines just boot into a initramfs (which is a very
minimal debian sid) from an usb-stick and nothing survives a reboot.
/bin/sh points to bash.
The system does not use systemd but sysv.
The login prompt is:
(none) login:
I cannot log into the machine, login seems also be broken, it always
says "login incorrect".
If I try to reboot by entering ctrl-alt-del the reboot fails with:
INIT: Switching to runlevel: 6
INIT: No inittab.d directory found
INIT: Sending processes configured via /etc/inittab the TERM signal
[ 305.550677][ T1235] rc[1235]: segfault at 1c81000 ip b7ebf634 sp
bfb5ce78 error 6 in libc-2.33.so[b7d8e000+158000]
[ 305.550791][ T1235] Code: 95 04 00 03 1c 8b 01 ca ff e3 29 d9 8d b4
26 00 00 00 00 8d 76 00 0f 18 8a c0 03 00 00 0f 18 8a 80 03 00 00 81 eb
80 00 00 00 <66> 0f 7f 02 66 0f 7f 42 10 66 0f 7f 42 20 66 0f 7f 42 30
66 0f 7f
Give root password for maintenance
(or press Control-D to continue):
But I cannot login (Login incorrect). If I enter control-d instead, I
get "sulogin: cannot read /dev/tty1: Operation not permitted".
The very same usb stick boots just fine with non VIA 7 / VIA Eden
processors.
I modified it a bit an set --autologin for one getty. This did not worḱ,
I get a lot of things like
[ ..][ T1231] login[1231]: segfault at bfd3d000 ip b7eb5656 sp
bfd36978 error 6 in libc-2.33.so[b7d84000+158000]
or
[ ][ T1241] sh[1241]: segfault at 12ac000 ip b7e03638 sp
bff99ff8 error 6 in libc-2.33.so[b7cd2000+158000]
Now I tried getty -n -l /bin/dash. This worked.
If I try to start bash, bash crashes with a segmentation fault. I have
no debugger and no debugging symbols in this image at the moment, only
strace
If I strace -f bash I get:
The last thing done is reading the first line of passwd, closing the
file. Then there is a SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
si_addr=0x12d9000}
When I do a strace -f bash 2> /tmp/blub the last system call is uname(),
then again a SEGV_MAPPERR
When bash segfaults I get no log that it crashed in libc6.
ls, rm, mount etc seem to work.
But vim crashes in libc6, again at +158000 and with Code "1c 8b 01 ca ff
e3 29 d9 8d b4 26 00 00 00 00 8d 76 00 0f 18 8a c0 03 00 00 0f 18 8a 80
03 00 00 81 eb 80 00 00 00 <66> 0f 7f 02 66 0f 7f 42 10 66 0f 7f 42 20
66 0f 7f 42 30 66 0f"
Also ip link ls crashes, again in libc6, again at +158000 and with Code
"0f 18 8a 80 03 00 00 81 eb 80 00 00 00 00 66 0f 7f 02 66 0f 7f 42 10 66
0f 7f 42 20 66 0f 7f 42 30 66 0f 7f 42 40 66 0f 7f 42 50 <66> 0f 7f 02
66 0f 7f 42 70 71 c2 80 00 00 00 81 fb 80 00 00 00"
or ip addr ls
or less, perl, ssh, sshd, rsyslogd
The Code is not always the same, but <66> 0f 7f 42 seems to be and the
crash in libc-2.33.so[x+158000]
Thanks,
Aurelien
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Bug#1003610: libc6 crashes with VIA C7 and VIA Eden processors starting with 2.33
Package: libc6 Version: 2.33-2 Severity: important After upgrading from libc6 2.32 to 2.33 all machines with a VIA C7 or VIA Eden show segfaults in libc (i.e. hostname fails to work, or rebooting fails). Machines with VIA Nehemiah work fine. I tested again starting with an older version of sid, upgrading all packages but libc6 (pinned to 2.32) (some other packaages could not been updated because they already depend on 2.33). This works fine. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#970156: systemd.socket fails with Failed to queue service startup job (Maybe the service file is missing or not a template unit?): Transport endpoint is not connected
Am Samstag, 12. September 2020, 18:45:07 CEST schrieb Michael Biebl: > Am 12.09.20 um 13:33 schrieb Wolfgang Walter: > > Package: systemd > > Version: 246.4-1 > > Severity: important > > > > Since upgrading (to 246 think) our socket services terminate sometimes > > every hour with: > > > > "Failed to queue service startup job (Maybe the service file is missing or > > not a template unit?): Transport endpoint is not connected" > > > > I think this is this bug: > > > > https://www.spinics.net/lists/systemd-devel/msg04761.html > > https://www.spinics.net/lists/systemd-devel/msg04784.html > > > > So commit 86e045ecefc404d4fccbeb78aa212ec4714a5763 should fix this. > > > > Would it be possible to include this fix into debian's systemd? > > Sure. Would you be willing to confirm that this commit fixes your issue? Thanks for releasing 246.5-1. Faster then I could test this patch :-). 246.5-1 fixes the issue. By the way: thanks to all debian systemd maintainers for their great work. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#970156: systemd.socket fails with Failed to queue service startup job (Maybe the service file is missing or not a template unit?): Transport endpoint is not connected
Package: systemd Version: 246.4-1 Severity: important Since upgrading (to 246 think) our socket services terminate sometimes every hour with: "Failed to queue service startup job (Maybe the service file is missing or not a template unit?): Transport endpoint is not connected" I think this is this bug: https://www.spinics.net/lists/systemd-devel/msg04761.html https://www.spinics.net/lists/systemd-devel/msg04784.html So commit 86e045ecefc404d4fccbeb78aa212ec4714a5763 should fix this. Would it be possible to include this fix into debian's systemd? Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#956640: regression: playing video from ard/zdf on i915 using hardware accelerated video decoding stops working
On Tue, 23 Jun 2020 21:54:09 -0400 Michael Gilbert wrote: > version: 83.0.4103.106-1 > > Hmm, actually 83.0.4103.116-1 doesn't allow setting the hardware decoding experimental flag on i915 any more. So in some sense this is not a real solution :-). Software based decoding already worked in older versions. Regards, Wolfgang Walter -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#963548: Received signal 11 SEGV_MAPERR
On Wed, 24 Jun 2020 13:20:04 +0800 積丹尼 Dan Jacobson wrote: > Now even with 81, browsing Facebook gives Aw Snaps after scrolling down > a bit. > > Anyway I recall this sort of thing happened before. > I'll hope others will do the traces, if my guess is right that many > people will encounter the problem. > > Same here: 83 crashes, often after only a few minutes. Regards, Wolfgang Walter
Bug#962334: .key files not handled correctly in TSIG.pm in version 1.24
Package: libnet-dns-perl
Version: 1.24-1
Hello,
after upgrading from 1.23 to 1.24 I get the following error:
Use of uninitialized value $_[0] in join or string at
/usr/share/perl5/Net/DNS/RR/TSIG.pm line 182.
when I call sign_tsig() with a .key file.
I think the reason is that .key files are now handled as .private file due to
the new code in TSIG.pm, line 384:
$filename =~ m/^K([^+]+)\+\d+\+\d+\./; # BIND
dnssec-keygen
my $key = $1;
if ( $key && $filename =~ /\.key$/ ) {
If it is a .key file, $key will usually be undefined and the code path for
handling .key files will therefore not be entered.
If I change the condition to
if ( ! $key || $filename =~ /\.key$/ ) {
sign_tsig() works fine again.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Bug#941018: ibus 1.5.21-1 does not work with qt5 applications
Package: ibus Version: 1.5.21-1 Severity: serious After upgrading from 1.5.19-4 to 1.5.21-1 all may qt5 ibus stop working with ibus (for example anki, kate, konsole, ...). If one switches to say chinese, nothing happens , the default keyboard remains to input method. Switching input method in chromium, for example, works. Downgrading back to the version in testing (which is 1.5.19-4+b1) fixes the issue. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#917128: Bug
On Sunday, 24 February 2019 09:19:14 CET you wrote: > Control: found -1 241-1 > > Wolfgang Walter [2019-02-23 11:39 +0100]: > > The bug is back again: 241-1 again has this problem. > > So this broke again due to > https://github.com/systemd/systemd/commit/3907446f02 or > https://github.com/systemd/systemd/commit/73d2bb08816 , i. e. as part of > https://github.com/systemd/systemd/pull/11449 . > > The logging should now be improved with v241, particularly which policy was > applied. Do you have a chance to get a journal log (journalctl -b) from such > a broken boot? > Thanks for the commits, this helps a lot. I could not find much more information in the log. Basically I see (which I don't see with 240-6): systemd-udevd[312]: Using default interface naming scheme 'v240'. kernel: ´rename41: renamed from INT ... systemd-udevd[312]: INT: Failed to rename network interface 41 from 'BASE' to 'I': Device or resource busy I'll try again to add the OriginalName=eth* enp* to the match of the .link files and see if this helps and so they won't match the vlan interfaces. I didn#t try to match enp* the last time, because in the log I see eth0 and eth1. The commit message of https://github.com/systemd/systemd/commit/3907446f02 seems to be wrong. It suggests that behaviour will only change if there is a NamePolicy entry in the link file. Actually it will also change behaviour if there is none. So my link files matches vlan interfaces as they have the same mac as the underlying physical device and udev tries to rename it to the name given with Name= whereas previously the IN_SET(name_type, NET_NAME_USER, NET_NAME_RENAMED) (line 402) catched and avoided the change. I think systemd should restore the old behaviour in that sense that if there is NO NamePolicy it also will check for IN_SET(name_type, NET_NAME_USER, NET_NAME_RENAMED). This would be different from https://github.com/systemd/systemd/commit/73d2bb08816 as it only would restore old behaviour for the case that a link file does NOT contain a NamePolicy. How, by the way, does one set the name-scheme to version 239 as commit https://github.com/systemd/systemd/commit/73d2bb08816 implements? I'll try to add NamePolicy=keep to my link file. If I understand the man page and the commit correctly this policy will match for my explicitly named devices (my vlan devices) and they will not be renamed even though they have the same mac and therefor match the link file. For the physical ethernet device which matches the mac-address this NamePolicy will fail and therefor the Name= will be used. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#917128: Bug
Version: 241-1 On Sun, 03 Feb 2019 13:34:19 +0100 Wolfgang Walter wrote: > On Sat, 26 Jan 2019 13:55:33 +0100 Wolfgang Walter > wrote: > > Yes, I tested this with 240-4. > > > > I tested this now again with udev 240-5. > > With 240-5 the problem has disappeared. > > Probably "Revert interface renaming changes. (Closes: The bug is back again: 241-1 again has this problem. Downgrading udev and libudev1 to 240-6 fixes the issue. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#917128: Bug
On Sat, 26 Jan 2019 13:55:33 +0100 Wolfgang Walter wrote: > Yes, I tested this with 240-4. > I tested this now again with udev 240-5. With 240-5 the problem has disappeared. Probably "Revert interface renaming changes. (Closes: #919390)" also fixes this issue. Thanks, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#917128: Bug
Yes, I tested this with 240-4. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#917128: udev 240 breaks network interface naming
On Fri, 11 Jan 2019 17:44:48 +0100 Michael Biebl wrote: > Version: 240-3 > > On Wed, 9 Jan 2019 22:41:24 +0100 Michael Biebl wrote: > > On Fri, 28 Dec 2018 15:24:03 +0100 Wolfgang Walter > > wrote: > > > On Friday, 28 December 2018 15:05:06 CET Michael Biebl wrote: > > > > On Sun, 23 Dec 2018 01:51:00 +0100 Wolfgang Walter > > > > > > > > wrote: > > > > > systemd-networkd from 240-1 though crashes with > > > > > > > > > > Assertion 'IN_SET(link->state, LINK_STATE_CONFIGURING, > > > > > LINK_STATE_CONFIGURING, LINK_STATE_FAILED, LINK_STATE_LINGER)' failed at > > > > > ../src/network/network/networkd-link.c:934, function address_handler(). > > > > > Aborting. > > > > That error message looks a lot like > > > > > > > > https://github.com/systemd/systemd/issues/11272 > > > > > > > > Would you mind testing the pull request at > > > > https://github.com/systemd/systemd/pull/11274 > > > > > > > > If this fixes your problem, we can consider cherry-picking that fix. > > > > > > Will do, but can't do it immediately as I'm not back till 2.1.2019 > > > > I've pulled this patch and applied it to 240-3. > > > As I'm pretty sure this is fixed in 240-3, I'm going to close the bug > report. > Please reopen if you still have problems. > > Regards, > Michael > The renaming problem still exists. I tried to workaround it by changing 10-netint.link as follows: 10-netint.link: [Match] MACAddress=00:01:2e:77:a5:45 Name=eth* [Link] Name=netint WakeOnLan=off As the vlan interface is named kbs this should not match, but the physical interface which starts with eth0 should. But the vlan interface still ist renamed to renameX and later udev wants to change its name into netint, so kbs matches. The systemd-doku says: "A link file is said to match a device if each of the entries in the "[Match]" section matches, or if the section is empty." Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#918900: arptables: alternativ native nicht möglich
Package: arptables Version: 0.0.4+snapshot20181021-2 Severity: important executing update-alternatives --config arptables and then choosing 1 (/usr/sbin/arptables-legacy) leads to the following error: update-alternatives: warning: skip creation of /usr/sbin/arptables-restore because associated file /usr/sbin/arptables-legacy-restore (of link group arptables) doesn't exist update-alternatives: warning: not removing /usr/sbin/arptables-restore since it's not a symlink update-alternatives: warning: skip creation of /usr/sbin/arptables-save because associated file /usr/sbin/arptables-legacy-save (of link group arptables) doesn't exist update-alternatives: warning: not removing /usr/sbin/arptables-save since it's not a symlink Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#918551: ebtables-nft does not know -t broute
Package: iptables Version: 1.8.2-3 Severity: important After upgrading the ebtables packet our routers broke. Reason is that the ebtables command now defaults to ebtables-nft which seems not to support the table broute. Therefor the following command fails: ebtables -t broute -A BROUTING --protocol 802_1Q -j DROP Probably the default should remain the ebtables command provided by the ebtables packet until the ebtables-nft is fully compatible. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#917128: udev 240 breaks network interface naming
> On Sun, 23 Dec 2018 01:51:00 +0100 Wolfgang Walter > > wrote: > > Package: udev > > Version: 240-1 > > Severity: important > > > > After upgrading from 239-15 to 240-1 or higher my network setup breaks. > > > > The breakage is similar to the last one I reported (bug #904198) though > > different in detail. > > > > This times all my vlan-devices on a physical device netint are first > > renamed to renameX and than udev tries to rename them again but this time > > it tries to give them all the name netint - which of course fails. > > > > A setup like the following one should be able to reproduce this problem: > > > > 10-netint.link: > > [Match] > > MACAddress=00:01:2e:77:a5:45 > > > > [Link] > > Name=netint > > WakeOnLan=off > > > > > > netint.network: > > [Match] > > Name=netint > > > > [Network] > > VLAN=kbs > > LinkLocalAddressing=no > > DHCP=no > > > > > > kbs.link > > [NetDev] > > Name=kbs > > Kind=vlan > > > > [VLAN] > > Id=10 > > > > > > > > In the journal you should see something like > > > > kernel: rename31: renamed from kbs > > > > systemd-networkd[852]: kbs: Interface name change detected, kbs has been > > renamed to rename31 > > [347]: kbs: Failed to rename network interface 31 from 'kbs' to 'netint': > > Device or resource busy > > > > > > > > Downgrading udev to 239-15 fixes it in principle that is this rename does > > not happen. > > > > systemd-networkd from 240-1 though crashes with > > > > Assertion 'IN_SET(link->state, LINK_STATE_CONFIGURING, > > LINK_STATE_CONFIGURING, LINK_STATE_FAILED, LINK_STATE_LINGER)' failed at > > ../src/network/network/networkd-link.c:934, function address_handler(). > > Aborting.> > > > Therefor I also had to downgrade systemd back to 239-15. > > Someone mentioned on IRC: > > hmm, 917128 actually comes pre-broken > the reporter is applying renaming based purely on MACAddress, > and that's *already* a problem when VLANs are involved > because they all have the same MAC address as the underlying > physical interface > (which I found out the hard way years ago, with just udev > .rules too) > so the only change is that it was a race previously and a > crash now I can't believe that. Not only did it work since systemd is in debian without any problem, in older version including 239 I could add vlan netdev-devices later and they never were renamed. There has something changed which causes that. Maybe devices created by .netdev simply were excempted renamed as they already get there name by in the [NetDev]-section? I also can't see a workaround as you cannot have a match which says "don't match netdev devices" or simething like that. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#917128: udev 240 breaks network interface naming
On Friday, 28 December 2018 15:05:06 CET Michael Biebl wrote: > On Sun, 23 Dec 2018 01:51:00 +0100 Wolfgang Walter > > wrote: > > systemd-networkd from 240-1 though crashes with > > > > Assertion 'IN_SET(link->state, LINK_STATE_CONFIGURING, > > LINK_STATE_CONFIGURING, LINK_STATE_FAILED, LINK_STATE_LINGER)' failed at > > ../src/network/network/networkd-link.c:934, function address_handler(). > > Aborting. > That error message looks a lot like > > https://github.com/systemd/systemd/issues/11272 > > Would you mind testing the pull request at > https://github.com/systemd/systemd/pull/11274 > > If this fixes your problem, we can consider cherry-picking that fix. Will do, but can't do it immediately as I'm not back till 2.1.2019 > > Regards, > Michael Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#917128: udev 240 breaks network interface naming
Package: udev Version: 240-1 Severity: important After upgrading from 239-15 to 240-1 or higher my network setup breaks. The breakage is similar to the last one I reported (bug #904198) though different in detail. This times all my vlan-devices on a physical device netint are first renamed to renameX and than udev tries to rename them again but this time it tries to give them all the name netint - which of course fails. A setup like the following one should be able to reproduce this problem: 10-netint.link: [Match] MACAddress=00:01:2e:77:a5:45 [Link] Name=netint WakeOnLan=off netint.network: [Match] Name=netint [Network] VLAN=kbs LinkLocalAddressing=no DHCP=no kbs.link [NetDev] Name=kbs Kind=vlan [VLAN] Id=10 In the journal you should see something like kernel: rename31: renamed from kbs systemd-networkd[852]: kbs: Interface name change detected, kbs has been renamed to rename31 [347]: kbs: Failed to rename network interface 31 from 'kbs' to 'netint': Device or resource busy Downgrading udev to 239-15 fixes it in principle that is this rename does not happen. systemd-networkd from 240-1 though crashes with Assertion 'IN_SET(link->state, LINK_STATE_CONFIGURING, LINK_STATE_CONFIGURING, LINK_STATE_FAILED, LINK_STATE_LINGER)' failed at ../src/network/network/networkd-link.c:934, function address_handler(). Aborting. Therefor I also had to downgrade systemd back to 239-15. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#907345: After upgrading from 5.10.1+dfsg-6 to 5.10.1+dfsg-7 akonadi imap stops working - possibly OpenSSL 1.1.1
Am Montag, 27. August 2018, 23:02:35 schrieben Sie: > Hey, > > > I think this bug-report can be closed. > > you can do this by your own if you send a mail at > 907345-d...@bugs.debian.org. > > The problems disappears if openssl is also upgraded to version > > 1.1.1~~pre9-1 (from 1.1.0h-4). So this problem only exists with openssl < > > 1.1.1~~pre9-1. > Wait - this is all very strange you say you have Qt 5.10.1+dfsg-6 installed > and OpenSSL 1.1.1~~pre9-1. Hmm, I'm afraid I wanted to write 5.11.1+dfsg-6 to 5.11.1+dfsg-7 Don't know why I typed 5.10, sorry for that. So the problem was: I upgraded libqt5core5a etc. from 5.11.1+dfsg-6 to 5.11.1+dfsg-7 but I did not upgrade openssl from 1.1.0h-4 to 1.1.1~~pre9-1, then. Under these conditions akonadi failed to access the imap server via TLS. After also upgrading openssl from 1.1.0h-4 to 1.1.1~~pre9-1 akonadi worked again. Regards and sorry for the wrong version numbers. -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#907345: After upgrading from 5.10.1+dfsg-6 to 5.10.1+dfsg-7 akonadi imap stops working
I think this bug-report can be closed. The problems disappears if openssl is also upgraded to version 1.1.1~~pre9-1 (from 1.1.0h-4). So this problem only exists with openssl < 1.1.1~~pre9-1. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#907049: openssl: Update to 1.1.1~~pre9-1 makes certain programs unusable
This version of openssl also eventually breaks unbound-control of package unbound for some people: unbound-control may gives an error: 140493601018752:error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small:../ssl/ssl_rsa.c:310 outcommenting #CipherString = DEFAULT@SECLEVEL=2 fixes this. The real fix is probably to generate new keys for unbound-control and unbound with unbound-control-setup. Just calling unbound-control-setup is not enough, though, as unbound-control does not create new ones if these keys already exists. So the existing ones have to be removed first. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#907345: After upgrading from 5.10.1+dfsg-6 to 5.10.1+dfsg-7 akonadi imap stops working
Package: qtbase-opensource-src Version: 5.10.1+dfsg-7 Severity: important After upgrading from version 5.10.1+dfsg-6 to version 5.10.1+dfsg-7 akonadi's imap resource does not work any more (at least with IPv6 + TLS). It permanently tries to establish a connection but fails to do so. It logs: org.kde.pim.kimap: Connection to server lost 0 On the server side one can see that akonadi establish a connection but then close it immediately and then tires again ... Dowgrading to 5.10.1+dfsg-6 fixes the problem. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#904198: udev 239 breaks network interface naming
Package: udev Version: 239-1 Severity: important After upgrading from 238-5 to 239-1 or higher my network setup breaks. Basically all interfaces which do NOT have a mac-address (like tun devices, sit-tunnels, etc) are now matched by the first .link file which matches on the mac-address and udev tries to rename them all to this name (in this case netint) The log shows for all of them: systemd-networkd[768]: rename6: Interface name change detected, rename6 has been renamed to sit0. systemd-networkd[768]: sit0: Interface name change detected, sit0 has been renamed to rename6. As netint is already in use they all end as renameX... For devices which have a mac-address all works fine (like hardware ethernet devices, tap devices etc). Downgrading to udev 239-5 und libudev1 239-5 fixes the problem. A setup like the following one should be able to reproduce this problem: 10-netint.link: [Match] MACAddress=00:01:2e:77:a5:45 [Link] Name=netint WakeOnLan=off mytun.netdev: [NetDev] Name=mytun Kind=tun [Tun] You then should see log entries like systemd-networkd[768]: rename6: Interface name change detected, rename6 has been renamed to mytun. systemd-networkd[768]: mytun: Interface name change detected, sit0 has been renamed to rename6. and further lines like kernel: rename6: renamed from mytun systemd-udevd[280]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. systemd-udevd[280]: Could not set WakeOnLan of mytun to off: Operation not supported There will be now device mytun but instead be a renameX. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#891511: ip route flush all does not work any more
Package: iproute2 Version: 4.15.0-2 Hello, after upgrading iproute2 from 4.14.1-2 to 4.15.0-2 ip route flush all seems not to work any more. It does not remove all ipv4 routes from the main table as it did before. Downgrading to 4.14.1-2 fixes the problem. Basically 4.15.0-2 removes the default route, but other routes are not removed. What still works is ip route flush table main Another thing which changed is that ip route ls all now does not show anything but the default route whereas it used to show all routes of the main table. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#886342: systemd-networkd: Unknown section 'Tap'. Ignoring.
On Thursday, 4 January 2018 19:54:41 CET Michael Biebl wrote: > Am 04.01.2018 um 19:30 schrieb Wolfgang Walter: > > Package: systemd > > Version: 236-2 > > > > Problem: since upgrading to 236-1 I get the following error: > > > > systemd-networkd:[810]: /etc/systemd/network/tunnel.netdev: :5: Unknown > > section 'Tap'. Ignoring. I'm not familiar with the source code of systemd, but this false warnings may result from network/netdev/netdev.c, line 603: netdev_load_one() this functions calls config_parse_many() from shared/conf_parser.c. The first time netdev_load_one() calls it (line 634) to inspect the sections Match and NetDev because it does not know at that point which kind of netdev will be defined. In shared/conf-parser.c config_parse_many() calls config_parse_many_files() => config_parse() => parse_line(). parse_line() emits that warning in line 229 of shared/conf_parser.c when it parses the VLAN/MACVTAP/... section as in this first call netdev_load_one() does not include them in the list of valid sections. Maybe netdev_load_one() should set the flag CONFIG_PARSE_RELAXED for the first call. I looked at the code https://sources.debian.org/src/systemd/236-2/src/ Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#886342: systemd-networkd: Unknown section 'Tap'. Ignoring.
Hello Michael, thanks for your answer. On Thursday, 4 January 2018 19:54:41 CET Michael Biebl wrote: > Am 04.01.2018 um 19:30 schrieb Wolfgang Walter: > > Package: systemd > > Version: 236-2 > > > > Problem: since upgrading to 236-1 I get the following error: > > > > systemd-networkd:[810]: /etc/systemd/network/tunnel.netdev: :5: Unknown > > section 'Tap'. Ignoring. > Please share the complete file. > > Have you rebooted after upgrading to v236? Yes. Several times. Indeed I just rebooted a couple of times since 18.12.2017 different machines and they every time logged these things. Example #1: == [NetDev] Name=int Kind=vlan [VLAN] Id=2567 == Example #2: == [NetDev] Name=mail Kind=macvtap [MACVTAP] Mode=bridge == Example #3: == [NetDev] Name=tunnel Kind=tap [Tap] User=otunnel Group=otunnel == Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#886342: systemd-networkd: Unknown section 'Tap'. Ignoring.
Package: systemd Version: 236-2 Problem: since upgrading to 236-1 I get the following error: systemd-networkd:[810]: /etc/systemd/network/tunnel.netdev: :5: Unknown section 'Tap'. Ignoring. The same problem exists with other kinds as VLAN MACVTAP I did not change these .netdev files, and I checked again that the spelling (case wise) of the section name is correct according to the manpage. It seems, by the way, that systemd-nentworkd does NOT ignore these sections, as the interfaces are set up correctly. Especially all vlan interfaces have the Id as given in the "ignored" section. This is the reason I didn't detect this bug earlier. But according to my logfiles I have these messaged logged since upgrading to 236-1. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#871477: [Pkg-openssl-devel] Bug#871477: upgrade of libssl1.1 to breaks dovecot imap via tls: kmail from debian stable/unstable cannot connect to dovecot any more
Am Dienstag, 8. August 2017, 15:13:23 schrieben Sie: > reassign kmail 4:16.04.3-3 > thanks > > On Tue, Aug 08, 2017 at 12:44:09PM +0200, Wolfgang Walter wrote: > > Package: libssl1.1 > > Version: 1.1.0f-4 > > Severity: important > > > > After upgrading a server to libssl1.1 1.1.0f-4 kmail on debian/stable could > > not connect to dovecot on debian/unstable any more (kmail on > > debian/unstable can't connect, either). > > > > Dovecot logs "... tls_process_client_hello:version too low ..." > > > > Probably this is due to "Disable TLS 1.0 and 1.1". > > > > Please reactivate it. We would like to continue our policy to continously > > test debian/unstable and debian/testing on servers in our environment. > > I'm going to start with reassigning this to kmail. I believe all > such issues should get fixed, and that they should get fixed in > stable and maybe oldstable too. > But this also exists in ubuntu and other systems. I agree that it would be good to fix that in debian/stable and debian/oldstable anyway (if it is indeed a kmail problem). But disabling TLS 1.0 and 1.1 in openssl directly to find other (mostly remote, often other people's) systems is bad. It makes testing unstable much harder because you have to rebuild openssl yourself with TLS 1.0 and 1.1 reactivated. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#871477: upgrade of libssl1.1 to breaks dovecot imap via tls: kmail from debian stable/unstable cannot connect to dovecot any more
Am Dienstag, 8. August 2017, 13:31:30 schrieb Sebastian Andrzej Siewior: > On 2017-08-08 12:44:09 [+0200], Wolfgang Walter wrote: > > Package: libssl1.1 > > Version: 1.1.0f-4 > > Severity: important > > > > After upgrading a server to libssl1.1 1.1.0f-4 kmail on debian/stable could > > not connect to dovecot on debian/unstable any more (kmail on > > debian/unstable can't connect, either). > > > > Dovecot logs "... tls_process_client_hello:version too low ..." > > Is this broken with kmail only or are other clients affected, too? Don't know. Not tried yet. > > > Probably this is due to "Disable TLS 1.0 and 1.1". > > Yes but why? studlmu.lrz.de:993 handshakes here with TLS1.2. openssl in > previous releases supports TLS1.2. So something limited it to TLS1.0 > and/or 1.1 only. > > > Please reactivate it. We would like to continue our policy to continously > > test debian/unstable and debian/testing on servers in our environment. > > Did you limit on kmail side the connection somewhere to TLS1.0 only? > We run kmail es provided by debian/stable or debian/unstable. I didn't check other clients, so I don't know if kmail does not speak TLS1.2 > If not, does this help (patch against kio): > Don't know if I have time to rebuild a kde paket (kio). I'll try another client first. Even if this is a limitation of kmail I still think it is a rather bad idea to limit openssl for unstable to TLS1.2. I don't think that an upgrade to buster should also enforce simultanous updates for a lot of other machines be it clients or servers, so TLS1.0 and TLS1.1 probably must be reenabled for buster anyway. The main effect will be that it is just harder to test unstable/testing. > diff --git a/src/core/ktcpsocket.h b/src/core/ktcpsocket.h > index 75e1f8c4489a..4ff674d8abc1 100644 > --- a/src/core/ktcpsocket.h > +++ b/src/core/ktcpsocket.h > @@ -163,7 +163,7 @@ class KIOCORE_EXPORT KTcpSocket: public QIODevice > TlsV1_0 = TlsV1, > TlsV1_1 = 0x40, > TlsV1_2 = 0x80, > -AnySslVersion = SslV2 | SslV3 | TlsV1 > +AnySslVersion = SslV2 | SslV3 | TlsV1 | TlsV1_1 | TlsV1_2 > }; > Q_DECLARE_FLAGS(SslVersions, SslVersion) > > > I Cc qt/kdepim/kio folks in case they have a clue who is limmiting this. > Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#871477: upgrade of libssl1.1 to breaks dovecot imap via tls: kmail from debian stable/unstable cannot connect to dovecot any more
Package: libssl1.1 Version: 1.1.0f-4 Severity: important After upgrading a server to libssl1.1 1.1.0f-4 kmail on debian/stable could not connect to dovecot on debian/unstable any more (kmail on debian/unstable can't connect, either). Dovecot logs "... tls_process_client_hello:version too low ..." Probably this is due to "Disable TLS 1.0 and 1.1". Please reactivate it. We would like to continue our policy to continously test debian/unstable and debian/testing on servers in our environment. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#851503: [pkg-dhcp-devel] Bug#851503: dhcprelay stops working for bridge-interfaces
On Sun, 22 Jan 2017 20:45:34 +0100 Wolfgang Walter <wolfgang.wal...@stwm.de> wrote: > On Sun, 22 Jan 2017 17:57:51 +0100 Wolfgang Walter <wolfgang.wal...@stwm.de> > wrote: > > On Sun, 15 Jan 2017 12:46:11 -0500 Michael Gilbert <mgilb...@debian.org> > > wrote: > > > control: tag -1 moreinfo > > > > > > On Sun, Jan 15, 2017 at 12:23 PM, Wolfgang Walter wrote: > > > > After upgrading from 4.3.5-1 to 4.3.5-3 relaying bridge interfaces seem > > > > not to work any more: > > > > > > dhcommon-getifaddrs.patch is the only thing I think that would have > > > touched dhcrelay during the last two updates. Can you try unapplying > > > that patch? > > > > I built dhcrelay without that patch: it works fine, then. > > I have to correct me: it does not work. > Just to correct me again: it works without that patch. unattended-upgrades just installed the repo-version over it. So: 4.3.5-3 without dhcommon-getifaddrs.patch works. Sorry for the noise, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#851503: [pkg-dhcp-devel] Bug#851503: dhcprelay stops working for bridge-interfaces
On Sun, 22 Jan 2017 17:57:51 +0100 Wolfgang Walter <wolfgang.wal...@stwm.de> wrote: > On Sun, 15 Jan 2017 12:46:11 -0500 Michael Gilbert <mgilb...@debian.org> > wrote: > > control: tag -1 moreinfo > > > > On Sun, Jan 15, 2017 at 12:23 PM, Wolfgang Walter wrote: > > > After upgrading from 4.3.5-1 to 4.3.5-3 relaying bridge interfaces seem > > > not to work any more: > > > > dhcommon-getifaddrs.patch is the only thing I think that would have > > touched dhcrelay during the last two updates. Can you try unapplying > > that patch? > > I built dhcrelay without that patch: it works fine, then. I have to correct me: it does not work. > > > > > The only other thing I can think of is that and dhcrelay-listen.patch > > do not interact correctly, so you could try unapplying that > > separately. > > > > It would also help if you could test 4.3.5-2 to make sure it wasn't a > > change in that version, which I think is unlikely. > > > > Best wishes, > > Mike > > > > > Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#851503: [pkg-dhcp-devel] Bug#851503: dhcprelay stops working for bridge-interfaces
On Sun, 15 Jan 2017 12:46:11 -0500 Michael Gilbert <mgilb...@debian.org> wrote: > control: tag -1 moreinfo > > On Sun, Jan 15, 2017 at 12:23 PM, Wolfgang Walter wrote: > > After upgrading from 4.3.5-1 to 4.3.5-3 relaying bridge interfaces seem > > not to work any more: > > dhcommon-getifaddrs.patch is the only thing I think that would have > touched dhcrelay during the last two updates. Can you try unapplying > that patch? I built dhcrelay without that patch: it works fine, then. > > The only other thing I can think of is that and dhcrelay-listen.patch > do not interact correctly, so you could try unapplying that > separately. > > It would also help if you could test 4.3.5-2 to make sure it wasn't a > change in that version, which I think is unlikely. > > Best wishes, > Mike > > Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#851503: dhcprelay stops working for bridge-interfaces
Package: isc-dhcp-relay Version: 4.3.5-3 Severity: important After upgrading from 4.3.5-1 to 4.3.5-3 relaying bridge interfaces seem not to work any more: I have three interfaces A, B, C part of a bridge X. In /etc/default/isc-dhcp-relay I set INTERFACES="X" After upgrading I get the following errors if a device connected via A makes an dhcp-reqest: Jan 15 17:38:02 wuschel dhcrelay[1573]: Discarding packet received on A interface that has no IPv4 address assigned. Jan 15 17:38:02 wuschel dhcrelay[1573]: Discarding packet received on B interface that has no IPv4 address assigned. Jan 15 17:38:02 wuschel dhcrelay[1573]: Discarding packet received on C interface that has no IPv4 address assigned. As these interfaces are bridge ports they don't have an IP-address. X has one but dhcprelay seems not consider X any more. Instead it considers B and C where the packet has not been received from. Downgrading to 4.3.5-1 fixes the problem. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#850430: fixed in postfix 3.1.4-2
On Fri, 06 Jan 2017 16:49:17 + LaMont Jones <lam...@debian.org> wrote: > Source: postfix > Source-Version: 3.1.4-2 > > We believe that the bug you reported is fixed in the latest version of > postfix, which is due to be installed in the Debian FTP archive. This does not fix the problem here. What fixes the problem is making a symlink to smtp called lmtp and changing master.cf to call lmtp instead of smtp. I don't think you can call smtp as smtp if you want it to act in lmtp mode. Here code from smtp.c: (from https://git.launchpad.net/postfix/tree/src/smtp/smtp.c?h=stable/v3.1) /* * XXX At this point, var_procname etc. are not initialized. * * The process name, "smtp" or "lmtp", determines the protocol, the DSN * server reply type, SASL service information lookup, and more. Prepare * for the possibility there may be another personality. */ sane_procname = sane_basename((VSTRING *) 0, argv[0]); if (strcmp(sane_procname, "smtp") == 0) smtp_mode = 1; else if (strcmp(sane_procname, "lmtp") == 0) smtp_mode = 0; So I think there must be a link lmtp => smtp and in master.cf it sould be lmtp unix - - - - - lmtp Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#841420: --enable-default-pie breaks kernel builds
On Friday, 21 October 2016 14:45:25 CEST Ritesh Raj Sarraf wrote: > The Debian kernel packages still have a dependency on gcc-5, which may mean > that the kernels are currently only built/supported with gcc-5. vanilla kernels (Linus' tree and the stable ones) could be compiled just fine with gcc 6.2.0-6 and that now fails. I still think this is a major regression and regard gcc 6.2.0-7 simply as broken. > > On Thu, 2016-10-20 at 11:22 -0500, S R Wright wrote: > > Concurring with Wolfgang; pulling the source straight from kernel.org > > and using identical .config files will work with 6.2.0-6 but fail with > > 6.2.0-7. I was able to build and install 4.8.3 with no issues after > > back-revving gcc et. al. to 6.2.0-6 > > > > -- sRw > > > > On 10/20/16 11:09, Wolfgang Walter wrote: > > > Hello, > > > > > > with this version of gcc-6 I can't build vanilla kernels any more. It > > > fails > > > with even with CC_STACKPROTECTOR_STRONG disabled: > > > > > > scripts/kconfig/mconf Kconfig > > > configuration written to .config > > > > > > *** End of the configuration. > > > *** Execute 'make' to start the build or try 'make help'. > > > > > > ksrc@ei:~/build/kernels/linux-4.8.3$ make > > > scripts/kconfig/conf --silentoldconfig Kconfig > > >CHK include/config/kernel.release > > >CHK include/generated/uapi/linux/version.h > > >CHK include/generated/utsrelease.h > > >UPD include/generated/utsrelease.h > > >CC kernel/bounds.s > > > kernel/bounds.c:1:0: error: code model kernel does not support PIC mode > > > /* > > > > > > Kbuild:45: recipe for target 'kernel/bounds.s' failed > > > make[1]: *** [kernel/bounds.s] Error 1 > > > Makefile:1015: recipe for target 'prepare0' failed > > > make: *** [prepare0] Error 2 > > > > > > > > > I think this is a major regression if you can't build vanilla and stable > > > kernels any more. > > > > > > Regards, Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#841420: --enable-default-pie breaks kernel builds
Hello, with this version of gcc-6 I can't build vanilla kernels any more. It fails with even with CC_STACKPROTECTOR_STRONG disabled: scripts/kconfig/mconf Kconfig configuration written to .config *** End of the configuration. *** Execute 'make' to start the build or try 'make help'. ksrc@ei:~/build/kernels/linux-4.8.3$ make scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h CC kernel/bounds.s kernel/bounds.c:1:0: error: code model kernel does not support PIC mode /* Kbuild:45: recipe for target 'kernel/bounds.s' failed make[1]: *** [kernel/bounds.s] Error 1 Makefile:1015: recipe for target 'prepare0' failed make: *** [prepare0] Error 2 I think this is a major regression if you can't build vanilla and stable kernels any more. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#837759: network configuration stops working reliably
Hello Martin, On Monday, 19 September 2016 16:24:12 CEST Martin Pitt wrote: > Control: severity -1 important > Contro: tag -1 unreproducible > > In accordance with the severity definitions [1] I downgrade this to > "important". It does not completely break systemd, we don't enable > networkd by default, and it does not affect every installation (it's > not reproducible on our side yet). > > Don't worry, I'm still eager to find out what's happening here; I'll > look at your logs as soon as possible. > > Martin > > [1] https://www.debian.org/Bugs/Developer#severities Ok, here as attachment is the log with debugging enabled for systemd-networkd. In this boot net and TEST have lost all there ip-adresses. The logs shows that it is systemd-networkd which removes them. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts-- Logs begin at Sat 2016-07-02 20:15:26 CEST, end at Mon 2016-09-19 21:24:41 CEST. -- Sep 19 21:24:03 maiskolben systemd-journald[182]: Runtime journal (/run/log/journal/) is 1.2M, max 9.9M, 8.7M free. Sep 19 21:24:03 maiskolben kernel: Initializing cgroup subsys cpuset Sep 19 21:24:03 maiskolben kernel: Initializing cgroup subsys cpu Sep 19 21:24:03 maiskolben kernel: Initializing cgroup subsys cpuacct Sep 19 21:24:03 maiskolben kernel: Linux version 4.4.21-debianlike64x+1.4 (root@maiskolben) (gcc version 6.2.0 20160901 (Debian 6.2.0-3) ) #1 SMP PREEMPT Thu Sep 15 21:25:55 CEST 2016 Sep 19 21:24:03 maiskolben kernel: Command line: root=/dev/sda quiet Sep 19 21:24:03 maiskolben kernel: x86/fpu: Legacy x87 FPU detected. Sep 19 21:24:03 maiskolben kernel: x86/fpu: Using 'lazy' FPU context switches. Sep 19 21:24:03 maiskolben kernel: e820: BIOS-provided physical RAM map: Sep 19 21:24:03 maiskolben kernel: BIOS-e820: [mem 0x-0x0009fbff] usable Sep 19 21:24:03 maiskolben kernel: BIOS-e820: [mem 0x0009fc00-0x0009] reserved Sep 19 21:24:03 maiskolben kernel: BIOS-e820: [mem 0x000f-0x000f] reserved Sep 19 21:24:03 maiskolben kernel: BIOS-e820: [mem 0x0010-0x3ffdcfff] usable Sep 19 21:24:03 maiskolben kernel: BIOS-e820: [mem 0x3ffdd000-0x3fff] reserved Sep 19 21:24:03 maiskolben kernel: BIOS-e820: [mem 0xfeffc000-0xfeff] reserved Sep 19 21:24:03 maiskolben kernel: BIOS-e820: [mem 0xfffc-0x] reserved Sep 19 21:24:03 maiskolben kernel: NX (Execute Disable) protection: active Sep 19 21:24:03 maiskolben kernel: SMBIOS 2.8 present. Sep 19 21:24:03 maiskolben kernel: DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014 Sep 19 21:24:03 maiskolben kernel: Hypervisor detected: KVM Sep 19 21:24:03 maiskolben kernel: e820: update [mem 0x-0x0fff] usable ==> reserved Sep 19 21:24:03 maiskolben kernel: e820: remove [mem 0x000a-0x000f] usable Sep 19 21:24:03 maiskolben kernel: e820: last_pfn = 0x3ffdd max_arch_pfn = 0x4 Sep 19 21:24:03 maiskolben kernel: MTRR default type: write-back Sep 19 21:24:03 maiskolben kernel: MTRR fixed ranges enabled: Sep 19 21:24:03 maiskolben kernel: 0-9 write-back Sep 19 21:24:03 maiskolben kernel: A-B uncachable Sep 19 21:24:03 maiskolben kernel: C-F write-protect Sep 19 21:24:03 maiskolben kernel: MTRR variable ranges enabled: Sep 19 21:24:03 maiskolben kernel: 0 base 008000 mask FF8000 uncachable Sep 19 21:24:03 maiskolben kernel: 1 disabled Sep 19 21:24:03 maiskolben kernel: 2 disabled Sep 19 21:24:03 maiskolben kernel: 3 disabled Sep 19 21:24:03 maiskolben kernel: 4 disabled Sep 19 21:24:03 maiskolben kernel: 5 disabled Sep 19 21:24:03 maiskolben kernel: 6 disabled Sep 19 21:24:03 maiskolben kernel: 7 disabled Sep 19 21:24:03 maiskolben kernel: x86/PAT: PAT not supported by CPU. Sep 19 21:24:03 maiskolben kernel: x86/PAT: Configuration [0-7]: WB WT UC- UC WB WT UC- UC Sep 19 21:24:03 maiskolben kernel: found SMP MP-table at [mem 0x000f6610-0x000f661f] mapped at [880f6610] Sep 19 21:24:03 maiskolben kernel: Base memory trampoline at [88099000] 99000 size 24576 Sep 19 21:24:03 maiskolben kernel: BRK [0x01c7a000, 0x01c7afff] PGTABLE Sep 19 21:24:03 maiskolben kernel: BRK [0x01c7b000, 0x01c7bfff] PGTABLE Sep 19 21:24:03 maiskolben kernel: BRK [0x01c7c000, 0x01c7cfff] PGTABLE Sep 19 21:24:03 maiskolben kernel: BRK [0x01c7d000, 0x01c7dfff] PGTABLE Sep 19 21:24:03 maiskolben kernel: RAMDISK: [mem 0x3f08c000-0x3ffc] Sep 19 21:24:03 maiskolben kernel: ACPI: Early table checksum verification disabled Sep 19 21:24:03 maiskolben kernel: ACPI: RSDP 0x000F6440 14 (v00 BOCHS ) Sep 19 21:24:03 maiskolben kernel: ACPI: RSDT 0x3FFE1737 30 (v01 BOCHS BXPCRSDT 0001 BXPC 0001) Sep 19 21:24:03 maiskolben kernel: ACPI: FACP 0x3FFE1613 74 (v01 BOCHS BXPCFACP 00
Bug#837759: network configuration stops working reliably
Hello Martin, On Monday, 19 September 2016 11:02:08 CEST Martin Pitt wrote: > Hello Wolfgang, > > Wolfgang Walter [2016-09-14 23:34 +0200]: > > > > I tested this with a script: > FTR, I tried this as welll, and I cannot reproduce the bug either. > > Wolfgang Walter [2016-09-14 17:56 +0200]: > > Yes, systemd-networkd ist active. But on most machines I only have *.link > > > entries, usually one to name the device: > *.link entries are handled by udev, not networkd. So if you can > reproduce this on a machine with only has files like > > > == > > [Match] > > MACAddress=11:22:33:44:55:66 > > > > [Link] > > Name=net > > WakeOnLan=off > > == > > then can you please "systemctl disable --now systemd-networkd" and > check if the problem still happens? I suppose not, but if so, this > tells us that this is being done through udev. When I disable systemd-networkd the problem disappears. The reason I think it is a race is because it depends on how many interfaces you set up, if you use systemd-networkd to setup some interfaces and the number of ip-addresses and things you do in /etc/network/interfaces. For example on that simple machines where I only have *.link and don't use systemd-networkd: sometimes (maybe 2 out of 10) it works, but most of the time I loose some or all ip-adresses. Here is the log (without) debugging: in this case the interface only kept the IPv6 addresses and lost its ipv4 address, all set up in /etc/network/interfaces. Sep 19 11:33:25 maiskolben systemd[1]: Starting Raise network interfaces... Sep 19 11:33:25 maiskolben systemd[1]: Starting Network Service... Sep 19 11:33:26 maiskolben systemd-networkd[480]: Enumeration completed Sep 19 11:33:26 maiskolben systemd-networkd[480]: net: Lost carrier Sep 19 11:33:26 maiskolben systemd-networkd[480]: net: Gained carrier Sep 19 11:33:26 maiskolben systemd[1]: Started Network Service. Sep 19 11:33:27 maiskolben systemd-networkd[480]: net: Gained IPv6LL Sep 19 11:33:27 maiskolben ifup[352]: Waiting for DAD... Done Sep 19 11:33:27 maiskolben systemd[1]: Started Raise network interfaces. But there is nothing special about ipv4-addresses. With more interfaces one may loose some or all of the ipv6 adresses, too. I think the crucial point is that systemd-networkd may declares the interface "net" unamanaged AFTER "net: Lost carrier" so that all addresses confgured until that point are ripped off. This " Lost carrier" is always there on startup, don't know if this is caused by udev when it detects the interface on startup. Here is the log with systemd-networkd disabled: Sep 19 11:37:20 maiskolben systemd[1]: Starting Raise network interfaces... Sep 19 11:37:22 maiskolben ifup[400]: Waiting for DAD... Done Sep 19 11:37:23 maiskolben systemd[1]: Started Raise network interfaces. > > If networkd itself is really the culprit, can you please try the > following: > > * Keep it disabled, run your test.sh to set up the dummy interface, >and run > > SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd > > (as root). Does this now cause the addresses to be removed? This > will run much later than test.sh, so this will tell us if this is a > principal logic error or a race condition, i. e. only happens if > networkd starts at the right time after test.sh. No, I don't loose any addresses then. But as you see there is no such "net: Lost carrier" or "TEST: Lost carrier" and so on. SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd Found container virtualization none Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a Got message type=method_return sender=org.freedesktop.DBus destination=:1.3 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=AddMatch cookie=2 reply_cookie=0 error=n/a Got message type=method_return sender=org.freedesktop.DBus destination=:1.3 object=n/a interface=n/a member=n/a cookie=3 reply_cookie=2 error=n/a Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=RequestName cookie=3 reply_cookie=0 error=n/a Got message type=method_return sender=org.freedesktop.DBus destination=:1.3 object=n/a interface=n/a member=n/a cookie=5 reply_cookie=3 error=n/a Failed to open configuration file '/etc/systemd/networkd.conf': No such file or directory timestamp of '/etc/systemd/network' changed timestamp of '/lib/systemd/network' changed TEST: Flags change: +UP +LOWER_UP +RUNNING
Bug#837759: network configuration stops working reliably
On Wednesday, 14 September 2016 10:00:28 CEST Felipe Sateler wrote: > Control: tags -1 moreinfo > > On 14 September 2016 at 06:59, Wolfgang Walter <wolfgang.wal...@stwm.de> > wrote: > > Package: systemd > > Version: 231-6 > > Severity: grave > > > > Starting with version 231-6 the configuration of network interfaces stops > > working reliably when rebooting a system. Downgrading to 231-5 fixes the > > problem. > > > > Symptoms: If a network interface is configured using > > /etc/network/interfaces it seems that systemd now sometimes removes the > > configured ip4 and/or ipv6 addresses in the boot process. It also seems > > to remove routes of network interfaces configured manually or with > > /etc/network/interfaces if the link state changes. > > > > This seems not only be the case with interfaces configured via > > /etc/network/ interfaces but with any interface one creates and assigns > > ip addresses manually. > > > > I tested this with a script: > > > > #!/bin/sh > > if [ "$1" = start ]; then > > ip link del TEST >/dev/null 2>&1 || true > > ip link add name TEST type dummy > > ip -b - <<"EOF" > > link set TEST up > > addr add 10.10.10.10/32 dev TEST nodad > > addr add 2a01:1:1:1::1/128 dev TEST nodad > > addr add 2a01:1:1:1::2/128 dev TEST nodad > > addr add 2a01:1:1:1::3/128 dev TEST nodad > > addr add 2a01:1:1:1::4/128 dev TEST nodad > > addr add 2a01:1:1:1::5/128 dev TEST nodad > > EOF > > ip addr ls TEST > > sleep 2 > > elif [ "$1" = stop ]; then > > ip addr flush dev TEST > > ip link del TEST > > fi > > > > which I start with as a systemd oneshot service with > > > > Before=systemd-networkd.service > > > > I can see in the journal that TEST has all adresses assigned but with > > 231-6 it looses them again (probably when systemd-networkd.service > > starts). With 231-5 or earlier this in not the case. > > It appears you are using systemd-networkd. Could you please attach > your networkd configuration? > > Version 231-6 is built with iptables support, so that may be causing > an interaction that was not visible before. I think this is the problem: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=debian/231-6=79e10aaee1cdd412bd42f13f26e558ba1cd2196b I suppose is that the check for LINK_STATE_UNMANAGED may be racy. The interface may go down and up before LINK_STATE_UNMANAGED is set. Maybe the state is LINK_STATE_PENDING ? Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#837759: network configuration stops working reliably
Am Mittwoch, 14. September 2016, 10:00:28 schrieben Sie: > Control: tags -1 moreinfo > > On 14 September 2016 at 06:59, Wolfgang Walter <wolfgang.wal...@stwm.de> wrote: > > Package: systemd > > Version: 231-6 > > Severity: grave > > > > Starting with version 231-6 the configuration of network interfaces stops > > working reliably when rebooting a system. Downgrading to 231-5 fixes the > > problem. > > > > Symptoms: If a network interface is configured using > > /etc/network/interfaces it seems that systemd now sometimes removes the > > configured ip4 and/or ipv6 addresses in the boot process. It also seems > > to remove routes of network interfaces configured manually or with > > /etc/network/interfaces if the link state changes. > > > > This seems not only be the case with interfaces configured via > > /etc/network/ interfaces but with any interface one creates and assigns > > ip addresses manually. > > > > I tested this with a script: > > > > #!/bin/sh > > if [ "$1" = start ]; then > > ip link del TEST >/dev/null 2>&1 || true > > ip link add name TEST type dummy > > ip -b - <<"EOF" > > link set TEST up > > addr add 10.10.10.10/32 dev TEST nodad > > addr add 2a01:1:1:1::1/128 dev TEST nodad > > addr add 2a01:1:1:1::2/128 dev TEST nodad > > addr add 2a01:1:1:1::3/128 dev TEST nodad > > addr add 2a01:1:1:1::4/128 dev TEST nodad > > addr add 2a01:1:1:1::5/128 dev TEST nodad > > EOF > > ip addr ls TEST > > sleep 2 > > elif [ "$1" = stop ]; then > > ip addr flush dev TEST > > ip link del TEST > > fi > > > > which I start with as a systemd oneshot service with > > > > Before=systemd-networkd.service > > > > I can see in the journal that TEST has all adresses assigned but with > > 231-6 it looses them again (probably when systemd-networkd.service > > starts). With 231-5 or earlier this in not the case. > > It appears you are using systemd-networkd. Could you please attach > your networkd configuration? Yes, systemd-networkd ist active. But on most machines I only have *.link entries, usually one to name the device: == [Match] MACAddress=11:22:33:44:55:66 [Link] Name=net WakeOnLan=off == Most of them are virtual machines. On those machine where I also habe *.netdev and *.network entries this also happens. The one with the simpliest has only one *.network: == [Match] Name=net [Network] LinkLocalAddressing=ipv6 IPv6AcceptRouterAdvertisements=no DHCP=no Address=10.11.12.13/24 Gateway=10.11.12.1 Address=2001:1234:1::abc1 Address=2001:1234:1::abc2 Address=2001:1234:1::abc3 Address=2001:1234:1::abc4 NTP=2001:1234:1::123 [Route] Gateway=fe80::1 PreferredSource=2001:1234:1::abc1 == This interface works fine. But other interfaces configured by /etc/network/interfaces or the manually created interface TEST loose there ipv4 and ipv6 addresses. Please note, that I did not create a *.link entry for TEST on any of the machines. If I later restart these interfaces (with ifdown + ifup for /etc/network/interfaces, systemctl restart test-network-device.service for TEST) they keep their addresses. > > Version 231-6 is built with iptables support, so that may be causing > an interaction that was not visible before. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#837759: network configuration stops working reliably
Package: systemd Version: 231-6 Severity: grave Starting with version 231-6 the configuration of network interfaces stops working reliably when rebooting a system. Downgrading to 231-5 fixes the problem. Symptoms: If a network interface is configured using /etc/network/interfaces it seems that systemd now sometimes removes the configured ip4 and/or ipv6 addresses in the boot process. It also seems to remove routes of network interfaces configured manually or with /etc/network/interfaces if the link state changes. This seems not only be the case with interfaces configured via /etc/network/ interfaces but with any interface one creates and assigns ip addresses manually. I tested this with a script: #!/bin/sh if [ "$1" = start ]; then ip link del TEST >/dev/null 2>&1 || true ip link add name TEST type dummy ip -b - <<"EOF" link set TEST up addr add 10.10.10.10/32 dev TEST nodad addr add 2a01:1:1:1::1/128 dev TEST nodad addr add 2a01:1:1:1::2/128 dev TEST nodad addr add 2a01:1:1:1::3/128 dev TEST nodad addr add 2a01:1:1:1::4/128 dev TEST nodad addr add 2a01:1:1:1::5/128 dev TEST nodad EOF ip addr ls TEST sleep 2 elif [ "$1" = stop ]; then ip addr flush dev TEST ip link del TEST fi which I start with as a systemd oneshot service with Before=systemd-networkd.service I can see in the journal that TEST has all adresses assigned but with 231-6 it looses them again (probably when systemd-networkd.service starts). With 231-5 or earlier this in not the case. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#825520: plasma-desktop: fonts in kde application launcher have wrong size
Same problem here. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#815173: kernel-image-4.4.0-1-amd64 does not boot on my Thinkpad X240
Package: linux-image-4.4.0-1-amd64 Version: 4.4.2-1 Severity: serious Hello, This kernel does not boot on my Thinkpad X240. grub loads the kernel and the initrd. Then die computer hangs. There is no additional output. I must switch the computer with the powerbutton. linux-image-4.4.0-trunk-amd64 works fine. Regards -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#807445: kopete crashes with kde4libs 4:4.14.14-1
On Tue, 08 Dec 2015 23:40:19 +0100 Wolfgang Walter <wolfgang.wal...@stwm.de> wrote: > Package: src:kde4libs > Version: 4:4.14.14-1 > Severity: normal > > kopete chrashes when one closes a chat window or the settings dialog. > Downgrading kde4libs to 4:4.14.13-1 fixes the issue. > > This is probably upstream > > https://bugs.kde.org/show_bug.cgi?id=355275 > > According to Alex Merry a fix would be to revert commit 4f7ea2f77 > > https://bugs.kde.org/show_bug.cgi?id=355275#c25 > KDE has reverted it and this will be in 4.14.16: http://commits.kde.org/kdelibs/a02df05e4bd083f98147c86f88da2f818fc6c9f4 Would it be possible to cherry-pick that for debian's 4:4.14.14? Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#807445: kopete crashes with kde4libs 4:4.14.14-1
Package: src:kde4libs Version: 4:4.14.14-1 Severity: normal kopete chrashes when one closes a chat window or the settings dialog. Downgrading kde4libs to 4:4.14.13-1 fixes the issue. This is probably upstream https://bugs.kde.org/show_bug.cgi?id=355275 According to Alex Merry a fix would be to revert commit 4f7ea2f77 https://bugs.kde.org/show_bug.cgi?id=355275#c25 Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#803319: chromium: GPU accelerated video decode failure
On Sat, 05 Dec 2015 15:07:42 +0100 Paride Legovini <p...@ninthfloor.org> wrote: > Package: chromium > Version: 47.0.2526.73-1 > Followup-For: Bug #803319 > > Duplicate of #804901, I already reported this issue while chromium 47 > was still in experimental, but unfortunately the report was ignored. > The PDF attached to that bug shows the broken chrome://gpu. > > Regards, > > Paride > > Same problem here: no gpu acceleration. I can confirm that your suspicion that Enable accelerated video decoding (closes: #793815). is the culprit is correct. I built chromium without system/vaapi.patch and hardware acceleration works again. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#799377: Apparently it is a config file migration problem
On Thu, 24 Sep 2015 09:14:37 +0200 Eric Valette <eric.vale...@free.fr> wrote: > I had other things that were wrong in my desktop behavior (mounting USB > key , mounting it did stop launching dolphin, clock applet in the panel > tray sometimes stopped at a given time, ..., so I decided to take the > risk of removing (moving) the .config directory and the .kde directory > and relogged. > > This Problem disappeared as well as a few others. So this probably is a > "config files" migration problem. While people installing new system may > be unaffected, people migrating may be. > dolphin 4:15.08.1-1 crashes here as soon as I enable the information panel. If I enable thumnails it crashes as soon as it had to show one. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#798041: chromium has an extension "Google Now" which cannot be disabled
Package: chromium Version: 45.0.2454.85-1~deb8u1 Severity: important chromium now has an extension "Google Now" which cannot be disabled. This extension has far reaching rights. One should be able to disable it and probably it should be disabled by default. Regards, Wolfgang
Bug#762755: bind 9.9.5-4.1: assertion failure
Package: bind9 Version: 1:9.9.5.dfsg-4.1 Severity: important After upgrading from 1:9.9.5.dfsg-4 bind9 fails to start. It logs after loading the zones: Sep 24 23:44:19 name named[10932]: mem.c:1321: REQUIRE(ptr != ((void *)0)) failed, back trace Sep 24 23:44:19 name named[10932]: #0 0x7f74d0b4922d in ?? Sep 24 23:44:19 name named[10932]: #1 0x7f74ced367ba in ?? Sep 24 23:44:19 name named[10932]: #2 0x7f74ced4702c in ?? Sep 24 23:44:19 name named[10932]: #3 0x7f74d03f8694 in ?? Sep 24 23:44:19 name named[10932]: #4 0x7f74d03a416a in ?? Sep 24 23:44:19 name named[10932]: #5 0x7f74d038bc29 in ?? Sep 24 23:44:19 name named[10932]: #6 0x7f74d038bd99 in ?? Sep 24 23:44:19 name named[10932]: #7 0x7f74d03ff7fd in ?? Sep 24 23:44:19 name named[10932]: #8 0x7f74d040dbf0 in ?? Sep 24 23:44:19 name named[10932]: #9 0x7f74ced57eeb in ?? Sep 24 23:44:19 name named[10932]: #10 0x7f74ce7090a4 in ?? Sep 24 23:44:19 name named[10932]: #11 0x7f74ce0d9c2d in ?? Sep 24 23:44:19 name named[10932]: exiting (due to assertion failure) Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741561: No longer ship cacert certificates (and valicert)
The sudden removal of cacerts.org is questionable. E.g. jabber.ccc.org is suddenly untrusted. Kopete detects that but gives you only 2 possibilities: cancel connection or continue (and that without showing the fingerprint or any more details). Of course this is also a problem of kopete. But it is nevertheless bad to suprise people. Especially as people have no secure way to actually check the fingerprint. And why valicert's certificates have been removed though they are still in iceweasel? If I installed ca-certificates with Ask and enabled/disabled certificates by hand it is surprising if a certificate disappears. Mabye this ca-certifcate should change how it works: * deliver cacert and other certificates * but give every certifcate two independend flags: * trusted by maintainer / not trusted by maintainer * use maintainer's recommendation / enabled by administrator / disabled by administrator A certificate is only removed if it is compromised. But the maintainers trust may be changed. New CA certificates will be trusted and installed gets New CA certificates follow the maintainers recommendation If one selects ask one can set the local policy for the cert: use maintainer's recommendation which means that it may be enabled oder disabled dat any time depending on the recommendation of the maintainer. Or the administrator explicitly sets a local policy. Regards, P.S.: Maybe this can be implemented even simpler by having two packets which basically work as ca-certifcates now: ca-certificates and ca-certificates-not- really-trusted-by-maintainer -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741561: No longer ship cacert certificates (and valicert)
On Friday 14 March 2014 13:51:18 Michael Shuler wrote: Thanks for including your thoughts. On 03/14/2014 01:25 PM, Wolfgang Walter wrote: And why valicert's certificates have been removed though they are still in iceweasel? Valicert as well as several other 1024-bit CA certificates were removed from Mozilla. https://bugzilla.mozilla.org/show_bug.cgi?id=881553 https://bugzilla.mozilla.org/show_bug.cgi?id=936304 Thanks for this info. *.wp.com has a certificate (indirectly) rootet in one of those valicert-certificates. Blogs hosted on wordpress.com seem to make https-requests to e.g. s0.wp.com and akregator started to complain. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729713: libcups2: fails to fetch ppd of ipp:// device
On Sunday 05 January 2014 13:47:41 Till Kamppeter wrote: On 01/05/2014 01:36 PM, Wolfgang Walter wrote: On Sunday 05 January 2014 13:12:31 Till Kamppeter wrote: On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote: Control: tags -1 +moreinfo Hi Lionel and Wolfgang, hi Till, thanks for your detailed bugreports and proposed patch. Le samedi, 16 novembre 2013, 05.34:09 Lionel Elie Mamane a écrit : Let FOO be a printer configured in CUPS with an ipp://foo.localdomain.tld/something device uri. Mine is a Konica Minolto C353. All cups clients fail to show printing options. lpoptions -d FOO -l says: lpoptions: Unable to get PPD file for FOO: Not Found A wireshark shows a request for http://device_ip:631/ipp.ppd, to which the printer replies by a 404. The attached patch disables that undesirable behaviour, which is new in 1.6 (did not happen in 1.5). Your proposed patch is functionally equivalent to disabling the get-ppd- file-for-statically-configured-ipp-shared-queues.patch , which was introduced in 1.6.1-1 as a backport from upstream's fix for http://cups.org/str.php?L4178 Till, as you wrote this patch, what do you think about this? Apparently, http://cups.org/str.php?L4159 was related to this problem and got solved differently in 1.6.2, and now cups/util.c appears to be redundant around this codeblock. Till, can we remove this patch on all versions 1.6.2 ? Important is to check whether if you create a raw IPP queue pointing to a CUPS queue on a remote server that you get access to the options on the client (means that the client loads the PPD from the server). Please test this. You can test by creating an arbitrary print queue with PPD on one machine (the server) and sharing it. On another machine (the client) you either create a raw ipp: or ipps: queue pointing to the queue on the server or you run cups-browsed (which creates such a queue automatically). If you print out of a GUI app on the client using the ipp/ipps queue pointing to the CUPS server you should see the PPD options in the print dialog. You should also run lpoptions -p printer -l on the client and should see the options if printer is an ipp/ipps queue pointing to the server and no error message if printer is pointing to a native IPP printer. Till We do not have a cups-server running on the client. Our configuration is: client: only /etc/cups/client.conf with ServerName cups.localdomain.tld. On the print server cups.localdomain.tld. we have a lot of printers in printers.conf like that Printer Mehltau AuthInfoRequired none Info Mehltau Location Rosenstraße MakeModel MyFavoritePostscripPrinterModel DeviceURI ipp://mehltau.drucker.localdomain.tld/ipp State Idle StateTime 1387541234 Type 8425548 Filter application/vnd.cups-raw 0 - Filter application/vnd.cups-command 0 commandtops Filter application/vnd.cups-postscript 0 - Accepting Yes Shared Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 OpPolicy default ErrorPolicy abort-job /Printer We do not wan't to mehltau to be a raw-printer as the printer server should e.g. handle pdfs etc. This setting breaks with cups 1.6. as now the client contacts cups.localdomain.tld but then tries to get the ppd from mehltau.drucker.localdomain.tld instead from cups.localdomain.tld But mehltau.drucker.localdomain.tld is a ipp postscript printer (e.g. from HP or any other vendor) and does not provide ppds (and in our case the client is not even allowed to communicate with Mehltau directly). Regards, My patch did httpSeparateURI(HTTP_URI_CODING_ALL, device_uri, scheme, sizeof(scheme), username,sizeof(username), host, hostsize, port, resource, resourcesize); whereas the final fix does httpSeparateURI(HTTP_URI_CODING_ALL, _httpResolveURI(device_uri, uri, sizeof(uri), _HTTP_RESOLVE_DEFAULT, NULL,NULL), scheme, sizeof(scheme), username,sizeof(username), host, hostsize, port, resource, resourcesize); Can it be that the _httpResolveURI() causes some problem here? Till No, this makes no difference. The problem is using device_uri. Having a device-uri starting with ipp:// does not ensure that the printer is another cups-server which you can ask for a ppd. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729713: libcups2: fails to fetch ppd of ipp:// device
On Sunday 05 January 2014 13:12:31 Till Kamppeter wrote: On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote: Control: tags -1 +moreinfo Hi Lionel and Wolfgang, hi Till, thanks for your detailed bugreports and proposed patch. Le samedi, 16 novembre 2013, 05.34:09 Lionel Elie Mamane a écrit : Let FOO be a printer configured in CUPS with an ipp://foo.localdomain.tld/something device uri. Mine is a Konica Minolto C353. All cups clients fail to show printing options. lpoptions -d FOO -l says: lpoptions: Unable to get PPD file for FOO: Not Found A wireshark shows a request for http://device_ip:631/ipp.ppd, to which the printer replies by a 404. The attached patch disables that undesirable behaviour, which is new in 1.6 (did not happen in 1.5). Your proposed patch is functionally equivalent to disabling the get-ppd- file-for-statically-configured-ipp-shared-queues.patch , which was introduced in 1.6.1-1 as a backport from upstream's fix for http://cups.org/str.php?L4178 Till, as you wrote this patch, what do you think about this? Apparently, http://cups.org/str.php?L4159 was related to this problem and got solved differently in 1.6.2, and now cups/util.c appears to be redundant around this codeblock. Till, can we remove this patch on all versions 1.6.2 ? Important is to check whether if you create a raw IPP queue pointing to a CUPS queue on a remote server that you get access to the options on the client (means that the client loads the PPD from the server). Please test this. You can test by creating an arbitrary print queue with PPD on one machine (the server) and sharing it. On another machine (the client) you either create a raw ipp: or ipps: queue pointing to the queue on the server or you run cups-browsed (which creates such a queue automatically). If you print out of a GUI app on the client using the ipp/ipps queue pointing to the CUPS server you should see the PPD options in the print dialog. You should also run lpoptions -p printer -l on the client and should see the options if printer is an ipp/ipps queue pointing to the server and no error message if printer is pointing to a native IPP printer. Till We do not have a cups-server running on the client. Our configuration is: client: only /etc/cups/client.conf with ServerName cups.localdomain.tld. On the print server cups.localdomain.tld. we have a lot of printers in printers.conf like that Printer Mehltau AuthInfoRequired none Info Mehltau Location Rosenstraße MakeModel MyFavoritePostscripPrinterModel DeviceURI ipp://mehltau.drucker.localdomain.tld/ipp State Idle StateTime 1387541234 Type 8425548 Filter application/vnd.cups-raw 0 - Filter application/vnd.cups-command 0 commandtops Filter application/vnd.cups-postscript 0 - Accepting Yes Shared Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 OpPolicy default ErrorPolicy abort-job /Printer We do not wan't to mehltau to be a raw-printer as the printer server should e.g. handle pdfs etc. This setting breaks with cups 1.6. as now the client contacts cups.localdomain.tld but then tries to get the ppd from mehltau.drucker.localdomain.tld instead from cups.localdomain.tld But mehltau.drucker.localdomain.tld is a ipp postscript printer (e.g. from HP or any other vendor) and does not provide ppds (and in our case the client is not even allowed to communicate with Mehltau directly). Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729713: libcups2: fails to fetch ppd of ipp:// device
We see the same problem here: we have a cups printer server say cups.localdomain.tld with a lot ipp- postscript-printers. The clients are configured to use the cups-server. Since 1.6 the client tries to get the ppd from the printer instead from the server. A workaround is use a device-uri starting with http:// instead of ipp:// ipp://bla.localdomain.tld:631/ipp = http://bla.localdomain.tld:631/ipp We modified libcups in the same way as Lionel. I don't know why this has been changed from 1.5 to 1.6 but it seems buggy. Most ipp-printers don't provide a PPD. And even if the do there is no guarantie the client is allowed to communicate directly with the printer. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728823: Fails to start: Running without the SUID sandbox!
same problem here. A workaround is to make a symlink ln -s chromium-sandbox /usr/lib/chromium/chrome-sandbox -- Wolfgang Walter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722604: Info received (Bug#722604: Info received (udev: system won't mount partitions at boot, nor create network interface
Hello,
CONFIG_DEVTMPFS_MOUNT=y
does not fix our problems here, we need the changes to /etc/init.d/udev I
mailed earlier.
The reason is that we start a complete debian system as initramfs. In this
case CONFIG_DEVTMPFS_MOUNT=y does nothing. As there is no devtmpfs mounted the
bugs in /etc/init.d/udev are triggered: it tries to mount a tmpfs (instead of
devtmpfs) and even this fails because it calls mount erroneously.
Probably debian systems running custom kernels built without
CONFIG_DEVTMPFS_MOUNT=y will start, too, if /etc/init.d/udev is fixed.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
--- udev.orig 2013-09-16 13:41:20.750160567 +0200
+++ udev 2013-09-15 02:48:03.699703206 +0200
@@ -22,11 +22,11 @@
# mount a tmpfs over /dev, if somebody did not already do it
mount_tmpfs() {
if grep -E -q ^[^[:space:]]+ /dev (dev)?tmpfs /proc/mounts; then
-mount -n -o remount,${dev_mount_options} -t tmpfs tmpfs /dev
+mount -n -o remount,${dev_mount_options} -t devtmpfs devtmpfs /dev
return
fi
- if ! mount -n -o $dev_mount_options -t tmpfs tmpfs /dev; then
+ if ! mount -n -o $dev_mount_options -t devtmpfs devtmpfs /dev; then
log_failure_msg udev requires tmpfs support, not started
log_end_msg 1
fi
@@ -144,6 +144,11 @@
# new /dev has been mounted and udevadm trigger has been run there will be
# no /dev/null. This also means that you cannot use the shell command.
+dev_mount_options='mode=0755'
+if [ $tmpfs_size ]; then
+ dev_mount_options=size=${tmpfs_size},${dev_mount_options}
+fi
+
case $1 in
start)
if init_is_upstart 2/dev/null; then
Bug#722604: udev: system won't mount partitions at boot, nor create network interfaces
/etc/init.d/udev has a bug which breaks it here:
$dev_mount_options is empty (not set at all) which makes
mount -n -o $dev_mount_options -t tmpfs tmpfs /dev
fail in mount_tmpfs().
I think
dev_mount_options='mode=0755'
if [ $tmpfs_size ]; then
dev_mount_options=size=${tmpfs_size},${dev_mount_options}
fi
is missing.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722604: Info received (udev: system won't mount partitions at boot, nor create network interfaces)
I had to make another change to /etc/init.d/udev:
in mount_tmpfs() I had to change tmpfs to devtmpfs:
mount_tmpfs() {
if grep -E -q ^[^[:space:]]+ /dev (dev)?tmpfs /proc/mounts; then
mount -n -o remount,${dev_mount_options} -t devtmpfs devtmpfs /dev
return
fi
if ! mount -n -o $dev_mount_options -t devtmpfs devtmpfs /dev; then
log_failure_msg udev requires tmpfs support, not started
log_end_msg 1
fi
return 0
}
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704567: CVE-2013-0131: NVIDIA UNIX GPU Driver ARGB Cursor Buffer Overflow in NoScanout Mode.
Package: nvidia-graphics-drivers Version: 313.26-1 Version: 304.84-1 Version: 295.59-1~bpo60+2 Version: 195.36.31-6squeeze2 Severity: important https://devtalk.nvidia.com/default/topic/533434/linux/current-graphics-driver-releases/ NVIDIA released new versions with a bug fix. Regards, -- Wolfgang Walter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704174: CVE-2013-2266
Package: src:bind9 Version: 1:9.8.4.dfsg.P1-6 Severity: grave http://cxsecurity.com/issue/WLB-2013030255 https://kb.isc.org/article/AA-00879 This bug also affects all programs which use libdns. Regards, -- Wolfgang Walter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682218: charon: leftfirewall=yes broken
Package: strongswan-ikev2 Version: 4.6.4-5 Severity: serious In 4.6.4-5 charon runs as a non-privileged user instead of root. This breaks * leftfirewall=yes Breaking (silently) leftfirewall is a security problem. The problem is that iptables does not work as non-root even if it is called with the necessary capabilities. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675498: akregator: akrekator crashes on quit
This seems to be fixed in upstream now: http://commits.kde.org/kdepim/3497e5afe51490191825c7b7d475a5fc0702988d Would be very glad if this makes it as soon as possible into sid as akregator is rather unusable now: Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660420: Some Postscript printer drivers (Kyocera, Brother, maybe others) do not work anymore
cups-filters (1.0.5-1) fixes the problem for me. Probably this was bug: LP #951627 https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/951627 And probably this fix would also help here: http://cups.org/str.php?L4008+Qversion:1.5 Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660420: Some Postscript printer drivers (Kyocera, Brother, maybe others) do not work anymore
On Tuesday 06 March 2012, you wrote: Hi Wolfgang, Am 06.03.2012 01:28, schrieb Wolfgang Walter: I can also confirm that printing to a kyocera FS-1300D (as a postscript- printer) does not work any more. It does not print and hangs instead. This seems to be due to the postscript file generated from the PDF by ghostscript (called by the pdftops cups filter in my case). To test I tried to print my .bashrc: lp .bashrc 1. I redirected the final output a file and then sent to the printer by hand: printer does not print and hangs. 2. I modified cupsfilters.convs such that I get the PDF. I then used pdf2ps to generate the postscript file. Sent it to the printer: printer does not print and hangs. 3. I used pdftops from poppler-utils to generate the postscript file: Sent it to the printer and it works. 4. I used ps2ps on this postscript file: the generated one does not work and printer hangs. I called gs with -sDEVICE=pswrite to genrate a postscript file from the PDF: that one worked. The only way I may print using cups with a kyocera FS-1300D as postscript printer is by printing to a file as PDF and then using acroread to actually print it. Regards I tried to follow your explanations but somehow I did not succeed. :) I modified /etc/cups/printers.conf such that it prints into a file (DeviceURI file:///tmp/blub). This file I sent do the printer by hand (i.e. to /dev/usb/lp0). In Step 2) I modified /usr/share/cups/mime/cupsfilters.convs such that cups does not do the last step (generating a postscript file from the PDF by pdftops filter). So /tmp/blub is now a PDF and I can see if pdf2ps is the problem: pdf2ps /tmp/blub bla.ps cat bla.ps /dev/usb/lp0 As I said: does not work. But /usr/bin/pdftops /tmp/blub bla.ps cat bla.ps /dev/usb/lp0 works (/usr/bin/pdftops is from packet poppler-utils). Anyway, did you try to set the printer to use a generic Postscript PPD as outlined here in this report before? Yes. I did this with Kyocera's PPD and with the generic postscript. No change. If I send the postscript which is generated by KDE or chromium or firefox or a2ps ... directly to the printer it works (either as above or via a raw- printer in cups). Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660420: Some Postscript printer drivers (Kyocera, Brother, maybe others) do not work anymore
I can also confirm that printing to a kyocera FS-1300D (as a postscript- printer) does not work any more. It does not print and hangs instead. This seems to be due to the postscript file generated from the PDF by ghostscript (called by the pdftops cups filter in my case). To test I tried to print my .bashrc: lp .bashrc 1. I redirected the final output a file and then sent to the printer by hand: printer does not print and hangs. 2. I modified cupsfilters.convs such that I get the PDF. I then used pdf2ps to generate the postscript file. Sent it to the printer: printer does not print and hangs. 3. I used pdftops from poppler-utils to generate the postscript file: Sent it to the printer and it works. 4. I used ps2ps on this postscript file: the generated one does not work and printer hangs. I called gs with -sDEVICE=pswrite to genrate a postscript file from the PDF: that one worked. The only way I may print using cups with a kyocera FS-1300D as postscript printer is by printing to a file as PDF and then using acroread to actually print it. Regards -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639300: odbc-postgresql: can't be installed together with KDE any more
Package: odbc-postgresql Version: 1:09.00.0310-2 Severity: important odbc-postgresql can't be installed if libiodbc2 is installed. As most of KDE depends on libsoprano4 which again depends on libiodbc2 via soprano-daemon this makes odbc-postgresql unusable together with KDE. Please remove libiodbc2 from the Breaks: -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.3-ei+6.3 (SMP w/6 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages odbc-postgresql depends on: ii libc6 2.13-18Embedded GNU C Library: Shared lib ii libltdl7 2.4-4 A system independent dlopen wrappe ii libpq59.1~rc1-2 PostgreSQL C client library ii libssl1.0.0 1.0.0d-3 SSL shared libraries ii multiarch-support 2.13-18Transitional package to ensure mul ii odbcinst1debian2 2.2.14p2-3 Support library for accessing odbc odbc-postgresql recommends no packages. Versions of packages odbc-postgresql suggests: ii unixodbc-bin 2.3.0-1Graphical tools for ODBC management Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625877: xserver-xorg-core 1.10.2: resizing konsole hangs xserver
On Tuesday 31 May 2011, Andreas Beckmann wrote: On 2011-05-31 10:18, Stefano Callegari wrote: Hi I have tried last (yesterday) update on Sid. That would be 270.41.19-1. Something better :) Before, the system hangs after first maximize. Today, I do 2 or 3 loop maximize, normal and after the monitor has filled by artifacts like a fog of dots, but the system is still fully functional. Anyway, I don't think this can be fixed on the Debian side. Please check the NVIDIA forum whether a similar bug was reported there already. Then provide additional information there or create a new thread if you couldn't find anything. Post an link to the forum here. NVIDIA Bug reporting instructions: http://www.nvnews.net/vbulletin/showthread.php?t=46678 There are several threads on this, for example http://www.nvnews.net/vbulletin/showthread.php?t=161308 There is an ubuntu thread: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/760632 where you can find #53 This is a copy of the latest response I have received from nVidia's customer care, following yet another a fairly strongly worded email from me with regard to nVidia's total lack of activity in this regard:- Hello, I escalated this problem to the Linux Engineering Manager. An Engineer has been assigned to work on this at high priority. We are targeting the fix for the upcoming 275.xx driver which is currently planned to ship in early June 2011. And there is an arch linux thread: https://bbs.archlinux.org/viewtopic.php?id=116544 and a arch-linux bug-report https://bugs.archlinux.org/task/23381 So indeed debian cannot do much about it (unless it is the xserver's fault). To have newest version of nvidia driver in experimental would help so one can easily test it. As the driver works with 1.9.5 I can wait :-). Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625877: xserver-xorg-core 1.10.2: resizing konsole hangs xserver
18:06:15 ei kernel: [26545.025006] [8113995a] ? sys_ioctl+0x4a/0x80 May 30 18:06:15 ei kernel: [26545.025006] [8108b7f5] ? sys_rt_sigprocmask+0x75/0x110 May 30 18:06:15 ei kernel: [26545.025006] [81819f52] ? system_call_fastpath+0x16/0x1b May 30 18:06:15 ei kernel: [26545.025006] Code: 00 00 be 1e 00 00 00 ff 90 b8 0b 00 00 49 89 c4 44 89 e8 49 8b 94 24 c0 01 00 00 48 c1 e0 04 48 8b 1c 10 48 85 db 74 14 48 89 df May 30 18:06:15 ei kernel: [26545.025006] RIP [a032c9f0] _nv012685rm+0x3b/0x7e [nvidia] May 30 18:06:15 ei kernel: [26545.025006] RSP 880220583cb8 May 30 18:06:15 ei kernel: [26545.025535] ---[ end trace 5cfbfaf2d2e4ff73 ]--- In Xorg.0.log I see this: [ 26429.342] (WW) NVIDIA(0): The NVIDIA X driver has encountered too many errors. Falling [ 26429.342] (WW) NVIDIA(0): back to write-back cached memory. [ 26528.004] (EE) NVIDIA(0): Failed to allocate 2D engine [ 26528.004] (EE) NVIDIA(0): *** Aborting *** [ 26528.004] (EE) NVIDIA(0): Failed to allocate 2D objects [ 26528.004] (EE) NVIDIA(0): *** Aborting *** [ 26528.004] (EE) NVIDIA(0): Error recovery failed. [ 26528.004] (EE) NVIDIA(0): *** Aborting *** The X server then hangs in D state. It seems to me that the kernel oops comes only after nvidias xserver-modul gave up: * nvidia kernel module logs NVRM: Xid (:01:00): 13, ... everytime I resize a konsole. * then X-server logs * the nvidia kernel modul crashes I'm back to xserver-xorg-core 2:1.9.5-1 which works flawlessly. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625877: xserver-xorg-core 1.10.2: resizing konsole hangs xserver
On Sunday 29 May 2011, Andreas Beckmann wrote: Two new driver versions are available: * 270.41.19-1 (release) in unstable Tried now serveral times to see if I always get a kernel oops: No, usually not. Usually the kernel only logs NVRM: Xid (:01:00): 13, One time I got NVRM: os_schedule: Attempted to yield the CPU while in atomic or interrupt context Most of the time X is in R state. Often nothing gets logged to Xorg.0.log. Once I got [ 361.115] (EE) NVIDIA(0): Failed to allocate 2D engine [ 361.115] (EE) NVIDIA(0): *** Aborting *** [ 361.115] (EE) NVIDIA(0): Failed to allocate 2D objects [ 361.115] (EE) NVIDIA(0): *** Aborting *** [ 361.115] (EE) NVIDIA(0): Error recovery failed. [ 361.115] (EE) NVIDIA(0): *** Aborting *** [ 364.116] (WW) NVIDIA(0): WAIT (2, 6, 0x8000, 0x, 0x02cc) [ 371.116] (WW) NVIDIA(0): WAIT (1, 6, 0x8000, 0x, 0x02cc) [ 391.300] (WW) NVIDIA(0): WAIT (2, 6, 0x8000, 0x, 0x2e1c) [ 398.300] (WW) NVIDIA(0): WAIT (1, 6, 0x8000, 0x, 0x2e1c) [ 422.493] (WW) NVIDIA(0): WAIT (2, 6, 0x8000, 0x, 0x30e8) [ 429.493] (WW) NVIDIA(0): WAIT (1, 6, 0x8000, 0x, 0x30e8) [ 432.494] (WW) NVIDIA(0): WAIT (2, 6, 0x8000, 0x, 0x500c) [ 439.494] (WW) NVIDIA(0): WAIT (1, 6, 0x8000, 0x, 0x500c) [ 442.495] (WW) NVIDIA(0): WAIT (2, 6, 0x8000, 0x, 0x8af4) [ 449.495] (WW) NVIDIA(0): WAIT (1, 6, 0x8000, 0x, 0x8af4) [ 512.118] [mi] EQ overflowing. The server is probably stuck in an infinite loop. [ 512.118] Backtrace: [ 512.119] 0: /usr/bin/X (xorg_backtrace+0x26) [0x4a3866] [ 512.119] 1: /usr/bin/X (mieqEnqueue+0x201) [0x4a2cb1] [ 512.119] 2: /usr/bin/X (xf86PostMotionEventM+0xa3) [0x4804e3] [ 512.119] 3: /usr/bin/X (xf86PostMotionEventP+0x37) [0x4805d7] [ 512.119] 4: /usr/lib/xorg/modules/input/evdev_drv.so (0x7fb54919+0x49fe) [0x7fb5491949fe] [ 512.119] 5: /usr/bin/X (0x40+0x6dd17) [0x46dd17] [ 512.119] 6: /usr/bin/X (0x40+0x11c61e) [0x51c61e] [ 512.119] 7: /lib/libpthread.so.0 (0x7fb54f94c000+0xf020) [0x7fb54f95b020] [ 512.119] 8: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fb549c44000+0x768dd) [0x7fb549cba8dd] [ 512.119] 9: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fb549c44000+0x78520) [0x7fb549cbc520] [ 512.119] 10: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fb549c44000+0xde7a9) [0x7fb549d227a9] [ 512.119] 11: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fb549c44000+0x469070) [0x7fb54a0ad070] [ 512.119] 12: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fb549c44000+0x4676e5) [0x7fb54a0ab6e5] [ 512.119] 13: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fb549c44000+0x4692ad) [0x7fb54a0ad2ad] [ 512.119] 14: /usr/bin/X (0x40+0xdf9dc) [0x4df9dc] [ 512.119] 15: /usr/bin/X (0x40+0x2f9fe) [0x42f9fe] [ 512.119] 16: /usr/bin/X (0x40+0x32d09) [0x432d09] [ 512.119] 17: /usr/bin/X (0x40+0x26fae) [0x426fae] [ 512.120] 18: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fb54e685ead] [ 512.120] 19: /usr/bin/X (0x40+0x2729d) [0x42729d] Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628483: kde-plasma-desktop: plasma crashes sometimes when stopping kopete or amarok
Package: kde-plasma-desktop Version: 5:68 Severity: important -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-ei+6.3 (SMP w/6 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kde-plasma-desktop depends on: ii kdebase-apps 4:4.6.3-1 base applications from the officia ii kdebase-runtime 4:4.6.3-1 runtime components from the offici ii kdebase-workspace4:4.6.3-1 KDE Plasma Workspace components ii plasma-desktop 4:4.6.3-1 KDE Plasma workspace for desktop a ii udisks 1.0.2-4 storage media interface ii upower 0.9.11-1+b1 abstraction for power management Versions of packages kde-plasma-desktop recommends: ii kdm 4:4.6.3-1 KDE Display Manager for X11 ii xserver-xorg 1:7.6+6the X.Org X server Versions of packages kde-plasma-desktop suggests: pn kde-l10n none (no description available) -- no debconf information plasma crashes sometimes when I stop amarok or kopete (which crashes itself, but probably for other reasons). This seems to be upstream bug https://bugs.kde.org/show_bug.cgi?id=258706 and there is a fix: https://bugs.kde.org/show_bug.cgi?id=258706#c92 https://bugs.kde.org/show_bug.cgi?id=258706#c93 Maybe worth to backport? Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625877: xserver-xorg-core 1.10.2: resizing konsole hangs xserver
On Friday 06 May 2011, Cyril Brulebois wrote: reassign 625877 nvidia-glx thanks Hi, Wolfgang Walter wolfgang.wal...@stwm.de (06/05/2011): Package: xserver-xorg-core Version: 2:1.10.1-2 Severity: grave After upgrading from xserver-xorg-core 2:1.9.5-1 to version 2:1.10.1-2 the xserver hangs when I resize konsole (kde sid). Downgrading to 2:1.9.5-1 fixes the problem. I found similar reports for other distros (Ubuntu, Fedora, ArchLinux), i.e. https://bbs.archlinux.org/viewtopic.php?id=116544p=3 Most people report that they are using binary drivers from nvidia (as I do) but some report the those problems for other drivers. reassigning there for now. Your “report” is very incomplete. Please use reportbug next time. And follow up with details: http://pkg-xorg.alioth.debian.org/howto/report-bugs.html Disabling composite fixes the problem for me, too. Regards, -- Wolfgang Walter Mraw, KiBi. Here are some missing infos: -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38.5-ei+6.3 (SMP w/6 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xorg depends on: ii konsole [x-terminal-emulator] 4:4.4.5-3 X terminal emulator ii libgl1-mesa-dri 7.10.2-2 free implementation of the OpenGL ii libgl1-mesa-glx [libgl1] 7.10.2-2 free implementation of the OpenGL ii libglu1-mesa 7.10.2-2 The OpenGL utility library (GLU) ii x11-apps 7.6+4 X applications ii x11-session-utils 7.6+1 X session utilities ii x11-utils 7.6+2 X11 utilities ii x11-xfs-utils 7.6+1 X font server utilities ii x11-xkb-utils 7.6+2 X11 XKB utilities ii x11-xserver-utils 7.6+2 X server utilities ii xauth 1:1.0.5-1 X authentication utility ii xfonts-100dpi 1:1.0.3100 dpi fonts for X ii xfonts-75dpi 1:1.0.375 dpi fonts for X ii xfonts-base 1:1.0.3standard fonts for X ii xfonts-scalable 1:1.0.3-1 scalable fonts for X ii xfonts-utils 1:7.6~1X Window System font utility progr ii xinit 1.3.0-1X server initialisation tool ii xkb-data 2.1-2 X Keyboard Extension (XKB) configu pn xorg-docs-corenone (no description available) ii xserver-xorg 1:7.6+6the X.Org X server ii xterm [x-terminal-emulator] 269-1 X terminal emulator xorg recommends no packages. Versions of packages xorg suggests: pn xorg-docs none (no description available) Versions of packages xserver-xorg depends on: ii libc62.13-2 Embedded GNU C Library: Shared lib ii nvidia-glx [xorg-driver-vide 270.41.06-1 NVIDIA binary Xorg driver ii x11-xkb-utils7.6+2 X11 XKB utilities ii xkb-data 2.1-2 X Keyboard Extension (XKB) configu ii xserver-xorg-core2:1.9.5-1 Xorg X server - core server ii xserver-xorg-input-evdev [xo 1:2.6.0-2 X.Org X server -- evdev input driv ii xserver-xorg-video-dummy [xo 1:0.3.4-2 X.Org X server -- dummy display dr Versions of packages xserver-xorg recommends: ii libgl1-mesa-dri 7.10.2-2 free implementation of the OpenGL The server does not freeze immediately. When resizing a konsole window it shortly shows strange content, then the whole screens gets redrawn and the kernel logs May 4 01:09:26 ei kernel: [61049.249134] NVRM: Xid (:01:00): 13, 0001 5097 15e0 0100 You may resize 2 or 3 times and then the xserver freezes and I can't switch to a VT. But the xserver does not crash. If one moves the mouse it will react after several seconds and then starts moving very slowly in the direction the mouse was moved. Disabling composite probably helps because as a side effect one disables any opengl effects of kwin. I can't say if it is a problem of the nvidia driver or of the xserver. Regards, -- Wolfgang Walter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625877: xserver-xorg-core 1.10.2: resizing konsole hangs xserver
Package: xserver-xorg-core Version: 2:1.10.1-2 Severity: grave After upgrading from xserver-xorg-core 2:1.9.5-1 to version 2:1.10.1-2 the xserver hangs when I resize konsole (kde sid). Downgrading to 2:1.9.5-1 fixes the problem. I found similar reports for other distros (Ubuntu, Fedora, ArchLinux), i.e. https://bbs.archlinux.org/viewtopic.php?id=116544p=3 Most people report that they are using binary drivers from nvidia (as I do) but some report the those problems for other drivers. Disabling composite fixes the problem for me, too. Regards, -- Wolfgang Walter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614105: strongswan-ikev2: charon continually respawns
Same here. Would appreciate if this bug was fixed in sid. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587583: closed by Rene Mayrhofer rm...@debian.org (Bug#587583: fixed in strongswan 4.4.1-1)
Hello! Am Dienstag, 17. August 2010 schrieb Debian Bug Tracking System: This is an automatic notification regarding your Bug report which was filed against the strongswan package: #587583: strongswan 4.4.0-2 does not work here: charon seems not to ignore all incoming requests/answers It has been closed by Rene Mayrhofer rm...@debian.org. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Rene Mayrhofer rm...@debian.org by replying to this email. This does not help here. The issue remains. What helps is to change /etc/strongswan.conf. Explicitly forcing charon tu use socket-raw (instead of socket-default) fixes the problem here. I therefor added the line: load = curl ldap aes des sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem openssl fips-prf xcbc hmac agent gmp attr kernel-netlink socket-raw farp stroke updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 dhcp resolve This fixes the issue for 4.4.0-2, too. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587583: 4.4.0-2 does not work here: charon seems not to ignore all incoming
Maybe this is the solution: https://lists.strongswan.org/pipermail/users/2010-August/005192.html https://lists.strongswan.org/pipermail/users/2010-August/005197.html Probably socket-default should be disabled at compile-time as debian enables pluto. Regards -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587583: strongswan 4.4.0-2 does not work here: charon seems not to ignore all incoming requests/answers
Package: strongswan Version: 4.4.0-2 Severity: grave charon seems no ignore all incoming ikev2-request. I downgraded both machines to strongswan 4.3.2-1.3 and all worked again. I further left one with 4.3.2-1.3 and upgraded the other to 4.4.0-2. Whereas 4.3.2-1.3 logs and answer packets sent by 4.4.0-2, the latter neither logs request nor anwers from 4.3.2-1.0. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587282: plugins missing
Package: strongswan Version: 4.4.0-1 Severity: grave strongswan floods syslog with the following message charon: 08[NET] no socket implementation registered, receiving failed According to the strongswan mailing list: strongswan-4.4.0 requires a charon socket plugin, either socket-default if charon-only is running or socket-raw if both charon an pluto are running. These plugins are missing. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569462: xserver-xorg-input-elographics: FTBFS: ../../src/xf86Elo.c:800: error: too few arguments to function 'InitButtonClassDeviceStruct'
This is due to the new xserver version. Upstream already fixed this: http://cgit.freedesktop.org/xorg/driver/xf86-input-elographics/commit/?id=a18af14b1df5271fbe3100df3fcb3a8811981ddf Please upgrade the debian-package to the newest upstream version, which fixes other problems, too: http://cgit.freedesktop.org/xorg/driver/xf86-input-elographics/commit/?id=ac5366d6e1f26e6ceef3d062ab7df301d623cf54 Rergards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569931: oxygen-ait theme crashes in libjpeg62
Package: kdebase-workspace-kgreet-plugins Version: 4:4.3.4-4 Severity: grave Since I upgraded unstable (today, 15.2.2010) kdms greeter crashes when using the theme /usr/share/kde4/apps/kdm/themes/oxygen-air with a segmentation fault (in libjpeg62 when decompressing). Theme /usr/share/kde4/apps/kdm/themes/oxygen works. I think this has something todo with the upgrade of kdelibs5 and libplasma3 (or liblzma1 to liblzma2)? Here is the dpkg.log: 2010-02-15 01:01:32 startup archives unpack 2010-02-15 01:01:47 upgrade kdelibs-bin 4:4.3.4-1 4:4.3.4-1+b1 2010-02-15 01:01:47 status half-configured kdelibs-bin 4:4.3.4-1 2010-02-15 01:01:47 status unpacked kdelibs-bin 4:4.3.4-1 2010-02-15 01:01:47 status half-installed kdelibs-bin 4:4.3.4-1 2010-02-15 01:01:47 status half-installed kdelibs-bin 4:4.3.4-1 2010-02-15 01:01:47 status unpacked kdelibs-bin 4:4.3.4-1+b1 2010-02-15 01:01:47 status unpacked kdelibs-bin 4:4.3.4-1+b1 2010-02-15 01:01:47 upgrade libpng12-dev 1.2.42-1 1.2.42-2 2010-02-15 01:01:47 status half-configured libpng12-dev 1.2.42-1 2010-02-15 01:01:47 status unpacked libpng12-dev 1.2.42-1 2010-02-15 01:01:47 status half-installed libpng12-dev 1.2.42-1 2010-02-15 01:01:47 status triggers-pending man-db 2.5.6-5 2010-02-15 01:01:47 status half-installed libpng12-dev 1.2.42-1 2010-02-15 01:01:47 status half-installed libpng12-dev 1.2.42-1 2010-02-15 01:01:47 status unpacked libpng12-dev 1.2.42-2 2010-02-15 01:01:47 status unpacked libpng12-dev 1.2.42-2 2010-02-15 01:01:48 upgrade libpng12-0 1.2.42-1 1.2.42-2 2010-02-15 01:01:48 status half-configured libpng12-0 1.2.42-1 2010-02-15 01:01:48 status unpacked libpng12-0 1.2.42-1 2010-02-15 01:01:48 status half-installed libpng12-0 1.2.42-1 2010-02-15 01:01:48 status triggers-pending doc-base 0.9.5 2010-02-15 01:01:48 status half-installed libpng12-0 1.2.42-1 2010-02-15 01:01:48 status half-installed libpng12-0 1.2.42-1 2010-02-15 01:01:48 status unpacked libpng12-0 1.2.42-2 2010-02-15 01:01:48 status unpacked libpng12-0 1.2.42-2 2010-02-15 01:01:48 upgrade kdelibs5 4:4.3.4-1 4:4.3.4-1+b1 2010-02-15 01:01:48 status half-configured kdelibs5 4:4.3.4-1 2010-02-15 01:01:48 status unpacked kdelibs5 4:4.3.4-1 2010-02-15 01:01:48 status half-installed kdelibs5 4:4.3.4-1 2010-02-15 01:01:49 status half-installed kdelibs5 4:4.3.4-1 2010-02-15 01:01:49 status unpacked kdelibs5 4:4.3.4-1+b1 2010-02-15 01:01:49 status unpacked kdelibs5 4:4.3.4-1+b1 2010-02-15 01:01:49 trigproc man-db 2.5.6-5 2.5.6-5 2010-02-15 01:01:49 status half-configured man-db 2.5.6-5 2010-02-15 01:01:50 status installed man-db 2.5.6-5 2010-02-15 01:01:50 trigproc doc-base 0.9.5 0.9.5 2010-02-15 01:01:50
Bug#569931: closed by Andreas Barth a...@not.so.argh.org (Bug#569931: fixed in libjpeg6b 6b-16.1)
Hello, I installed these vesions of libjpeg62 and libjpeg8 and this does NOT fix the issue. It still crashes in jpeg_start_decompress () from /usr/lib/libjpeg.so.62 Not only kdm greeter crashes, konqueror and gwenview crash, too. It must have something to do with the upgrade from kdelibs-bin, kdelibs5 and libplasma3. If I downgraded them to 4:4.3.4-1 and reinstall liblzma1 the issue disappears. Regards, Wolfgang Walter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201002151845.55756.wolfgang.wal...@stusta.mhn.de
Bug#553918: [Pkg-virtualbox-devel] Bug#553918: virtualbox-ose-source: Please, make dkms a recommendation.
Am Donnerstag, 12. November 2009 schrieb Michael Meskes: On Fri, Nov 06, 2009 at 08:06:33PM +0100, Wolfgang Walter wrote: 2) It therefor runs as root. And it even does if /lib/modules/installed kernel/source points to a non privileged build directory which is a security problem. I don't really see where the security problem is here. Would you mind explaining it? Say you built your kernel as user foo on one machine. Say /lib/modules/2.6.31.6/source or /lib/modules/2.6.31.6/build therefor may points to /home/foo/kernels/linux-2.6.31.6 Now you install that kernel on a different machine exposed where user foo exists, too. You now have to trust machine exposed. You must trust f...@exposed that it does not provide a manipulated /home/foo/kernels/linux-2.6.31.6 which will either produce a trojaned kernel module or simply uses errors in dkms, gcc, binutils, ... to gain root access. I think virtualbox should do it like other similar packages which build kernel modules: virtualbox-ose-source for building binary-modules as self-sufficent deb-packages virtualbox-ose-dkms for the dkms approach Sehe batman-adv-source|dkms or openafs-modules-source|dkms Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leiter EDV Leopoldstraße 15 80802 München Tel: +49 89 38196 276 Fax: +49 89 38196 150 Email: wolfgang.wal...@stwm.de http://www.studentenwerk-muenchen.de/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537389: binutils 2.19.51.20090714-1 produces non-bootable kernel
Am Mittwoch, 22. Juli 2009 schrieb Matthias Klose: On 21.07.2009 07:23, Wolfgang Walter wrote: Package: binutils Version: 2.19.51.20090714-1 There were no error messages or anything from the kernel; just the spontaneous reboot or hang. No configuration kernel configuration changes either; the only difference in a working test case and a non-working test case was building with different versions of binutils. There's nothing special about the PC that had the problem booting the kernel. It's an old machine that has never had problems with Linux. I can confirm that. I had to downgrade binutils to build a working 2.6.30.2 (or 2.6.30.1). In LKML other people also tracked down non-booting 2.6.30.x to be caused by the actual binutils package in sid. I can't see this kind of report for current Fedora and Ubuntu, which are both based to a subset of the hjl's binutils patches (the Debian package is pure upstream without these patches applied). As a quick check, please could you recheck with the package found here: http://packages.ubuntu.com/karmic/amd64/binutils/download http://packages.ubuntu.com/karmic/i386/binutils/download I'll try tonight. Maybe this mail from Bastian Blank to 537...@bugs.debian.org has an hint: = On Mon, Jul 20, 2009 at 03:02:36PM -0700, Linus Torvalds wrote: On Mon, 20 Jul 2009, Kiko Piris wrote: Yes, as Marcel Beister pointed, it resulted some binutils bug. Downgrading the package produced a perfectly bootable 2.6.30.2. Ok, so it's been narrowed down to binutils. Good. Okay, I did some work and now got one working and one not working kernel. The setup code it, except the payload size and the version string, identical. Now to vmlinux. First difference (1-vmlinux is the broken, 2-vmlinux is the working version): | 2-vmlinux: file format elf32-i386 | 2-vmlinux | architecture: i386, flags 0x0113: | HAS_RELOC, EXEC_P, HAS_SYMS, D_PAGED vs. | 1-vmlinux: file format elf32-i386 | 1-vmlinux | architecture: i386, flags 0x0013: | HAS_RELOC, EXEC_P, HAS_SYMS The file lost its D_PAGED flag. Next: | 16 .init.rodata 0394 c05057e0 005057e0 004067e0 2**4 | CONTENTS, ALLOC, LOAD, RELOC, DATA | 17 .data.page_aligned 0800 c0506000 00506000 00407000 2**5 | CONTENTS, ALLOC, LOAD, DATA vs. | 16 .init.rodata 0394 c0506000 00506000 00407000 2**4 | CONTENTS, ALLOC, LOAD, RELOC, DATA | 17 .data_nosave 0c6c c0506394 00506394 00407394 2**0 | ALLOC | 18 .data.page_aligned 0800 c0507000 00506394 00407394 2**5 | CONTENTS, ALLOC, LOAD, DATA So suddenly there apears a .data_nosave with some content, but it is marked the same then a bss section and not even properly aligned according to the linker script. The same sections of another working kernel, built with the new binutils: | 18 .init.rodata 03bd c040f4c0 0040f4c0 003104c0 2**2 | CONTENTS, ALLOC, LOAD, RELOC, DATA | 19 .data_nosave 1000 c041 0041 00311000 2**2 | CONTENTS, ALLOC, LOAD, DATA | 20 .data.page_aligned 0800 c0411000 00411000 00312000 2**2 | CONTENTS, ALLOC, LOAD, DATA The .data_nosave section is a real one here. I would say, such holes won't survive the objcopy to create a binary and all code is at the wrong location. Bastian = Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537389: binutils 2.19.51.20090714-1 produces non-bootable kernel
On Wednesday 22 July 2009, Matthias Klose wrote: On 21.07.2009 07:23, Wolfgang Walter wrote: Package: binutils Version: 2.19.51.20090714-1 There were no error messages or anything from the kernel; just the spontaneous reboot or hang. No configuration kernel configuration changes either; the only difference in a working test case and a non-working test case was building with different versions of binutils. There's nothing special about the PC that had the problem booting the kernel. It's an old machine that has never had problems with Linux. I can confirm that. I had to downgrade binutils to build a working 2.6.30.2 (or 2.6.30.1). In LKML other people also tracked down non-booting 2.6.30.x to be caused by the actual binutils package in sid. I can't see this kind of report for current Fedora and Ubuntu, which are both based to a subset of the hjl's binutils patches (the Debian package is pure upstream without these patches applied). As a quick check, please could you recheck with the package found here: http://packages.ubuntu.com/karmic/amd64/binutils/download http://packages.ubuntu.com/karmic/i386/binutils/download No difference: neither 2.6.30.2 nor 2.6.30.1 work. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537389: binutils 2.19.51.20090714-1 produces non-bootable kernel
Package: binutils Version: 2.19.51.20090714-1 There were no error messages or anything from the kernel; just the spontaneous reboot or hang. No configuration kernel configuration changes either; the only difference in a working test case and a non-working test case was building with different versions of binutils. There's nothing special about the PC that had the problem booting the kernel. It's an old machine that has never had problems with Linux. I can confirm that. I had to downgrade binutils to build a working 2.6.30.2 (or 2.6.30.1). In LKML other people also tracked down non-booting 2.6.30.x to be caused by the actual binutils package in sid. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524845: libslang2 depends on libpng12-0
Package: libslang2 Version: 2.1.4-2 Severity: serious libslang2 depends on libpng12-0. Either libpng12-0 is really needed, in this case libpng12-0 probably needs to go into /lib. Or, as it seems, libpng12-0 is not needed, just suggested. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523102: do_bootloader=yes not completely honored
Package: kernel-package Version: 11.015 Installing a kernel-image build with kernel-package the postinst scripts asks if lilo should run even if bootloader=yes is set in kernel-img.conf The reason is that $explicit_do_loader will never be set in the postrm script: $do_bootloader = Yes if /do_bootloader\s*=\s*(yes|true|1)\s*$/ig; $explicit_do_loader = YES if /do_bootloader\s*=\s*(yes|true|1)\s*$/ig; Because of the g flag the first lines matches and consumes the line, so that the second can not match any more. To make it work the g flag of the first of those two lines must be removed: $do_bootloader = Yes if /do_bootloader\s*=\s*(yes|true|1)\s*$/i; $explicit_do_loader = YES if /do_bootloader\s*=\s*(yes|true|1)\s*$/ig; Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#484269: openssh-blacklist bloats small debian systems with sshd
Package: openssh-server Version: 1:4.7p1-12 Severity: important openssh-server depends on openssh-blacklist. This enhances the size of an small debian system significantly. I think it es wrong to force the blacklist on every user of openssh. openssh-server should: * check at runtime if blacklists are installed. It may log a warning message if it does not find blacklists (by default, which must be switched off explicitely in the sshd_config file) * and only recommend the openssh-blacklist package Alternatively debian could provide a package which provides openssh-blacklist but actually do not contain any blacklists. Regards -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484105: openvpn: bad keys detection bloads openvpn
Package: openvpn Version: 2.1~rc7-3 Severity: important openvpn uses openssl-vulnkey and openvpn-vulnkey. So its size enhances suddenly by more than 22MB (blacklists, python, libsqlite3-0, libdb4.5). I think it es wrong to force that on every user of openvpn. openvpn should: * check if /usr/bin/openssl-vulnkey and /usr/sbin/openvpn-vulnkey is available at runtime * and then only recommend the packages openvpn-vulnkey and openssl-vulnkey Alternatively debian could provide a package which provides openssl-blacklist and openvpn-blacklist but only contains openssl-vulnkey and openvpn-vulnkey commands. Regards -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
