Bug#315753: knockd shuts down when the interface disappears
Hi list This is still happening in Bullseye: knockd shuts down with the interface citing "pcap: The interface went down" and does not get restarted when the interface comes up again. A simple systemctl restart knockd does the trick, but this is not triggered automatically when you still use the networking.service (ifup method) So I tried a knockd.service.d override that should bind knockd to the relevant interface with: [Unit] BindsTo=ifup@eth1.service This fails as well with exit status 15. On Tue, 19 Apr 2011 01:02:00 +0200 Christian Kastner wrote: > > retitle 315753 knockd shuts down when the interface disappears > > The problem can be generalized: knockd shuts down when the interface > disappears, be it ppp0 or eth0 or whatever. > > Running knock in the foreground, the following message is printed when > the interface goes down (and nothing else): > > "pcap: The interface went down" > > Perhaps this condition could be handled differently, eg: waiting either > for the interface to come back up or /etc/init.d/knock stop is called? > >
Bug#315753: knockd shuts down when the interface disappears
Hi list,
This is still happening in Bullseye: knockd.service shuts down with the
interface citing "pcap: The interface went down" and does not get
restarted when the interface comes up again. A simple systemctl restart
knockd does the trick, but this is not triggered automatically when you
still use the networking.service (ifupdown method).
So I tried a knockd.service.d override that was supposed to bind knockd
to the relevant interface [eth1] with:
[Unit]
BindsTo=ifup@eth1.service
After=ifup@eth1.service
This fails as well with exit status 15 (same exit code) and does not
restart the unit when ifup@eth1.service is triggered successfully again.
I ended up disabling knockd.service and reverting back to an ifupdown
script solution (see attachment.)
I used setcap 'cap_net_admin,cap_net_raw,cap_sys_module=eip' to drop the
knockd binary capabilities to the same level the knockd.service suggested.
Dropping the networking.service in favour of NetworkManager or
systemd-networkd might be a good idea, but I'm not there yet with my
setup, so I could not test how the knockd.service behaves then.
On Tue, 19 Apr 2011 01:02:00 +0200 Christian Kastner wrote:
retitle 315753 knockd shuts down when the interface disappears
The problem can be generalized: knockd shuts down when the interface
disappears, be it ppp0 or eth0 or whatever.
Running knock in the foreground, the following message is printed when
the interface goes down (and nothing else):
"pcap: The interface went down"
Perhaps this condition could be handled differently, eg: waiting either
for the interface to come back up or /etc/init.d/knock stop is called?
cat /etc/network/if-{up,down}.d/knockd
#!/bin/sh
if [ "$IFACE" != "eth1" ]
then exit 0
else echo "starting knockd for [$IFACE]"
fi
if ! [ $(pidof knockd) ] ; then /usr/sbin/knockd -d -i $IFACE -c
/etc/knockd.conf ; fi
exit 0
---
#!/bin/sh
if [ "$IFACE" != "eth1" ]
then exit 0
else echo "stoping knockd for WAN interface [$IFACE]"
fi
if [ $(pidof knockd) ] ; then killall knockd ; fi
exit 0
Bug#987223: please bump fluxbox version from 1.3.5 to 1.3.7 - patch wish included
Package: fluxbox Version: 1.3.5-2 sourceforge does ship 1.3.7 [1] from 2016 and there is fluxbox.git [2] QT5 apps are acting up in fluxbox, when you try to leave main windows in maximized state. A fix for that was discussed and proposed in the sourceforge bug tracker [3]. Proposed patch is small and applies fine against 1.3.7 or 1.3.7-git Please consider it as an upgrade for Bullseye - it provides hassle free use of kwrite, konsole, even vlc in a fluxbox environment, given that qt5ct is installed as well. Thank you! [1] https://sourceforge.net/projects/fluxbox/files/latest/download [2] http://git.fluxbox.org/fluxbox.git/ [3] https://sourceforge.net/p/fluxbox/bugs/1176/#cc9f
Bug#985369: Banana Pi Call Trace in sound/core/init.c:207 snd_card_new+0x430/0x480 [snd]
Package: 5.10.0-4-armmp-lpae Version: Debian 5.10.19-1: armhf Call Trace coming up: [ +0.303626] [ cut here ] [ +0.008081] WARNING: CPU: 0 PID: 248 at sound/core/init.c:207 snd_card_new+0x430/0x480 [snd] [ +0.007999] Modules linked in: sun4i_codec(E+) snd_soc_core(E) snd_pcm_dmaengine(E) snd_pcm(E) nvmem_sunxi_sid(E) sun4i_ts(E) sg(E) snd_timer(E) snd(E) sunxi_cir(E) soundcore(E) rc_core(E) sun4i_ss(E+) libdes(E) sunxi_wdt(E) sunxi_cedrus(CE) videobuf2_dma_contig(E) v4l2_mem2mem(E) videobuf2_memops(E) videobuf2_v4l2(E) videobuf2_common(E) leds_gpio(E) cpufreq_dt(E) fuse(E) configfs(E) sunrpc(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) btrfs(E) blake2b_generic(E) xor(E) xor_neon(E) raid6_pq(E) libcrc32c(E) crc32c_generic(E) f2fs(E) crc32_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) crct10dif_common(E) axp20x_usb_power(E) industrialio(E) pinctrl_axp209(E) axp20x_regulator(E) realtek(E) sun4i_backend(E) dwmac_sunxi(E) stmmac_platform(E) stmmac(E) ohci_platform(E) pcs_xpcs(E) phylink(E) ahci_sunxi(E) ehci_platform(E) ohci_hcd(E) libahci_platform(E) ptp(E) libahci(E) sunxi(E) phy_generic(E) lima(E) libata(E) gpu_sched(E) musb_hdrc(E) [ +0.000354] pps_core(E) ehci_hcd(E) udc_core(E) i2c_mv64xxx(E) scsi_mod(E) sun4i_drm_hdmi(E) usbcore(E) cec(E) spi_sun4i(E) sunxi_mmc(E) phy_sun4i_usb(E) sun4i_drm(E) sun4i_frontend(E) sun4i_tcon(E) sun8i_tcon_top(E) drm_kms_helper(E) display_connector(E) drm(E) [ +0.064237] CPU: 0 PID: 248 Comm: systemd-udevd Tainted: G C E 5.10.0-4-armmp-lpae #1 Debian 5.10.19-1 [ +0.010143] Hardware name: Allwinner sun7i (A20) Family [ +0.010019] Backtrace: [ +0.009907] [] (dump_backtrace) from [] (show_stack+0x20/0x24) [ +0.010172] r7:00cf r6:600f0113 r5: r4:c16d04d0 [ +0.010253] [] (show_stack) from [] (dump_stack+0xc8/0xdc) [ +0.010012] [] (dump_stack) from [] (__warn+0xfc/0x158) [ +0.010183] r7:00cf r6:0009 r5:bf6e1604 r4:bf6eb01c [ +0.010016] [] (__warn) from [] (warn_slowpath_fmt+0x70/0xe4) [ +0.010317] r7:bf6e1604 r6:00cf r5:bf6eb01c r4: [ +0.010074] [] (warn_slowpath_fmt) from [] (snd_card_new+0x430/0x480 [snd]) [ +0.010305] r8:c2e0f8c4 r7:c1a3ec10 r6: r5:c2ca3000 r4: [ +0.010210] [] (snd_card_new [snd]) from [] (snd_soc_bind_card+0x3a8/0xa30 [snd_soc_core]) [ +0.010262] r10: r9:bf759d8c r8:c1a26e80 r7:0001 r6:0050 r5:c2e0f840 [ +0.010202] r4:c2bc2d00 [ +0.010557] [] (snd_soc_bind_card [snd_soc_core]) from [] (snd_soc_register_card+0xf8/0x108 [snd_soc_core]) [ +0.010486] r10:0024 r9:bf733170 r8:c1a26e80 r7:bf72e6f4 r6:c1a3ec10 r5:c2bd4a00 [ +0.010532] r4:c2e0f840 [ +0.010512] [] (snd_soc_register_card [snd_soc_core]) from [] (sun4i_codec_probe+0x230/0x468 [sun4i_codec]) [ +0.011003] r5:c2bd4a00 r4:0002 [ +0.010799] [] (sun4i_codec_probe [sun4i_codec]) from [] (platform_drv_probe+0x58/0xa8) [ +0.011063] r8: r7:c17f1de0 r6:bf733170 r5:c1a3ec10 r4: [ +0.011147] [] (platform_drv_probe) from [] (really_probe+0x108/0x514) [ +0.011228] r7:c17f1de0 r6: r5:c17f1dd8 r4:c1a3ec10 [ +0.011134] [] (really_probe) from [] (driver_probe_device+0x100/0x1d4) [ +0.16] r10:bf733940 r9:c1604e00 r8:c2f15f30 r7:bf733170 r6:c1a3ec54 r5:bf733170 [ +0.06] r4:c1a3ec10 [ +0.15] [] (driver_probe_device) from [] (device_driver_attach+0xb8/0xc0) [ +0.10] r9:c1604e00 r8:c2f15f30 r7:bf733170 r6:c1a3ec54 r5: r4:c1a3ec10 [ +0.12] [] (device_driver_attach) from [] (__driver_attach+0x9c/0x150) [ +0.18] r7:c17579a8 r6:c1a3ec10 r5:bf733170 r4: [ +0.079177] [] (__driver_attach) from [] (bus_for_each_dev+0x84/0xd0) [ +0.16] r7:c17579a8 r6:c0aac58c r5:bf733170 r4: [ +0.13] [] (bus_for_each_dev) from [] (driver_attach+0x2c/0x30) [ +0.08] r6: r5:c2f71780 r4:bf733170 [ +0.11] [] (driver_attach) from [] (bus_add_driver+0x120/0x20c) [ +0.13] [] (bus_add_driver) from [] (driver_register+0x98/0x128) [ +0.08] r7: r6:bf733a70 r5: r4:bf733170 [ +0.13] [] (driver_register) from [] (__platform_driver_register+0x50/0x58) [ +0.07] r5:c2fbe300 r4:c17579a8 [ +0.53] [] (__platform_driver_register) from [] (sun4i_codec_driver_init+0x24/0x1000 [sun4i_codec]) [ +0.06] r5:c2fbe300 r4:bf704000 [ +0.24] [] (sun4i_codec_driver_init [sun4i_codec]) from [] (do_one_initcall+0x50/0x27c) [ +0.14] [] (do_one_initcall) from [] (do_init_module+0x70/0x2a4) [ +0.09] r7:c2f15ea8 r6:bf733a70 r5:c2fbe300 r4:bf733940 [ +0.10] [] (do_init_module) from [] (load_module+0x2260/0x264c) [ +0.08] r6:bf733a70 r5:bf73394c r4: [ +0.10] [] (load_module) from [] (sys_finit_module+0xc8/0x12c) [ +0.12] r10:017b r9:c2f14000 r8:c04002c4 r7:017b r6:b6f60504 r5:0014 [ +0.05] r4: [
Bug#981586: Bullseye armhf kernel for Raspberry Pi 4b does not boot
Package: linux-image-5.10.0-2-armmp Version: 5.10.9-1: armhf Package: linux-image-5.10.0-2-armmp-lpae Version: 5.10.9-1: armhf Analysis showed that it does reach init-top. But when usbcore and usbhid are loaded, peripherals like mouse and keyboard are not at all detected. When later usbhid, usb_storage and uas should be started, they do not work either and the root file device is not detected. The same problem exists also for Buster armhf. However, Bullseye 64 Bit and Ubuntu 5.4 LTS armhf do work as expected. Building 5.9 against the Ubuntu 5.4 kernel config also does work. I hope that Bullseye 32 armhf can soon be fixed and I'm prepared to test future versions.
Bug#846297: mesa-vdpau-drivers: breaks vdpau for mpeg2video with mpv and vlc
@Jörg-Volker Peetz: can you please confirm this is fixed in mesa-vdpau-drivers 13.0.2-3 ? I use an onboard GPU Radeon 4290 which is almost the same model. I can't playback accelerated mpeg-2 with vlc - output is garbled in a similar way than you described, h.264 works fine. I'm sending a BC to the OP. Bug #847012 might be a duplicate, if the OP there uses an ATI GPU as well. Regards, Tuxo
Bug#770790: Info received (FW: random/intermittent black screen generally affects 3.16 of radeonhd)
@Ben: fixed upstream in torvalds/linux.git commit #72edd83cc9e5819ed1ee771519143d7594e059f0 Can you please push this for linux-image-3.16.0-5 ? thanks
Bug#777391: flashplugin-nonfree should update when Adobe Flash does
Or any other solution that achieves this result :-) That exists: update-flashplugin-nonfree --status update-flashplugin-nonfree --install Regards, Bart Martens Bart, what you could do is change the exit status of your script to non-zero, when --quiet --status does find a newer version. That way we can make use of this feature in a daily cronjob. I have to admit flash-plugin is really going down the drain now, which makes it more important to have an automated way for daily checks and possibly disable it altogether with a new switch called update-flashplugin-nonfree --disable. That switch could simply move the alternatives symlink to a an empty dumyfile and give that one the highest priority, as long it's not safe/desirable to use the current exploited and yet-to-be-fixed version. --status should of course reflect a disabled state. We would however have to check how the browser reacts on that dumyfile ... what's a safe way to disable a plugin and still have reference to it as beeing there, but disabled?
Bug#770790: random/intermittent black screen generally affects 3.16 of radeonhd
okay ... Ben, that small patch in attachment #163891 does indeed fix the screen flickering for me: I built three versions of radeon.ko against 3.16.7-ckt2 from debian/testing: 1) vanilla version: reproducible flickering, it's even easier to reproduce by quickly dragging a medium sized window around in circles 2) superseded version (attachment #159331): no flickering, might contain a typo on line 1002, but I did not fix that one and it ran flawless for days 3) current version (#attachment 163891): no flickering, C.K. might need somebody to confirm this patch is working fine as well Since I ingeniously managed to forget my pw AND the security question, I can't sign into my bugzilla.kernel.org account and tell him this myself O_o If you could look at that patch and then decide whether it's safe to use for debian 3.16 that would be much appreciated.
Bug#770790: FW: random/intermittent black screen generally affects 3.16 of radeonhd
*strike that* that would be attachment #163891 - the patch at the bottom ... [2] [2] https://bugzilla.kernel.org/show_bug.cgi?id=83461#c32 From: tuxoho...@hotmail.de To: 770...@bugs.debian.org Subject: RE: random/intermittent black screen generally affects 3.16 of radeonhd Date: Sun, 1 Feb 2015 11:44:01 +0100 [1] https://bugzilla.kernel.org/show_bug.cgi?id=83461#c27
Bug#770790: random/intermittent black screen generally affects 3.16 of radeonhd
Agreed , that patch has been superseded by a newer version [1] I'll try that one against current linux source in testing and report back. [1] https://bugzilla.kernel.org/show_bug.cgi?id=83461#c27
Bug#770790: random/intermittent black screen fixed upstream in 3.16.7-ckt2
Update: Turns out rebuilding 3.16.7-ckt2 (which is the current kernel source in testing) and using this PATCH [1] does fix it for me. I assume this will be pushed soon to a new linux-image-3.16.0-xx ? [1] https://bugzilla.kernel.org/show_bug.cgi?id=83461#c27
Bug#770790: random/intermittent black screen generally affects 3.16 of radeonhd
+ 1 for this bug from another RS880 / G785 IGP user: Using Jessie with 3.16.4 amd64 kernel I get random blank screens for 2 seconds with an 1080p ACER LCD connected to the DVI or HDMI input (monitor supports both inputs, as does my AsRock mainboard) Kernel 3.14 in Jessie was not affected by this bug, but a quick google dug up several blasts from the past in Squeeze/Wheezy during the grub2/KMS migration phase: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529178 http://lists.opensuse.org/opensuse-bugs/2014-09/msg00789.html 3.16 related bugs of that kind can be found in Opensuse 13.2 as well - I will report on that to the Novell guys later. https://bugzilla.novell.com/show_bug.cgi?id=767360 Thus people migrating from a flawless working Ubuntu 12.04 (kernel 3.14) to 12.10 (kernel 3.16) are apparently hit by this as well: http://ubuntuforums.org/archive/index.php/t-2246456.html As always: the bug will not show when disabling KMS with the nomodeset boot parameter, which leaves us with a totally messed up aspect ratio caused by an unfitting vesa mode resolution. If you're affected by the bug it will most likely be trigged by scrolling in a webbrowser (pick a loaded site for testing this) , but I also came along the bug by the page-up action in an x-terminal. Another observation that might explain the difficulty to track this down in the past: it's gpu type and monitor type dependend: The same Acer monitor will *not* show the bug on *the same* installation, if it's a run on an SB 850 chipset - that one is only slightly newer to my understanding: (RS880P , IGP version would be called an ATI Radeon HD 4290 and still be an UVD-2 type) And a G780 chipset (RS780) connected to HDMI and a Phillips monitor using the same Jessie installation does *not* trigger the bug ... so indeed, this might be tricky to reproduce. Here's one more non-blanking related thing I noticed about the radeon KMS framebuffer: It seems to ignore the gxfpayload grub parameter: You can successfully set a high grub2 resolution with gfxmode=auto and verify this with vbeinfo in the grub2 command line, but when you start booting you will end up using gxfpayload_linux=text in the initial booting phase, then switch to a higher resolution, then switch one last time to the X resolution (and well ... by then the blank screen bug will continue to kick in eventually and intermittently) Forcing grub_gfxpayload_linux=keep in /etc/default/grub does not seem to help, that value is ignored. You will end up with the 80-lines character mode then, should you try to use a cryptoroot hook and type in the luks pw in that early booting stage. Hope this helps to fix this bug for good, I volunteer for more testings on several radeonhd gpus + monitors Regards TuxoHolic
Bug#741164: no mp3splt-gtk in jessie?
Hello, Any update on this? Meanwhile http://mp3splt.sourceforge.net/ does ship ready to use packages for jessie in his own repository: version 0.9.2 for the GTK user interface (NOT available in the debian/jessie mirrors yet) version 2.6.2 for mp3splt (2.4 in the debian mirrors) version 0.9.2 for Libmp3splt (0.7.2 in the debian mirrors)
