Bug#1036657: bridge-utils: inconsistent IPv6 local-link between Ethernet and WiFi
On Xuñ 04 2023, Martin-Éric Racine wrote: > allow-auto br0 > allow-hotplug /en* /wl* > iface br0 inet static > bridge_ports regex (enp3s|enp2s|wl).* > address 172.16.1.1 > iface br0 inet6 auto > # IPv6-PD via /etc/dhcpcd.conf > # Routing via /etc/boot.d/iptables_IPv4-MASQ_IPv6-Bridge > iface enp4s0 inet dhcp > iface enp3s0 inet manual > iface enp2s0 inet manual Can you remove these two lines (enp2s0 and enp3s0 definitions) and see if that makes any difference? I don't expect that will make any difference but for what I see they are not needed. Also... I'd add a "bridge_ports none" statement to the br0 inet6 stanza so that it is handled by bridge-utils, otherwise the bridge won't do a thing about it and maybe it is even showing some kind of error because of this. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#1036657: bridge-utils: inconsistent IPv6 local-link between Ethernet and WiFi
> In Bullseye, Ethernet cards did not have any IPv6 local-link, while Wifi > adapters did. In Bookworm, it the opposite. Wifi is very dependant on how you configure it, but as you say, now on bookworm you are not getting IPv6 on them, so... let's go for ethernet cards... on my machines I don't see any inet6 address assigned to any of the ethernet ports asigned to the bridge ports either full physical or vlan based. > It should be neither. Only configured interfaces should have an IPv6 > local-link. For bridges, it means that only the bridge should have an IPv6 > local-link, not the interfaces attached to it. I agree on this, can you share your setup so that I can try to replicate it? Also... is there any Router Advertisement Daemon or dhcpV6 daemon assigning ipV6 addresses? Regards... -- Manty/BestiaTester -> http://manty.net
Bug#1035940: unblock: squid/5.7-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: sq...@packages.debian.org
Control: affects -1 + src:squid
Please unblock package squid
squid on testing has several bugs which were fixed on version 5.8
of upstream, however 5.8 would not be allowed on bookworm when it
was released, so upstream for squid has sugested us to ship two
patches on top of 5.7, the suggested patches are the only changes
done to the package and can be seen here:
https://salsa.debian.org/squid-team/squid/-/commit/7ffc938c1456033ce4772bec067c6c90584bc348
https://salsa.debian.org/squid-team/squid/-/commit/cdd9134b05ac6587b4391a407061a426d283b840
[ Reason ]
The new package version solves a couple of nasty bugs.
[ Impact ]
Bugs introduced by the version now in testing and not present on stable
[ Tests ]
piuparts and autopkgtest passed, the code has also been tested on production
machines.
[ Risks ]
None identified, patches are from upstream, really small, apply cleanly and
work Ok.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[ Other info ]
unblock squid/5.7-2
diff -Nru squid-5.7/debian/changelog squid-5.7/debian/changelog
--- squid-5.7/debian/changelog 2022-10-04 11:04:20.0 +0200
+++ squid-5.7/debian/changelog 2023-04-28 08:35:27.0 +0200
@@ -1,3 +1,10 @@
+squid (5.7-2) unstable; urgency=medium
+
+ * Add a couple of upstream picked patches to fix some issues on 5.7
+that upstream has fixed on 5.8.
+
+ -- Santiago Garcia Mantinan Fri, 28 Apr 2023 08:35:27
+0200
+
squid (5.7-1) unstable; urgency=medium
* Urgency high due to security fixes
diff -Nru
squid-5.7/debian/patches/1f13f721263a4cc75e4b798a230022561047899c.patch
squid-5.7/debian/patches/1f13f721263a4cc75e4b798a230022561047899c.patch
--- squid-5.7/debian/patches/1f13f721263a4cc75e4b798a230022561047899c.patch
1970-01-01 01:00:00.0 +0100
+++ squid-5.7/debian/patches/1f13f721263a4cc75e4b798a230022561047899c.patch
2023-04-28 08:35:27.0 +0200
@@ -0,0 +1,42 @@
+From 1f13f721263a4cc75e4b798a230022561047899c Mon Sep 17 00:00:00 2001
+From: Eduard Bagdasaryan
+Date: Thu, 1 Dec 2022 18:50:37 +
+Subject: [PATCH] Bug 5162: mgr:index URL do not produce MGR_INDEX template
+ (#1191)
+
+Satisfy mgr:index requests using
+
+* a 200 OK response with a body derived from the MGR_INDEX template (if
+ that template file was found during (re)configuration) or
+* a 404 (Not Found) error response (otherwise).
+
+Broken in 2019 commit 7e6eabb, when Squid started replying using a 200
+OK response with a hard-coded "mgr_index" text as a body, ignoring any
+configured MGR_INDEX template.
+---
+ src/errorpage.cc | 5 +
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+diff --git a/src/errorpage.cc b/src/errorpage.cc
+index 6fbedbe1dba..f74e6e554e2 100644
+--- a/src/errorpage.cc
b/src/errorpage.cc
+@@ -154,6 +154,7 @@ static const struct {
+ const char *text;
+ }
+
++/// error messages that cannot be configured/customized externally
+ error_hard_text[] = {
+
+ {
+@@ -180,10 +181,6 @@ error_hard_text[] = {
+ {
+ ERR_REQUEST_START_TIMEOUT,
+ "request start timedout"
+-},
+-{
+-MGR_INDEX,
+-"mgr_index"
+ }
+ };
+
diff -Nru
squid-5.7/debian/patches/edad3f150de8af0aeb2f629508be3219b83369b9.patch
squid-5.7/debian/patches/edad3f150de8af0aeb2f629508be3219b83369b9.patch
--- squid-5.7/debian/patches/edad3f150de8af0aeb2f629508be3219b83369b9.patch
1970-01-01 01:00:00.0 +0100
+++ squid-5.7/debian/patches/edad3f150de8af0aeb2f629508be3219b83369b9.patch
2023-04-28 08:35:27.0 +0200
@@ -0,0 +1,31 @@
+From edad3f150de8af0aeb2f629508be3219b83369b9 Mon Sep 17 00:00:00 2001
+From: Alexander Bokovoy
+Date: Sat, 10 Dec 2022 11:50:27 +
+Subject: [PATCH] ext_kerberos_ldap_group_acl: Support -b with -D (#1207)
+
+When both '-b' (i.e. bind DN) and '-D' (i.e. Kerberos domain) options
+are specified, '-b' is ignored completely. This breaks the helper when a
+search subtree has to be limited (e.g., when using FreeIPA).
+
+Fix it to take '-b' into account if it was specified with '-D'.
+---
+ src/acl/external/kerberos_ldap_group/support_ldap.cc | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/src/acl/external/kerberos_ldap_group/support_ldap.cc
b/src/acl/external/kerberos_ldap_group/support_ldap.cc
+index 3608148a388..c713215a85c 100644
+--- a/src/acl/external/kerberos_ldap_group/support_ldap.cc
b/src/acl/external/kerberos_ldap_group/support_ldap.cc
+@@ -1114,7 +1114,11 @@ get_memberof(struct main_args *margs, char *user, char
*domain, char *group)
+ "%s| %s: DEBUG: Error during initialisation of ldap
connection: %s\n",
+ LogTime(), PROGRAM, strer
Bug#1031137: bridge-utils: No longer recognizes alternative NIC name (enp5s0)
Hi! > With that upgrade round bridge-utils went from 1.7-1 to 1.7.1-1. > That server has an iKVM module so I could still access it and found that > `brctl show` did not show any interfaces. I'd say it is impossible that it was the bridge-utils change, could you have a look at what had changed from the last reboot to this one? Maybe something related to systemd or udev or similar stuff, that is, along with the kernel, what is typically playing with interface naming. > The previous kernel was 6.1.4 (6.1.0-1-amd64) so I doubt that that > upgrade triggered this issue, so my guess is that it's 1.7-1 to 1.7.1-1. If you have a look at bugs.debian.org/1029445 you can see a diff for upstream changes, it hasn't changed much from 1.7 to 1.7.1, and the changes are just mostly cosmetic or packaging changes, just that. Let's see if you can have more info on the changes so that we can assign this bug to the right package. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#1025141: powermgmt-base: Doesn't correctly detect we are on AC power
Hi! > It's possible that your machine can indeed be powered via USB C, new laptops > usually can. Which leads to fun like laptop that wants to be charged by a > phone -- and indeed negotiating it that way. If it was like that... do you think that USB-C would be a real USB or just for power delivery? I could atach a USB-C hub I have arround. I don't think a PD power supply will be able to supply enough power unless I unplug the two SATA HD I have plugged and the graphic card. I could try to unplug all this and try to get a PD power supply to test if you feel it would help us. > Could you perhaps provide: > cd /sys/class/power_supply && grep . */* 2>/dev/null|grep -v /uevent: ucsi-source-psy-USBC000:001/current_max:0 ucsi-source-psy-USBC000:001/current_now:0 ucsi-source-psy-USBC000:001/online:0 ucsi-source-psy-USBC000:001/type:USB ucsi-source-psy-USBC000:001/usb_type:[C] PD PD_PPS ucsi-source-psy-USBC000:001/voltage_max:0 ucsi-source-psy-USBC000:001/voltage_min:0 ucsi-source-psy-USBC000:001/voltage_now:0 Regards... -- Manty/BestiaTester -> http://manty.net
Bug#1002656: bridge-utils: bridge_hw: add random option like for ifupdown hwaddress
> The kernel using the MAC of a real device, if none is specified, is > precisely what we wanna avoid. Systemd is not involed. Like I said, if we don't specify the mac address systemd will set up a fake one for us, so... systemd is involved and the kernel is not allowed to use a real one, that's why I said that bridge-utils shouldn't do a thing about this. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#1002656: bridge-utils: bridge_hw: add random option like for ifupdown hwaddress
Hi! > It would be desirable for bridge_hw to be able to generate a random MAC > address as per ifupdown's generic hwaddress syntax. I don't know if I get this right or not... if you don't want to specify a MAC or get it from an interface... then you better not assign any MAC and so systemd will do his thing and assign a "random" one. I really don't think that the code on bridge-utils should generate such a random MAC, systemd already causes a lot of trouble by overriding the address that the kernel would select, I don't think we need another actor here. Can you justify your request? Otherwise I'll close the bug. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#993716: I think this should be fixed on ifupdown
Hi! I'd like to sum this up. The problem comes when we create a bridge with an IPv6 but without assigning any ports to it. What happens then is that DAD is triggered and ifupdown fails to bring the interface up as DAD times out. Waiting for DAD... Timed out ifup: failed to bring up br1 We can just sugest to set dad-attempts to 0 when using bridges without ports, but maybe that's not a good thing as the bridge can have the ports attached later and DAD would be needed then. Other than that, all I can think of is fixing it on ifupdown by not failing on DAD timeout or even not doing DAD at all if the interface is a bridge without ports, but maybe that is too complicated. I'll be around with an eye on the bug, in case you need help or want to discuss anything just cc me. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#993716: bridge-utils: IPv6 network bridge fails after upgrading Buster to Bullseye
Hi! On Set 06 2021, Pieter Hollander wrote: > PS: Additionally, I forgot to mention that adding dad-attempts 0 to the br0 > inet6 config also solves the issues of networking failing. > > Using a dummy port to perform DAD sounds like the best solution to me. > > Back to the workaround: It also solves the problems I encountered with > > Unbound & PostgreSQL being unable to bind to the IPv6 interface address > > specified. Sorry for coming back to this so late... going over it now I see that I didn't get which of the workarounds worked for you. Did you add a dummy port? if so... can you send a config example? If not... how did you fixed this? Regards. -- Manty/BestiaTester -> http://manty.net
Bug#980507: Closing this bug
It looks like the latest changes we did before Bullseye are working, so I'm changing the interfaces man page removing the stp warning pointing to the 736336 bug report as that was no longer true. With this change I'm marking this bug closed. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#1013268: chromium: Broken kerberos authentication
> > "AuthServerWhitelist": "*.internal.domain" > You need to replace "Whitelist" with "Allowlist", the names were changed in > Chromium 101. That was it, AuthServerAllowlist is what I needed. Thanks a lot for your quick reply, maybe we can close the bug, or maybe close it after adding a little note on the NEWS file or at least the changelog? I had searched the web for this, but searching with the old term... I guess that resulted on old term results, not the change. Again, thanks a lot for your quick reply. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#984897: Merge request to fix this bug
Hi! This bug came in response for a proper fix in order for the problem we found in squid after introducing the new squid-openssl flavour, that was: https://bugs.debian.org/984880 At that time I spoke to Niels Thykier in order to fix this, but it was late in the bullseye development cycle a fix on debhelper seemed too dangerous, I've further thought about the problem, as the first patch I had sent was failing when dh_installsystemd was called with several services, like: dh_installsystemd -ppackage first.service second.service The new proposal takes this into account and now UNITFILES can really be plural, in the sense of have mor than one unit file, and thus I believe this is finally a full solution. Please consider this merge request: https://salsa.debian.org/debian/debhelper/-/merge_requests/65 so that we can have a proper fix for #984880 on squid in time for bookworm and if you need further explanations just let me know. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#989162: bridge-utils: ifupdown scripts should not unconditionally disable IPv6 on physical interface
> This is NOT about addresses on bridge ports (and I agree those are not > needed or desirable), but the case where the bridge port is a VLAN Ok. > interface. Then the current code prevents you from using not just the > VLAN interface (e.g. eth0.3), but also the underlying physical interface > (i.e. eth0). I see no reason why you should not use both of these > simultaneously. Well, having IPv6 addresses attached to those ports can also be undesirable, I really think that those addresses should be allowed with an explicit config not by default. > The patch I sent does not change anything about disabling ipv6 on the > bridge port interface, only for the underlying physical interface for a > VLAN bridge port. I know, but I don't think that is the behaviour change we need. I think we should find a way to say we should not disable them, or a way to enable them if we want, but not by default. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#984897: Problems in a setup with two conflicting binary packages which share the same service name
Hi! We had spoken about this problem and the possible fix and by that time, so close to Bullseye release... it was not a good timing. I guess now would be the right timing, before bookworm gets us again in a bad timing situation again. Do you need any more info on this? Regards. -- Manty/BestiaTester -> http://manty.net
Bug#989162: bridge-utils: ifupdown scripts should not unconditionally disable IPv6 on physical interface
On Xan 20 2022, Anton Khirnov wrote: > Attaching a patch. I still couldn't think of a reason this code should > ever disable IPv6 on the physical interface, so it's removed > unconditionally. If anyone can think of such a reason, then I guess an > option could be added? Well, the thing here is that since de beginning of the bridge code it was recommended not to add ip addresses to the bridge ports, this was a long time ago, and maybe it has changed, if so, I'd like to know when. But anyway... why would you want to have an IP v4 or v6 on the bridge ports? why not having it on the bridge itself? Regards. -- Manty/BestiaTester -> http://manty.net
Bug#993920: Patch works on bullseye
Hi! Thanks Sascha for the pointer. I have tested it on bullseye and it really works, great. I don't know if we could add this patch for the next .release or something. All I did was patch all the nodes, a ganeti force-reload and I was migrating without problems (no need to reboot the guests or anything). I'm attaching the patch as github's web seems to put it difficult (or even imposible, at least I didn't find it) to download the raw patch. Regards. -- Manty/BestiaTester -> http://manty.net --- a/usr/share/ganeti/3.0/ganeti/hypervisor/hv_kvm/__init__.py 2021-03-02 14:13:17.0 +0100 +++ b/usr/share/ganeti/3.0/ganeti/hypervisor/hv_kvm/__init__.py 2021-09-09 12:15:30.634811616 +0200 @@ -629,6 +629,10 @@ # different than -drive is starting) _BOOT_RE = re.compile(r"^-drive\s([^-]|(?
Bug#993947: Time lost, /etc/systemd/timesyncd.conf gets replaced with a default one
Hi again! I have just migrated another machine and I found out that it worked out well. The thing is exactly what you have descrived, here the order was (luckily) the right one, so when systemd-timesyncd is configured, systemd had already created the dpkg-bak file like we can see here: Configurando systemd (247.3-6) ...M Instalando una nueva versión del fichero de configuración /etc/systemd/journald.conf ...M Instalando una nueva versión del fichero de configuración /etc/systemd/logind.conf ...M Instalando una nueva versión del fichero de configuración /etc/systemd/networkd.conf ...M Instalando una nueva versión del fichero de configuración /etc/systemd/resolved.conf ...M Instalando una nueva versión del fichero de configuración /etc/systemd/system.conf ...M Instalando una nueva versión del fichero de configuración /etc/systemd/user.conf ...M Created symlink /etc/systemd/system/sysinit.target.wants/systemd-pstore.service → /lib/systemd/system/systemd-pstore.service.M Removing obsolete conffile /etc/dhcp/dhclient-exit-hooks.d/timesyncd ...M Obsolete conffile /etc/systemd/timesyncd.conf has been modified by you.M Saving as /etc/systemd/timesyncd.conf.dpkg-bak ...M Removing obsolete conffile /etc/pam.d/systemd-user ...M Configurando libmono-system-core4.0-cil (6.8.0.105+dfsg-3.2) ...M Configurando systemd-timesyncd (247.3-6) ...M Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /lib/systemd/system/systemd-timesyncd.service.M Created symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /lib/systemd/system/systemd-timesyncd.service.M Configurando libmono-system-security4.0-cil (6.8.0.105+dfsg-3.2) ...M Regards... -- Manty/BestiaTester -> http://manty.net
Bug#993947: Time lost, /etc/systemd/timesyncd.conf gets replaced with a default one
Package: systemd-timesyncd Version: 247.3-6 Severity: important Hi! On upgrade from Buster to Bullseye I have seen my machines, without Internet ntp access, loose their time sync because of the upgrade. On the upgrade to the new packages, the old /etc/systemd/timesyncd.conf file which specifies the right ntp servers to use, will get replaced with a default one which will not work for a setup where Internet ntp access is not available. Luckily the old file is left as /etc/systemd/timesyncd.conf.dpkg-bak, so a mv /etc/systemd/timesyncd.conf.dpkg-bak /etc/systemd/timesyncd.conf and proper reloading will get things back to normal. I don't know why this file is being replaced, this happened on all the machines that had a modified timesyncd.conf file and the system never asked if I wanted to override the setup or leave the old one, no choice was given, it was just replaced and that's it. If you feel that this is the right behaviour, I believe that we should at least add a note on the Release Notes or similar. Regards. -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (990, 'stable-security'), (990, 'stable'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd-timesyncd depends on: ii adduser 3.118 ii libc62.31-13 ii systemd 247.3-6 systemd-timesyncd recommends no packages. systemd-timesyncd suggests no packages. -- no debconf information
Bug#987445: Same warning, different error
Hi! I also got hit by the same warning on the logs that completelly misleaded me (thinking it was the error stopping me). I wanted to comment just in case some other people may also get hit by it. After upgrading a cluster from buster to bullseye I couldn't bring the guests back to my upgraded nodes. Ganeti would refuse to move them because there was a problem, when I looked at the ganeti logs I could only see the message: ganeti.errors.OpExecError: Could not pre-migrate instance sid: Failed to accept instance: Failed to start instance sid: exited with exit code 1 (kvm: -usbdevice tablet: '-usbdevice' is deprecated, please use '-device usb-...' instead This was completely misleading, as this message is only a warning, not an error, the real error was... kvm: -vnc 127.0.0.1:5142: keymap include files are not supported any more Which I just couldn't see anywhere until I looked at the kvm logs, don't know why I didn't see it, now I see it was on Ganeti's logs as well. Anyway, the error was caused by me having the keymap set to spanish, so what I did was: gnt-instance modify -H keymap= guest for every guest, but having them change the keymap meant a reboot off all guests. Having done that I thought I had finished, as I had all the nodes updated to bullseye and cleaned, the cluster is running ok and everything looks fine, however I got hit by another bug (#993920). Regards... -- Manty/BestiaTester -> http://manty.net
Bug#993920: Migration of guests fails on drbd with kvm
Package: ganeti Version: 3.0.1-2 Severity: important Hi! I tried to contact you through the ganeti at packages.d.o address but I'm not sure that has arrived to any mailbox, so I'm opening a bug so that we can comment this. After having all the nodes of a ganeti cluster updated to bullseye and cleaned, the cluster is running ok and everything looks fine, so... I started moving the guests to their default node and... guests started to freeze as they reached the destination node :-( When I tried to see what had happened to those guests connecting to the console... I got: # gnt-instance console sid Instance sid is paused, unpausing But the machine remains in a halted state, farder investigation of what had happened revealed... # cat /var/log/ganeti/kvm/sid.log kvm: Could not open '/var/run/ganeti/instance-disks/sid:0': Permission denied # ls -l /var/run/ganeti/instance-disks/sid:0 lrwxrwxrwx 1 root root 11 sep 2 12:48 /var/run/ganeti/instance-disks/sid:0 -> /dev/drbd11 # ls -l /dev/drbd* brw-rw 1 root disk 147, 0 sep 2 12:50 /dev/drbd0 brw-rw 1 root disk 147, 1 sep 2 12:50 /dev/drbd1 brw-rw 1 root disk 147, 10 sep 2 12:50 /dev/drbd10 brw-rw 1 root disk 147, 11 sep 2 12:48 /dev/drbd11 # id sid uid=123(sid) gid=105(kvm) groups=105(kvm) I run the machine as user sid (security_domain: sid), of course user sid cannot open the drbd I don't think it should either. I tested to see if this was the real problem, I changed group from disk to kvm on the secondary node of sid and then did a migration without any problem. So... looks like we are dropping privilege too soon and we move to the security domain user before the drbd is opened, so we can't open it when it is needed. I don't know if this is a problem on ganeti's side or if it is related to kvm, but I wanted to comment on it so that we can find a fix. Thanks in advance. -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (990, 'stable-security'), (990, 'stable'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ganeti depends on: ii adduser 3.118 ii ganeti-3.0 3.0.1-2 ii ganeti-haskell-3.0 3.0.1-2 ii ganeti-htools-3.03.0.1-2 ii init-system-helpers 1.60 ii lsb-base 11.1.0 ii python3 3.9.2-3 Versions of packages ganeti recommends: ii drbd-utils 9.15.0-1 ii fdisk2.36.1-8 ii ganeti-instance-debootstrap 0.16-6.1 pn ndisc6 ii qemu-system-x86 1:5.2+dfsg-11 Versions of packages ganeti suggests: pn blktap-dkms pn ganeti-doc pn molly-guard
Bug#987907: How I solved the python problem
Hi! I wrote a mail to ganeti at packages.debian.org which I don't know if you guys got, on it I commented over this problem and some others I had found while upgrading. The thing is that I also got this problem and the solution I found was to do a: apt install python-is-python2 And then magically everything fitted, I could install both ganeti versions and do the upgrade, after upgrading everything I removed all python 2 stuff and that's it. Hope it helps. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#993716: bridge-utils: IPv6 network bridge fails after upgrading Buster to Bullseye
Hi! I'm CCing Josué because this seems to be more on ifupdown's side than on bridge-utils. > > auto br0 > > iface br0 inet static > > address 10.10.10.1 > > netmask 255.255.255.0 > > bridge_ports none > > bridge_stp off > > bridge_fd 0 > > > > iface br0 inet6 static > > address 2001:db8::2 > > netmask 64 > These stanzas are missing the "bridge_hw" entry which can be a MAC > address or the name of the interface whose MAC to take. Thus your > bridge ends up being connected to nothing. I know we are having quite some trouble with the random bridge mac address, but this doesn't seem to be one of those cases. For what I see this is a problem with DAD, the bridge is created without any port attached to it, so the kernel doesn't allow it to transition from: 18: br0inet6 X/64 scope link tentative \ valid_lft forever preferred_lft forever to: 18: br0inet6 X/64 scope link \ valid_lft forever preferred_lft forever This is because without any port on the bridge the kernel cannot do any DAD. So, without trasitioning it remains on tentative all the time, and thus the script /lib/ifupdown/settle-dad.sh from the package ifupdown exits with a timeout message, like the one you are seing and an error status of 1, thus breaking the network setup. I have thanged the exit 1 to an exit 0 on that script and everything works like expected, this is a nasty workaround while we don't arrive to a better solution, the other solution would be to attach something to the bridge, maybe even a dummy port or similar. Josué, we've had the idea of integrating bridge setup (now on bridge-utils) into ifupdown, I wouldn't mind doing this for Bookworm, I would continue to take care of this part to the best of my knowledte even if it is on ifupdown. Maybe it it is the time to do that. As for this bug, the workaround I describe is not a valid solution, but maybe we can check on the settle-dad script to see if the device is a bridge without any interface added to it, and thus not transitioning, and return with a 0 on the timeout in that case? About integration... we have talked about that on some bugs that are somehow half way between bridge-utils and ifupdown, last one may be #939713, I would try to rewrite everything on the ifupdown scripts to depend on ip and not brctl, so that ifupdown wouldn't depend on bridge-utils. We can start some other thread on this if you want or we can talk about this on irc or mail, whatever. As for this bug... I believe it is on the ifupdown side, so I think we should reasign it, unless you see a way to fix this problem on the bridge-utils side, but I can't think about any fix on bridge-utils side right now. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#992158: Race in ifup maybe related to brctl failure in pre-up of network interface
> Thank you for your assistance. With hint for the relevant man > page "bridge-utils-interfaces" I found the bridge setup working > using the configuration > > auto br0 > iface br0 inet static > address 192.168.1.1 > network 192.168.1.0 > netmask 255.255.255.0 > bridge_ports none > bridge_hw 86:aa:aa:aa:aa:aa > > With that there is no race observed, I deem this bug report as > invalid. Yes, that looks ok for a setup where you don't want to add any ports to a bridge. > I tested without the legacy stuff, worked, making this bug report > irrelevant. Testing how far the change can be backported is > done on demand later, not relevant here (Bullseye). I don't remember any reason why current bullseye package can't be used at buster or prior versions. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#992158: Race in ifup maybe related to brctl failure in pre-up of network interface
Hi! First I'd like to thank Dennis for his good support, as always ;-) > > $ ifup virtbr0 > > Cannot find device "virtbr0" > > ifup: failed to bring up virtbr0 > > It is because the "bridge_ports" directive is missing. From the > manpage bridge-utils-interfaces(5): > >bridge_ports interface specification > this option must exist for the scripts to setup the bridge. > > Either specify "bridge_ports none" or "bridge_ports enp2s0 enp2s1" (or > whatever your physical interfaces are named). That's it, you always have to specify the bridge_ports directive so that we treat the interface as a bridge. > > I also reactivated "systemd-udevd": ... > > # systemctl reload /lib/systemd/network/80-bridgeutils.link > > Failed to reload lib-systemd-network-80\x2dbridgeutils.link.mount: Unit > > lib-systemd-network-80\x2dbridgeutils.link.mount not found. I really believe that this contribution from Dennis should not be needed, so I'd appreciate if you could test without this extra stuff, which hasn't really been thoroughtly tested and test with the standard setup, if we identify a problem with the standard bridge_hw setup we'll go over it. If you test it like that, please provide feedback to know if it worked and if we can close the bug or not. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#989043: squid: CVE-2021-31806 CVE-2021-31807 CVE-2021-31808
> CVE-2021-31806[0], CVE-2021-31807[1], CVE-2021-31808[2], see the SuSE > bug as well at [3]. Luigi are you around to take care about this? Anybody else? Regards. -- Manty/BestiaTester -> http://manty.net
Bug#856505: Bug#911443: linux-image-4.18.0-2-arm64: wlan0 no longer present
Hi! I no longer have a working pi3 around, but last time I checked, all the way through the 5.X series... it was ok, and this was at least until 5.8.X or 5.9.X. So, I'd say this is solved, at least for the Pi 3 b, which was the one I used to have around and which was presenting this on 4.19. I believe you can close this. Regards. El dom, 2 may 2021 a las 9:32, Salvatore Bonaccorso () escribió: > > Control: tags -1 + moreinfo > > On Mon, Dec 31, 2018 at 12:15:35AM +0100, Santiago Garcia Mantinan wrote: > > > > >> And could we have the patch I sent on #856505 to enable sound on this > > > > >> machines applied as well? > > > > > > > > i assume you are talking about: > > > > > > > > arm: bcm2835-audio: Document the device tree node to enable > > > > bcm2835-audio driver > > > > > > > > This patch will not be accepted. For a explanation please refer to: > > > > > > > > https://lkml.org/lkml/2018/10/16/1615 > > > > > > > > The proper solution is called: > > > > > > > > staging: bcm2835-audio: Drop DT dependency > > > > > > > > and is in linux-next since a week. > > > > I've been playing with those patches for a while on 4.19, but those patches > > won't work on their own, they depend on some other stuff that has been > > commited as well. All that would mean a lot of changes. > > > > So, it seems that 4.21 will have a solution for this through a lot of > > changes and updates on the drivers, ... > > > > But, if we are going to go with 4.19 I believe that the simple change I was > > proposing which works as expected is going to give us audio on the pi and > > only affects the pi, is a clean solution that would solve the problem. > > > > I don't see the problem on applying this patch on Debian while upstream > > evolves the drivers even more on 4.21 and next versions, all we do is enable > > what is available on 4.19 like it was coded. > > > > Any chance for this to happen? > > What is the status of this bug? has the issue been fixed upstream? > Does it happen still with a recent kernel from unstable or > buster-backports? > > Regards, > Salvatore > -- Manty/BestiaTester -> http://manty.net
Bug#985390: Uploaded -9 to try to fix the concerns
Hi! I have just uploaded -9 which tries to fix the things that we've talked that you didn't like. I'm attaching the debdiff. Hope this helps getting -9 on Bullseye. Regards. -- Manty/BestiaTester -> http://manty.net diff -Nru squid-4.13/debian/changelog squid-4.13/debian/changelog --- squid-4.13/debian/changelog 2021-03-21 00:58:29.0 +0100 +++ squid-4.13/debian/changelog 2021-03-23 00:18:11.0 +0100 @@ -1,3 +1,11 @@ +squid (4.13-9) unstable; urgency=medium + + * Clarify on NEWS and scripts that we no longer remove logs on purge. + * Clarify on postrm script that the debhelper code was put manually. + * Add README.Debian to squid-openssl. + + -- Santiago Garcia Mantinan Tue, 23 Mar 2021 00:18:11 +0100 + squid (4.13-8) unstable; urgency=medium * Add SQUID-2020_11.patch to fix HTTP Request Smuggling. diff -Nru squid-4.13/debian/NEWS squid-4.13/debian/NEWS --- squid-4.13/debian/NEWS 2021-03-08 22:32:47.0 +0100 +++ squid-4.13/debian/NEWS 2021-03-23 00:18:11.0 +0100 @@ -1,3 +1,13 @@ +squid (4.13-9) unstable; urgency=medium + + Current package flavours: squid (GnuTLS) and squid-openssl share config, + logs and cache. Since 4.13-6 none of them removes the logs on purge, so + that you can purge one flavour when switching to the other without loosing + the logs. If you don't need them anymore and want them removed you'll + have to do it yourself. + + -- Santiago Garcia Mantinan Tue, 23 Mar 2021 00:07:36 +0100 + squid (4.13-6) unstable; urgency=medium If you want to transition from squid to squid-openssl or vice versa you diff -Nru squid-4.13/debian/README.Debian squid-4.13/debian/README.Debian --- squid-4.13/debian/README.Debian 2021-03-08 22:32:47.0 +0100 +++ squid-4.13/debian/README.Debian 2021-03-23 00:18:11.0 +0100 @@ -1,18 +1,43 @@ -This is the next-generation Squid. In version 3.x squid has been ported to C++ -for code manageability. Since squid 2.x is not developed anymore except for bug -fixing, this package is where new features will be added. - -Squid 3.5 supports IPv6, WCCPv2, ICAP, Edge Side Include, SSL offloading, etc. Please -note that not all of the new feature have been enabled in Debian package. - -Squid 3.5 is configured by the /etc/squid/squid.conf file. Syntax of that -file is the same of previous versions of squid and each directive is largely -commented there. Configuration files from 2.x versions of squid will mostly -work in squid 3.5. Changes to the configuration file are reported in +This is the next-generation Squid. In version 3.x squid has been ported to +C++ for code manageability. + +Squid supports IPv6, WCCPv2, ICAP, Edge Side Include, SSL offloading, etc. + +Squid in Debian now comes in two flavours, the GnuTLS flavour, which is the +one that has been tratitionally supplied by Debian's squid package and a new +OpenSSL flavour which is provided by the squid-openssl package. + +Each flavour has its features, that's why we provide the two. The +traditional one is better at handling multiple certificates, while the +openssl flavour comes with SSL-Bump which allows full proxy transparency. + +Both flavours have their own specific options to be setup at config files, +but they share the same config files, both /etc/squid/squid.conf file, as +well as the new /etc/squid/conf.d/ directory. Syntax of those files is the +same of previous versions of squid and each directive is largely commented +there. Configuration files from 2.x versions of squid will mostly work in +later versions of squid. Changes to the configuration files are reported in /usr/share/doc/squid-common/RELEASENOTES.html +Both flavours of squid share not only the config files but also the log +files and the cache. When purging squid, the package didn't remove the +cache files, typically at /var/spool/squid, and now, since version 4.13-6, +it also doesn't remove the logs at /var/log/squid, this means that if you +want to migrate to squid-openssl and, afterwards, purge squid, you must make +sure you have at least version 4.13-6 of squid installed, this way you won't +loose the logs when you purge squid. So, if you have version 4.13-6 or +later of the squid packages, you can switch flavours and try each flavour's +own features without any problem, but first make sure you have at least +version 4.13-6 of the squid packages, otherwise you'll probably loose the +config file and the logs. + +This also means that if you want to fully purge all squid stuff from your +system, you must remove by yourself /var/spool/squid (to save time you can +use mkfs if you have them on a separate filesystem) and /var/log/squid if +you are completely sure that you don't need those files anymore. + The squid homepage is at http://www.squid-cache.org/ Squid was downloaded from that site with HTTP. - -- Luigi Gangitano , Wed 22 Jul 2015 15:57:00 +0200 + -- The Debian Squid Maintainers , Tue, 23 Mar 2021 11:28:15 +0100 diff -Nru squid-4.13/deb
Bug#985390: unblock: squid/4.13-7
I'm Ccing my fellows at the squid team in case they want to add something here, for the full conversation, please see #985390. I have finished testing the changes for -9, I don't know if I like it more now or if it would be better to just leave the comment on the NEWS file and don't echo anything on the console when we purge. This is what it does now when we purge squid if we have squid-openssl installed: (A ler a base de datos ... 603757 files and directories currently installed.) Purging configuration files for squid (4.13-9) ... Log and cache files are not automatically removed. These files are used by squid and squid-openssl flavours. Remove logs (/var/log/squid) and cache (/var/spool/squid) yourself if you no longer need them. As you can see there is a lot of text but the user doesn't really need to see any of this as he has squid-ssl installed, so I could try to only echo if we don't have the other flavour installed, but... When we purge all of squid, in this case I'm purging squid-common and squid-openssl, no piece of squid remains installed... (A ler a base de datos ... 603757 files and directories currently installed.) Removing squid-openssl (4.13-9) ... Purging configuration files for squid-openssl (4.13-9) ... Log and cache files are not automatically removed. These files are used by squid and squid-openssl flavours. Remove logs (/var/log/squid) and cache (/var/spool/squid) yourself if you no longer need them. dpkg: warning: while removing squid-openssl, directory '/var/spool/squid' not em dpkg: warning: while removing squid-openssl, directory '/var/log/squid' not empt Removing squid-common (4.13-9) ... Processing triggers for man-db (2.9.4-2) ... As you can see, we get the text I wrote for -9 and also the dpkg warning. So... I'm thinking, what if we don't echo anything and let dpkg do its work, and leave the note I just added to NEWS and maybe add a README.Debian file explaining the flavours, how they share the cache, the logs and the config file and that we are not cleaning logs and cache, and even sugesting that to clean the cache a mkfs can be faster (like the comment on the postrm says)? What do you think, maybe that way is even cleaner for the user. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#985390: unblock: squid/4.13-7
Hi again! I have just pushed: https://salsa.debian.org/squid-team/squid/-/commit/fe8a10ef8ec40411bb59bec7af2b179796d4f4ef I think I'm addressing all your concerns there, if you like it I'll run tests tomorrow and upload the -9 package. Thanks in advance. -- Manty/BestiaTester -> http://manty.net
Bug#985390: unblock: squid/4.13-7
> > Fixing a couple of nasty bugs discovered late, > Yes, due to handling of a new binary package that you had migrated into > bullseye the day before that wasn't allowed anymore exactly to avoid > this class of bugs. Agreed, this was something that several users had asked for and that we, the screen team, agreed on making, but nobody had the time till I was able to do it, yes, it was late on the cycle, but I think we can get it right before releasing. > > Loss of config and logs and service deactivated when switching squid flavour > > and purging the old one. > And now you don't purge the configuration and logs at all. Policy isn't > totally clear on this (the text is lightly ambiguous), but *I* expect > purging to remove my configuration and logs, what else is the delta > between removal and purging? However, I'm wondering if I want you to fix The package has traditionally left, the cache (something that is probably not usefull at all) without being removed from the disk just because it would take a lot of time to remove it (reading the comments on postrm script) # We do not remove /var/spool/squid because that might # take a lot of time. Most of the time it is on a seperate # disk anyway and it is faster to do a mkfs on it.. I thought that leaving the logs which can be even legally needed, wouldn't hurt, in my case when I found this it was a problem as I lost all the logs I had on the system (luckily I had a backup). > that at this moment at the risk of not getting it right. However, I You are right. > think you're current message is confusing though and needs improvement: > 1) it doesn't mention the configuration file(s) The configuration file (which was forcebly removed by postrm before) is removed by dpkg if squid and squid-openssl are both purged, so as far as config goes, it still does what you would spect. > 2) it doesn't mention that the log is shared with that other > (potentially installed) package. There's context missing here for > sysadmins of why you're not doing it in the package. What happens if > somebody just did exactly as told and deleted the log directory? Agreed, I can try to get a better message on a -9 version of it. > -#DEBHELPER# > +# Automatically added by dh_installinit/13.3.4 > ^ > > Highly confusing, don't you think, for something that's not at all > automatically added. Sure, I didn't remove this to minimize the changes between the binary packages, and given that this was a temporary fix, I thougt it would be better to leave it like that, but I'll remove it on -9. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#985708: RM: autodns-dhcp -- ROM; Old package not working with current dhcp servers.
Package: ftp.debian.org Severity: normal I'm both maintainer and upstream for this package, I haven't developped or tested it for years, I'm possitive that it wouldn't work with current versions of isc dhcp server. Also, there are alternatives to it that should be better suited for the time being. So it should be removed from the distribution before we ship a non working piece of software with Bullseye. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#985390: Make this request valid for 4.13-8
Hi! While we were waiting for 4.13-7 to age and enter testing, we were filled a security bug for CVE-2020-25097. I decided to fix that security problem ASAP and that is what is on 4.13-8, just that. 4.13-8 just adds the patch to fix the CVE as available at: http://www.squid-cache.org/Versions/v4/changesets/SQUID-2020_11.patch You can see more info on all this on the bug that was assigned, #985068. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#985390: Clarifying changes on resulting binary packages
Hi! Just to clarify a bit, as the changes on the sources may seem big, these are the differences on resulting scripts (the only that was changed besides changelogs and a note on NEWS). >From -5 to -6: diff -ru 5/control/postrm 6/control/postrm --- 5/control/postrm2021-02-08 21:35:48.0 +0100 +++ 6/control/postrm2021-03-04 14:45:00.0 +0100 @@ -6,20 +6,12 @@ remove) ;; purge) - echo "Purging logfiles..." - rm -rf /var/log/squid - - if [ -f /etc/squid/squid.conf ]; then - echo "Removing the config-file .." - rm -f /etc/squid/squid.conf - fi - # # We do not remove /var/spool/squid because that might # take a lot of time. Most of the time it is on a seperate # disk anyway and it is faster to do a mkfs on it.. # - echo "Please, remove /var/spool/squid yourself." + echo "Please, remove logs (/var/log/squid) and cache (/var/spool/squid) yourself." ;; failed-upgrade|abort-upgrade|upgrade|abort-install|disappear) ;; And these are those from -6 to -7: diff -ru 6/control/postrm 7/control/postrm --- 6/control/postrm2021-03-04 14:45:00.0 +0100 +++ 7/control/postrm2021-03-10 09:19:32.0 +0100 @@ -21,7 +21,7 @@ # generated by other debhelper scripts. # Automatically added by dh_installinit/13.3.4 -if [ "$1" = "purge" ] ; then +if [ "$1" = "purge" ] && ! [ -e /etc/init.d/squid ]; then update-rc.d squid remove >/dev/null fi # End automatically added section @@ -42,7 +42,7 @@ fi fi -if [ "$1" = "purge" ]; then +if [ "$1" = "purge" ] && ! [ -e /lib/systemd/system/squid.service ]; then if [ -x "/usr/bin/deb-systemd-helper" ]; then deb-systemd-helper purge 'squid.service' >/dev/null || true deb-systemd-helper unmask 'squid.service' >/dev/null || true Hope that clarifies a bit. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#985390: unblock: squid/4.13-7
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package squid Current version on tesing has two bugs (#984510 and #984880) they both happen when purging squid after transitioning to squid-openssl or vice versa. The first one means loosing the config file and logs (which in the case of squid can even be proves for crimes), and the second one means the service is deactivated. The version in sid, uploaded before hard freeze and with autopkgtests has just the changes made to fix these two bugs. The first bug was addressed on -6 and all we did was not to remove logs and config files on postrm script. The second one is caused by #984897 on debhelper, but debhelper won't be updated this late on release cycle, so the fix I've implemented is not what I'd like, I've added modified debhelper scripts to postrm. [ Reason ] Fixing a couple of nasty bugs discovered late, so that we got hit by hard freeze and given that squid is a key package, it won't transition automatically despite the autopkgtests. [ Impact ] Loss of config and logs and service deactivated when switching squid flavour and purging the old one. [ Tests ] The changes are a removal of a couple of rm commands (added on -6 version) and a condition added to two "if" commands on debhelper's scripts so that if the service still exists it won't get deactivated. The tests were carried to see that they work as expected when transitioning from one flavour to the other and then purging the original one. [ Risks ] No risks at all with changes applied to -6 as removal of code and what is affected is trivial, changes done on -7 should be just a build depends on a newer version of debhelper that would fix #984897 but as that won't happen on Bullseye, I applied the results of fixing this debhelper bug directly on the code produced by debhelper instead of writing some new code, I know this is ugly but it was the option that seemed to pose less risks. [ Checklist ] [X] all changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in testing [ Other info ] All changes are on https://salsa.debian.org/squid-team/squid unblock squid/4.13-7 diff -Nru squid-4.13/debian/changelog squid-4.13/debian/changelog --- squid-4.13/debian/changelog 2021-02-08 21:35:48.0 +0100 +++ squid-4.13/debian/changelog 2021-03-10 09:19:32.0 +0100 @@ -1,3 +1,18 @@ +squid (4.13-7) unstable; urgency=medium + + * Add full postrm scripts while we don't solve #984897 on debhelper. +Closes: #984880. + + -- Santiago Garcia Mantinan Wed, 10 Mar 2021 09:19:32 +0100 + +squid (4.13-6) unstable; urgency=medium + + * Stop removing cache and config file on postrm. Closes: #984510. + * Increase debhelper build dependency to 12.8 as we need that from -5. + * Add NEWS note on the problem with purge on previous versions. + + -- Santiago Garcia Mantinan Thu, 04 Mar 2021 14:45:00 +0100 + squid (4.13-5) unstable; urgency=high * Have a deeper look and change all dpkg-buildpackage commands diff -Nru squid-4.13/debian/control squid-4.13/debian/control --- squid-4.13/debian/control 2021-02-07 21:58:30.0 +0100 +++ squid-4.13/debian/control 2021-03-08 22:32:47.0 +0100 @@ -11,7 +11,7 @@ # The compiler dependencies are relevant for backporting. , g++ (>= 4.9) | clang (>= 3.7) , gcc (>= 4.9) | clang (>= 3.7) - , debhelper (>=12), dpkg-dev (>= 1.17.11~), lsb-release + , debhelper (>=12.8), dpkg-dev (>= 1.17.11~), lsb-release , dh-apparmor , libcppunit-dev , libcap2-dev [linux-any] diff -Nru squid-4.13/debian/NEWS squid-4.13/debian/NEWS --- squid-4.13/debian/NEWS 2021-02-07 01:39:45.0 +0100 +++ squid-4.13/debian/NEWS 2021-03-08 22:32:47.0 +0100 @@ -1,3 +1,12 @@ +squid (4.13-6) unstable; urgency=medium + + If you want to transition from squid to squid-openssl or vice versa you + should first make sure you have at least version 4.13-6 of the packages + installed or don't purge your packages, as older packages will remove + logs and config file on purge. + + -- Santiago Garcia Mantinan Thu, 04 Mar 2021 15:36:44 +0100 + squid (4.13-2) unstable; urgency=high Starting from this release we ship the old squid package compiled against diff -Nru squid-4.13/debian/squid-openssl.postrm squid-4.13/debian/squid-openssl.postrm --- squid-4.13/debian/squid-openssl.postrm 2021-02-05 14:38:22.0 +0100 +++ squid-4.13/debian/squid-openssl.postrm 2021-03-10 09:17:36.0 +0100 @@ -6,20 +6,12 @@ remove) ;; purge) - echo "Purging logfiles..." - rm -rf /var/log/squid - - if [ -f /etc/squid/squid.conf ]; then - echo "Removing the config-file .." -
Bug#984897: Problems in a setup with two conflicting binary packages which share the same service name
Package: debhelper Version: 13.3.4 Severity: normal Tags: patch Recently we decided to ship two binary versions of squid, one compiled with gnutls and the other with openssl, as the code provides different features depending with what is compiled. I decided to produce two binary packages conflicting with each other, squid and squid-openssl but that provide the same service squid.service The problem comes when we purge one that is removed when the other is installed, I see the problem on the automatic added sections of the postrm script. I have filled a bug on squid explaining the problem (#984880) and tried to explain this here: https://lists.debian.org/debian-mentors/2021/03/msg00022.html The problem is with both dh_installinit and dh_installsystemd, I have prepared a patch based on the dh_apparmor's code which does have checks for this. I don't know debhelper's code, and even tough this patch works ok for me, the plural of #UNITFILES# makes me think that it can have several files on it wich would make my patch fail on this case, I hope the patch gives you the idea of what would be needed. Fixing this bug would be needed to fix bug #984880 on squid for Bullseye, I don't know if it is possible to have a fix for this on debhelper or if we should try to woraround this on squid's postrm script, I hope that you can have a look at this and let me know. Regards. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debhelper depends on: ii autotools-dev20180224.1+nmu1 ii dh-autoreconf20 ii dh-strip-nondeterminism 1.11.0-1 ii dpkg 1.20.7.1 ii dpkg-dev 1.20.7.1 ii dwz 0.13+20210201-1 ii file 1:5.39-3 ii libdebhelper-perl13.3.4 ii libdpkg-perl 1.20.7.1 ii man-db 2.9.4-2 ii perl 5.32.1-3 ii po-debconf 1.0.21+nmu1 debhelper recommends no packages. Versions of packages debhelper suggests: ii dh-make 2.202003 -- no debconf information diff --git a/autoscripts/postrm-init b/autoscripts/postrm-init index 1c292982..acd7dc76 100644 --- a/autoscripts/postrm-init +++ b/autoscripts/postrm-init @@ -1,3 +1,3 @@ -if [ "$1" = "purge" ] ; then +if [ "$1" = "purge" ] && ! [ -e "/etc/init.d/#SCRIPT#" ]; then update-rc.d #SCRIPT# remove >/dev/null fi diff --git a/autoscripts/postrm-systemd b/autoscripts/postrm-systemd index d95013b6..3850e016 100644 --- a/autoscripts/postrm-systemd +++ b/autoscripts/postrm-systemd @@ -4,7 +4,8 @@ if [ "$1" = "remove" ]; then fi fi -if [ "$1" = "purge" ]; then +UNITFILES=#UNITFILES# +if [ "$1" = "purge" ] && ! [ -e "/lib/systemd/system/$UNITFILES" ]; then if [ -x "/usr/bin/deb-systemd-helper" ]; then deb-systemd-helper purge #UNITFILES# >/dev/null || true deb-systemd-helper unmask #UNITFILES# >/dev/null || true
Bug#984880: Purging squid when squid-openssl is installed disables service
Package: squid Version: 4.13-6 Severity: normal Looks like we still have a problem, the postrm auto added hooks by debhelper are disabling the service when you purge squid and squid-openssl is installed. The problem lays here, but as I said, this is auto added code :-( if [ "$1" = "purge" ]; then if [ -x "/usr/bin/deb-systemd-helper" ]; then deb-systemd-helper purge 'squid.service' >/dev/null || true deb-systemd-helper unmask 'squid.service' >/dev/null || true fi fi Don't really know how to solve this in code right now, I'll have to think about it, I'm accepting ideas. Meanwhile, if you encounter this bug, just do: systemctl enable squid Regards. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages squid depends on: ii adduser 3.118 ii init-system-helpers 1.60 ii libc62.31-9 ii libcap2 1:2.44-1 ii libcom-err2 1.46.2-1 ii libcrypt11:4.4.17-1 ii libdb5.3 5.3.28+dfsg1-0.8 ii libdbi-perl 1.643-3+b1 ii libecap3 1.0.1-3.2+b1 ii libexpat12.2.10-2 ii libgcc-s110.2.1-6 ii libgnutls30 3.7.0-7 ii libgssapi-krb5-2 1.18.3-4 ii libkrb5-31.18.3-4 ii libldap-2.4-22.4.57+dfsg-2 ii libltdl7 2.4.6-15 ii libnetfilter-conntrack3 1.0.8-3 ii libnettle8 3.7-2.1 ii libnsl2 1.3.0-2 ii libpam0g 1.4.0-6 ii libsasl2-2 2.1.27+dfsg-2.1 ii libstdc++6 10.2.1-6 ii libsystemd0 247.3-2 ii libxml2 2.9.10+dfsg-6.3+b1 ii logrotate3.18.0-2 ii lsb-base 11.1.0 ii netbase 6.2 ii squid-common 4.13-6 Versions of packages squid recommends: ii ca-certificates 20210119 ii libcap2-bin 1:2.44-1 Versions of packages squid suggests: ii apparmor 2.13.6-9 pn resolvconf pn smbclient pn squid-cgi pn squid-purge pn squidclient pn ufw pn winbind -- no debconf information
Bug#984510: purging squid with squid-openssl installed removes files anyway
Hi! I'd like to receive comments on this one, I have already pushed a solution to salsa that involves not removing the files and noting that on the comment we echo on postrm so that it now tells you to remove both cache and logs. I have also explained on the NEWS file that you must have at least -6 version in order to be able to do a purge without loosing your logs and config. The config will get automatically removed when it must be (if you purge squid and squid-openssl) so it shouldn't be removed on postrm anyway, so that works as expected, also if cache and logs dirs are empty dpkg will remove them and echo a warning that he could not remove them if they aren't empty. Maybe we could do better and try to remove in case we don't have any of our packages left or similar, but I also thought that logs are important, police may ask via judges for logs or similar, so preserving them... is a good thing I believe. So... what do you guys think? Should we upload that as -6 or do you want to do it some other way? Regards... -- Manty/BestiaTester -> http://manty.net
Bug#984510: purging squid with squid-openssl installed removes files anyway
Package: squid Version: 4.13-5 Severity: serious File: /usr/sbin/squid Hi! Today I tried to move from squid to squid-nossl and clean up afterwards, it all went ok when I did the installation of squid-openssl, squid got removed and everything worked as expected, but when I purged squid with squid-openssl installed, squid postrm script did... # dpkg --purge squid (A ler a base de datos ... 605846 files and directories currently installed.) Purging configuration files for squid (4.13-5) ... Purging logfiles... Removing the config-file .. Please, remove /var/spool/squid yourself. Which means that it removed squid.conf and the log directory without asking anything, it is curious that it left the cache files around for me to remove, but removed all the usefull info I had around. The code in question is this: echo "Purging logfiles..." rm -rf /var/log/squid if [ -f /etc/squid/squid.conf ]; then echo "Removing the config-file .." rm -f /etc/squid/squid.conf fi The problem here is... how to we deal with this? Regards... -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages squid-openssl depends on: ii adduser 3.118 ii init-system-helpers 1.60 ii libc62.31-9 ii libcap2 1:2.44-1 ii libcom-err2 1.46.2-1 ii libcrypt11:4.4.17-1 ii libdb5.3 5.3.28+dfsg1-0.8 ii libdbi-perl 1.643-3+b1 ii libecap3 1.0.1-3.2+b1 ii libexpat12.2.10-2 ii libgcc-s110.2.1-6 ii libgssapi-krb5-2 1.18.3-4 ii libkrb5-31.18.3-4 ii libldap-2.4-22.4.57+dfsg-2 ii libltdl7 2.4.6-15 ii libnetfilter-conntrack3 1.0.8-3 ii libnettle8 3.7-2.1 ii libnsl2 1.3.0-2 ii libpam0g 1.4.0-6 ii libsasl2-2 2.1.27+dfsg-2.1 ii libssl1.11.1.1j-1 ii libstdc++6 10.2.1-6 ii libsystemd0 247.3-1 ii libxml2 2.9.10+dfsg-6.3+b1 ii logrotate3.18.0-2 ii lsb-base 11.1.0 ii netbase 6.2 ii squid-common 4.13-5 Versions of packages squid-openssl recommends: ii ca-certificates 20210119 ii libcap2-bin 1:2.44-1 Versions of packages squid-openssl suggests: ii apparmor 2.13.6-9 pn resolvconf pn smbclient pn squid-cgi pn squid-purge pn squidclient pn ufw pn winbind -- Configuration Files: /etc/squid/squid.conf [Errno 2] Non hai tal ficheiro ou directorio: '/etc/squid/squid.conf' -- no debconf information
Bug#868220: Bug#979963: bridge-utils: bridge often collapses when removing USB WiFi dongle
> Looking at the debdiff, I notice that upstream considers this package > as deprecated and recommends using the 'bridge' command from iproute2. > Is there any plan to migrate bridge-utils-interfaces to use this? Well, kind of, I mean, on some of the bugs, at least on #868220, we've have talked about this. And given that upstream has been inactive for years... we have talked about getting the bridge setup scripts on ifupdown and leave bridge-utils with just the brctl tool. I'm crossposting and adding Guus to the mail to see if we can agree on something here, I don't think it is now the time to do it, it would be for post Bullseye, but I don't have any problem in rewriting the scripts to use just iproute2 and maintain those scripts under ifupdown so that Guus didn't have to take care of more stuff. Guus, what do you think? Regards. -- Manty/BestiaTester -> http://manty.net
Bug#979963: bridge-utils: bridge often collapses when removing USB WiFi dongle
> Noted. There's indeed too many patches for me to keep track of. At > some point, I lose track of what you need to validate each one. Well, after some more testing I uploaded the latest versions to unstable, so you don't need to access salsa as unstable is now in sync with the git repository. I've closed a lot of your bugs with the 1.6-6 release now in unstable and I hope it can make it to Bullseye, but I've left this open as it is too generic for me to know if all this is fixed with all the lot of patches we've put into the code. I'd like you to test -6 version and let me know if we can close this bug. Thanks. -- Manty/BestiaTester -> http://manty.net
Bug#979963: bridge-utils: bridge often collapses when removing USB WiFi dongle
> Like I have just said on the other bug report (looks like we have the same > setup on both bugs) I need to know how the system looks after the setup to > find what is wrong or different to mine here, "ip a" output would solve some > of my doubts. I don't know if you could test all the patches I sent you on your setup, in case you got lost with all the mails and patches, I have now uploaded everything to salsa at: https://salsa.debian.org/manty/bridge-utils where you can download what I hope will end up in a release. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#980507: How to get STP and IPv6
Hi again, Sam! > I suggest you do more testing whenever you can reach the equipment doing a > tcpdump of the traffic so that we know where the problem is, also, take a > look to the firewalling you have just in case igmp or other traffic is being > cut somewhere. I have recently uploaded bridge-utils to salsa at https://salsa.debian.org/manty/bridge-utils There I have a lot of patches, I hope some of them, including the last commit, which I don't know if it will make it to Bullseye, will help you solve the problems you had with IPv6 before, at least they solve some DAD problems and some other IPv6 things. I'm not sure the last commit fits for release at this time of freeze, I hope so, as it really makes static IPv6 work ok. If you happen to be able to do more tests I'd appreciate if you could test this changes. I'll appreciate your comments on all this anyway. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#981253: actually, make that: document minimum and maximum values of all options
> Document the minimum and maximum values of all options, and tell which > value is the strongest for each. This will take a lot of time, and I don't know if this is worth the effort. I'm going to try to go over all of this, as it seems that documentation is wrong, the kernel guys have changed things around and doc doesn't match kernel, for example, you asked for portprio... I had to read the kernel code to know what was happening, right now as of 5.10 this would be... br_stp_if.c:#define BR_MAX_PORT_PRIORITY ((u16)~0 >> BR_PORT_BITS) br_private.h:#define BR_PORT_BITS 10 This means that it is set to an unsigned int of 16 bits which is the complent of 0, which means it is in binary or in hexa, shifted right 10 bits, which makes it 11 or 63 in decimal, so... right now the values go from 0 to 63. It looks like by default... p->priority = 0x8000 >> BR_PORT_BITS; which would be... 0x20 or 32 in decimal. And testing shows lower is higher priority. I'll try to gather info for all this, but looks like it will be time consuming and that the kernel guys may change it again :-( Regards... -- Manty/BestiaTester -> http://manty.net
Bug#980856: bridge-utils: ignores bridge_hw
> We wouldn't need hwaddress anymore with the new patch, right? Nope, I have found another problem with the kind of setup that you have, on this setups brctl addif fails because the interface needs to be configured by hostapd, and as the code for setting the mac was conditionally tight to the brctl it would not be executed. I have moved it before the brctl addif so that it will be executed no matter what. This is on a patch attached to this bug. That should hopefully solve the final problem with mac setting. > iface br0 inet dhcp > bridge_hw enp4s0MAC > bridge_ports regex (en|wl).* > post-up ifup /wl* > iface br0 inet6 auto > privext 2 > > iface enp3s0 inet manual > iface enp4s0 inet manual these two iface enp* lines shouldn't be needed at all, the regex on bridge ports should catch them and bridge-utils should configure the ports. Like I said before I'd add the bridge_ports to the inet6 definition as well, the full patch to fix this two definitions will need that info for everything to run ok. If you can add the attached patch and test everything it would be great. Regards... -- Manty/BestiaTester -> http://manty.net --- /lib/udev/bridge-network-interface~ 2021-02-16 13:01:37.0 +0100 +++ /lib/udev/bridge-network-interface 2021-02-21 00:24:11.936523677 +0100 @@ -31,10 +31,10 @@ if [ -d /sys/class/net/$port ]; then ifup --allow auto $i if [ -f /proc/sys/net/ipv6/conf/$port/disable_ipv6 ]; then echo 1 > /proc/sys/net/ipv6/conf/$port/disable_ipv6;fi - brctl addif $i $port && ip link set dev $port up && if [ "$(ifquery "$i"|sed -n -e's/^bridge[_-]hw: //p')" = "$port" ]; then ip link set dev "$i" address "$(ip link show dev "$port" 2>/dev/null|sed -n "s|.*link/ether \([^ ]*\) brd.*|\1|p")" fi + brctl addif $i $port && ip link set dev $port up fi break ;;
Bug#980856: bridge-utils: ignores bridge_hw
> > auto br0 > > iface br0 inet dhcp > > hwaddress enp4s0mac > > bridge_hw enp4s0mac > > bridge_ports regex (en|wl).* > That would fail to raise enp4s0, and it also still has hwaddress. I Wel... isn't enp4s0mac a fixed ethernet port? if it is it should be available on booting, so when booting and the br0 is brought up (auto br0) and then enp4s0mac is added to it, or at least it should be. > also still need this: > iface br0 inet6 auto > privext 2 Ok, if you maintain that second config for inet6 I suggest you add also the bridge_ports expression to it then, I have a full patch that will allow this to work, it is the one on #319832, I don't think we can make that on Bullseye. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#980752: Patch for testing
On Feb 18 2021, Martin-Éric Racine wrote: > This indeed prevents the superfluous fe80 address from appearing when > the dongle is plugged in after the bridge is already up. It doesn't > seem to affect traffic connecting via the dongle either. I don't get this last sentence, I'm guessing you mean that the patch works Ok and it doesn't cause any trouble, is that it? If we are solving something with this patch, can you tell me which of the bugs we are addressing with you can be closed when we'll apply this patch and the other suggestions I made to you? Regards... -- Manty/BestiaTester -> http://manty.net
Bug#980856: bridge-utils: ignores bridge_hw
> > > Btw, the discrepancy in behavior explained in Bug#980752 remains. With > > The problem is with neither, I believe. > Oh? What would cause this then? Like I have explained to you in other bugs, I could replicate the problem and found that it was a problem with bridge-utils, I have assigned #980752 to bridge-utils and added a patch to fix that on the bug report. > Yes, they all have bridge=br0 in their config. Ok, I've been looking at your interfaces and I have some sugestions to make, removal of hwaddress statements, leave just the bridge_hw ones, remove all the ipv6 statements if they don't provide real meaning and I would extend this to any other stuff you have written. I would leave it like this: allow-hotplug wlxdongle1mac wlxdongle2mac wlxdongle3mac wlxdongle4mac wlxdongle5mac auto br0 iface br0 inet dhcp hwaddress enp4s0mac bridge_hw enp4s0mac bridge_ports regex (en|wl).* iface wlxdongle1mac inet manual hostapd /etc/hostapd/hostapd-wlxdongle1mac.conf iface wlxdongle2mac inet manual hostapd /etc/hostapd/hostapd-wlxdongle2mac.conf iface wlxdongle3mac inet manual hostapd /etc/hostapd/hostapd-wlxdongle3mac.conf iface wlxdongle4mac inet manual hostapd /etc/hostapd/hostapd-wlxdongle4mac.conf iface wlxdongle5mac inet manual hostapd /etc/hostapd/hostapd-wlxdongle5mac.conf I have tested this after applying the patch I sent to bug #980752 with a new dongle I have just bought and seems to work ok with a similar configuration. Can you please apply the patch on #980752 to your system and modify the configuration like I suggest and let me know how things go? Regards. -- Manty/BestiaTester -> http://manty.net
Bug#982943: Code for waiting for the bridge to be ready is broken
Package: bridge-utils Version: 1.5-10 Severity: important Tags: patch Hi! When we tried to fix bug #779348 what we did was broke the code. The since version 1.5-10 reads... unset BREADY unset TRANSITIONED COUNT=0 # Use 0.1 delay if available sleep 0.1 2>/dev/null && MAXWAIT=$((MAXWAIT * 10)) while [ -n "$BREADY" -a $COUNT -lt $MAXWAIT ] do WAIT AND OTHER STUFF done As BREADY is unset (bridge is not ready) it is empty and thus it won't enter the while, so it won't wait for the bridge to be ready. Whis results in a failure to set up the interface if we use IPv6 on it. Maybe this is what is happening on #980507: # time ifup br0 Waiting for br0 to get ready (MAXWAIT is 22 seconds). Waiting for br0 to get ready (MAXWAIT is 22 seconds). Waiting for DAD... Timed out ifup: failed to bring up br0 real0m8,045s The time expent waiting was all done at the DAD, the waiting for br0 didn't take any time as it didn't get to the while loop. The configuration used for testing this was: auto br0 iface br0 inet static bridge_ports eth0 wlan0 bridge_stp on bridge_fd 10 bridge_hw wlan0 address 192.168.X.X netmask 255.255.255.0 iface br0 inet6 static bridge_ports eth0 wlan0 address 2001:::::1 netmask 64 While, if we invert the logic of the -n of the while loop to a ! like it was before, like this: --- /lib/bridge-utils/ifupdown.sh~ 2021-01-22 11:06:45.0 +0100 +++ /lib/bridge-utils/ifupdown.sh 2021-02-17 03:41:50.114247593 +0100 @@ -203,7 +203,7 @@ # Use 0.1 delay if available sleep 0.1 2>/dev/null && MAXWAIT=$((MAXWAIT * 10)) -while [ -n "$BREADY" -a $COUNT -lt $MAXWAIT ] +while [ ! "$BREADY" -a $COUNT -lt $MAXWAIT ] do sleep 0.1 2>/dev/null || sleep 1 COUNT=$(($COUNT+1)) We get it to work and the while loop takes what it needs to get the bridge forwarding: # time ifup br0 Waiting for br0 to get ready (MAXWAIT is 22 seconds). Waiting for br0 to get ready (MAXWAIT is 6 seconds). Waiting for DAD... Done real0m16,723s user0m0,891s sys 0m1,261s If people finds that it takes always MAXWAIT seconds it is because there is no other bridge speaking STP on the net or our bridge will be the Root of the topology. If that is not the case, like in this example, where the neighbour has a FD of 2, the timing will be shorter and if one wants to make it shorter he can always play with bridge_fd I don't recommend to lower it under 2 anyway. So, the code was ok like it was before and we should try to get this fix in Bullseye. I have a better fix for this which also addresses bug #319832, I've posted it there, it addresses the two "Waiting for br0..." messages, now it is only shown once, and solves the ifdown errors that you get with current implementation, but maybe that's too late for Bullseye. Regards. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bridge-utils depends on: ii libc6 2.31-9 bridge-utils recommends no packages. Versions of packages bridge-utils suggests: ii ifupdown 0.8.36 -- Configuration Files: /etc/default/bridge-utils changed [not included] -- no debconf information
Bug#319832: A patch to solve this.
Hi! It's been a long time since this bug entered the system, and now I have a patch for it, I have to say it is a little dirty (I'm just adding the bridge back on the stances that had it removed before them) so that way they won't fail when trying to remove it. This will work if you do: ln -s /lib/bridge-utils/ifupdown.sh /etc/network/if-down.d/bridge and apply the attached patch. I'd love to see comments on this, even though more than 15 years later... well who knows. Whis patch is a little big, so I don't know if it will make it to Bullseye at this time of the freeze :-( so all the testing will be welcome and will of course help get it on Bullseye. Regards -- Manty/BestiaTester -> http://manty.net --- ifupdown.sh.orig2021-02-17 03:53:52.414027536 +0100 +++ ifupdown.sh 2021-02-17 03:51:29.029521766 +0100 @@ -67,7 +67,11 @@ fi # Previous work (stop the interface) elif [ "$MODE" = "stop" ]; then + if [ "$PHASE" = "pre-down" ]; then +[ ! -d /sys/class/net/$IFACE ] && brctl addbr $IFACE && ip address add "$IF_ADDRESS"/"$IF_NETMASK" dev $IFACE + elif [ "$PHASE" = "post-down" ]; then ip link set dev $IFACE down || exit 1 + fi fi all_interfaces= && @@ -100,7 +104,7 @@ fi brctl addif $IFACE $port && ip link set dev $port up # We detach each port of the bridge -elif [ "$MODE" = "stop" ] && [ -d /sys/class/net/$IFACE/brif/$port ]; then +elif [ "$MODE" = "stop" -a "$PHASE" = "post-down" ] && [ -d /sys/class/net/$IFACE/brif/$port ]; then ip link set dev $port down && brctl delif $IFACE $port && destroy_vlan_port if [ -f /proc/sys/net/ipv6/conf/$port/disable_ipv6 ] then @@ -194,16 +198,15 @@ # Wait for the bridge to be ready if [ "$MAXWAIT" != 0 ] then -/bin/echo -e "\nWaiting for $IFACE to get ready (MAXWAIT is $MAXWAIT seconds)." - unset BREADY unset TRANSITIONED COUNT=0 +MMAXWAIT=$MAXWAIT # Use 0.1 delay if available -sleep 0.1 2>/dev/null && MAXWAIT=$((MAXWAIT * 10)) +sleep 0.1 2>/dev/null && MMAXWAIT=$((MAXWAIT * 10)) -while [ -n "$BREADY" -a $COUNT -lt $MAXWAIT ] +while [ ! "$BREADY" -a $COUNT -lt $MMAXWAIT ] do sleep 0.1 2>/dev/null || sleep 1 COUNT=$(($COUNT+1)) @@ -219,12 +222,15 @@ unset BREADY fi done + if [ -z "$BREADY" -a $COUNT = 1 ] + then +/bin/echo -e "\nWaiting for $IFACE to get ready (MAXWAIT is $MAXWAIT seconds)." + fi done - fi # Finally we destroy the interface -elif [ "$MODE" = "stop" ]; then +elif [ "$MODE" = "stop" -a "$PHASE" = "post-down" ]; then brctl delbr $IFACE
Bug#980507: Problems with your fix for Debian bridge-utils bug 779348
Hi! I'm crossposting this to another bug because maybe the previous bug fix is the one that is making the new bug fail. Alexander, I hope you are still around so we can talk about this bug you had sent. I just came over to this bug but with the reverse feeling, after your patch now the code doesn't wait at all. You can go to https://bugs.debian.org/779348 in order to see what you had sent, with your change the code goes... unset BREADY unset TRANSITIONED COUNT=0 # Use 0.1 delay if available sleep 0.1 2>/dev/null && MAXWAIT=$((MAXWAIT * 10)) while [ -n "$BREADY" -a $COUNT -lt $MAXWAIT ] do WAIT AND OTHER STUFF done So, as we've unset BREADY, then BREADY is empty, so -n "$BREADY" will be false and thus we wont go in the wait loop and thus it will exit without the bridge being ready. So... for me the code was Ok, now... what I'm asking myself is how have we gone this far with this bug we introduced without anybody complaining. I just came to it after setting STP and IPv6, then DAD failed and I went looking for the bug. So... I'm about to reverse this patch you sent me but... I'd like to know what was wrong in the first place, that is, when you sent me the patch. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#979963: Addressing the IPv6 thing
Hi! While I'm still waiting for you "ip a" output to continue debugging this, I'd like to to test the one line patch which I'm going to add on next version, this should solve the hotplugged interfaces getting an IPv6 address like you explained here and also on #980752 which I have now reassigned to bridge-utils, I've sent the patch to that bug not to mix more stuff here, but yo were saying... > What I DO notice is that because the bridge is stupid enough to use the > MAC address of a removable device to build the EUI64 address for fe80 > local link (despite bridge_hw specifying the MAC address of a fixed > device), disconnecting that removable device collapses the bridge. I'd like you to test with the patch to see if this is still like you describe it and then send me the output of "ip a" explaining how it behaves now. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#980752: Patch for testing
Hi! I have now assigned this bug to bridge-utils and I've got this patch that should solve it, can you test it on your machine and let me know if it fixes the problem? --- /lib/udev/bridge-network-interface~ 2021-02-16 20:59:36.397579972 +0100 +++ /lib/udev/bridge-network-interface 2021-02-16 20:59:45.777222821 +0100 @@ -30,6 +30,7 @@ create_vlan_port if [ -d /sys/class/net/$port ]; then ifup --allow auto $i + if [ -f /proc/sys/net/ipv6/conf/$port/disable_ipv6 ]; then echo 1 > /proc/sys/net/ipv6/conf/$port/disable_ipv6;fi brctl addif $i $port && ip link set dev $port up && if [ "$(ifquery "$i"|sed -n -e's/^bridge[_-]hw: //p')" = "$port" ]; then ip link set dev "$i" address "$(ip link show dev "$port" 2>/dev/null|sed -n "s|.*link/ether \([^ ]*\) brd.*|\1|p")" Regards. -- Manty/BestiaTester -> http://manty.net
Bug#765098: Proposed example for NetworkManager
Hi! I've installed a machine with NetworkManager, so I could do tests with this, I have arrived to an example that does what I think you wanted. The example would be this: auto lo iface lo inet loopback iface enp2s0 inet manual auto br0 iface br0 inet dhcp bridge_ports all bridge_fd 2 bridge_hw enp2s0 This way NetworkManager doesn't configure enp2s0 and ifupdown uses it on br0 without any interference. What do you think? Regards... -- Manty/BestiaTester -> http://manty.net
Bug#966395: Double building?
> > My current guess looking at things around the package is that it is ok on my > > build to have it in etc/squid, plus is a good place for a config file, so... > > everything looks ok. > > Yes. It is supposed to be a config file to tell Squid where to load static > web content from (based on FTP mime type). I know about its usage, but I don't know why we ship it on /usr, I saw later that we had patch 0002 in order to do that, that patch was no longer working as the package now does an autoreconf and thus I needed to rework this on order to leave it like it was before, but I still don't know why it is on /usr. I'll push my last changes as soon as I fix a couple of lintian warnings. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#966395: Double building?
> On current build we ship usr/share/squid/mime.conf on squid-common, but on > my build it gets installed on etc/squid/mime.conf, which place is the right > one? My current guess looking at things around the package is that it is ok on my build to have it in etc/squid, plus is a good place for a config file, so... everything looks ok. I'm doing a last build and I'll run some tests with it tomorrow. I'll try to push my changes to git now in case anybody has the time to play with it, but it looks like everybody is out of time currently. I've been busy lately so I couldn't take care of this, now we are in a hurry if we want this for Bullseye, if we are not already too late :-( If nobody objects and I see it fine on my tests tomorrow I'll write about this to -release and push it to unstable. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#966395: Double building?
Hi! > There is also the GnuTLS ability to load multiple certificates for > virtual-hosting HTTPS websites which OpenSSL simply cannot do itself. I > know a few users are liking that. I'm trying to make a double building like you suggested, but I don't think we'll make it in time for Bullseye. When changing the build rules I find some weird things like: On current build we ship usr/share/squid/mime.conf on squid-common, but on my build it gets installed on etc/squid/mime.conf, which place is the right one? Regards.
Bug#980507: How to get STP and IPv6
> To clarify one thing about my setup before someone points out it could > cause problems. > I talk about a wifi router. Note that I'm using an ethernet port on the > wifi router, so I have no wifi bridging involved. Well, exept for the part on my setup being free soft that I can play with... your setup is not that much different from the one on my workstation, with a bridge (of two cards, but usually just one plugged) going to my server wich runs a bridge over wifi and copper, but I'm going through copper anyway. > Also, you may have something in all of that acting as an IGMP querier. > It's certainly complicated enough that I wouldn't know how to go about > isolating differences between it and something that doesn't work. Nope, I don't have any querier unless Linux does that by default. Anyway, I tried to build a more complicated setup just in case the problem was going through a bridge or things like that, in fact, I have now gone to the normal setup of just the server and the workstation. > Admittedly that's probably Linux under the covers, and it's probably > bridging the wifi to the ethernet ports, but in debugging this sort of > thing I tend to find a big difference between equipment under one's > control and equipment not under one's control. Yes, that is true, so... we can only tcpdump one of the sides :-( I suggest you do more testing whenever you can reach the equipment doing a tcpdump of the traffic so that we know where the problem is, also, take a look to the firewalling you have just in case igmp or other traffic is being cut somewhere. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#980856: bridge-utils: ignores bridge_hw
> Was there any particular reason for not enabling hotplug out of the box? This was like that to preserve things working like they used to (some years ago, when we introduced hotplug) > Btw, the discrepancy in behavior explained in Bug#980752 remains. With > BRIDGE_HOTPLUG=yes, upon startup, the WiFI dongles are brought up > after the fixed interfaces and they don't have any IPv6 EUI64 local > link (fe80) separate from the one on the bridge. However, if they are > plugged in after the bridge is already up, fe80 addresses are > generated for each of the dongles. As a user, I wouldn't know which > one of ifupdown or bridge-utils is at cause. The problem is with neither, I believe. When I saw your setup I learned about hostap ifupdown interfaces option, I didn't knew about it. I'm trying to make a setup that works like you and I think I may have some clues on this, and things point to hostap package and its ifupdown thing, but before extracting something out of my tests I need to know, your hostapd.conf for all those cards, they all have a bridge=br0 line on them? Thanks. -- Manty/BestiaTester -> http://manty.net
Bug#980507: How to get STP and IPv6
> 1) eno1 is connected directly to a wifi router. > I get an IPv6 address using router advertizements. > > But if I insteade slave that interface to a bridge say > iface brint inet dhcp > bridge-ports eno1 > auto brint > > then I don't get a global v6 address on the bridge. Well, this is kind of weird as the setup I commented I have here is much more complicated than that and it is working, I'm getting the ipv6 from my server which runs radvd on all the machines across, the dummy switch, to the workstation which has a bridge like the one you describe and also across that one to the laptop, and also across the laptop to the wifi. So... I don't really get the problem here. Looking at my setup I found that I had an old bridge_fd 2 that I was using in the past when I used to run stp as I had a loop in the net, but even when I commented this out, making the interfaces take long time to go forwarding, I algo got the global v6 address. Don't know what else to say except that my switch is a dummy switch which I suppose is flooding, and yours may be doing real stuff with igmp and all that, so I'd have a look at that. If you can come to any conclusion that we should add to the doc, please just let me know. Also, like I said before, if you see that the doc needs some changes on wording or whatever I'm open to it, no problem. > It seems very implausible to me that's STP, although I haven't tested > that. > > Apparently by default the kernel turns on IGMP snooping on the bridge. > There is no querier on the network in question, so it's plausible that > IGMP snooping could get in the way. > Although I'd kind of expect that all-nodes and all-routers would get > flooded all the time anyway. > I can't remember which groups are involved in v6 RAs. I don't have any querier, only Linux devices and no extra soft wround other than radvd and the kernel, like I said... it is not posible for me to elavorate any more. IGMP sounds a good starting point for your problem, I'd give that a look, and tcpdump on both sides (router asigning and client receiving). Regards... -- Manty/BestiaTester -> http://manty.net
Bug#979963: bridge-utils: bridge often collapses when removing USB WiFi dongle
> I HAVE set bridge_hw to a static device. That's what I described. Like I have just said on the other bug report (looks like we have the same setup on both bugs) I need to know how the system looks after the setup to find what is wrong or different to mine here, "ip a" output would solve some of my doubts. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#980856: bridge-utils: ignores bridge_hw
> > What I need to be able to replicate this is more info on your setup, I mean, > > I need your network/interfaces (you can change macs and IPs of course) and > > the "ip a" output with everything plugged and up like you have it setup and > > then the same but without hwaddress applied (I'm supposing here that you > > don't need hwaddress if bridge_hw works ok). > > Anonymized and attached. You didn't send the "ip a" output on your setup, please send it to me making sure the data matches that of the attached network setup. I've partially tested a setup based on yours and I see no problem. BTW: one thing I do on this kind of hotplug setup is allow hotplug on bridge-utils, which means setting it to yes on /etc/default/bridge-utils This allows me to plug in and out ethernet devices without needing to declare them or anything, I know this doesn't work for wifi devices, which need hostapd. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#980507: How to get STP and IPv6
Hi! > Here's what I've found so far. > https://askubuntu.com/questions/460405/ipv6-does-not-work-over-bridge Ok, I see the problem the guy has but I don't get a clear setup definition, also that was a long long time ago. > This answer suggests that it's IGMP snooping *not* STP that is the > problem. The problem we used to have was a behaviour of the kernel. Because of this bug and other bugs I have setup IPv6 all over my network at home, so right now I have... Laptop workstation server - router Where the laptop has a wifi card bridged to the ethernet that connects to one of the ethernets of the workstation (without stp) The which runs a bridge between its two ethernets with stp on and that bridges the laptop to the server network. Server is a Pi3 which also has a bridge with the wifi and a ethernet card and then another ethernet routing this bridged net to the internet. The server is stablishing a tunnel to HE ipv6 network over the router's net and then maps the /64 net that HE assigns to the local network, i.e. it's wifi+ethernet bridge which then goes to a switch and from there to the workstation and the laptop. All of these machines can communicate perfectly over the link-local network and also to the internet using IPv6. So... as far as my tests go... what this bug needs and also looks like some other bugs are pointing in this direction is... Changing the documentation. If there is a setup that is not working with current tooling we can discuss it, but if not... please stick to the documentation part, which seems to be causing panic and/or trouble. So... we have the NEWS that I have written lately, which seems to alarm people, I don't know if by current policy we can change what is written, but I don't see any problem with that if we can make this text look clearer and less frightening. Then we have the bridge-utils-interfaces wich documents old bugs and also seems to frighten people when they read the bridge_hw option, maybe I should remove all that and just state that everything works ok and that this option is a must if MAC address means something for your network, then maybe pointing to the old bugs for further reading, or even not? An then we have the README.Debian which maybe needs some more stuff added. Maybe we can agree if this is all that is needed and some native English speaker can write up the changes for me to implement? If there is some problem with a setup that is not working... can we open a bug reflecting the setup? I guess that's all on my side, you guys have filed a lot of bugs lately, just before the freeze, and that is not a good timing at all, let's see if we can agree on what is needed and make it into shape and time for Bullseye. Thanks for the reports, regards... -- Manty/BestiaTester -> http://manty.net
Bug#980856: bridge-utils: ignores bridge_hw
> On a host with a mixture of USB WiFi dongles and Ethernet cards, I have to > specify the MAC address using both bridge_hw and ifup's generic hwaddress > to ensure that the host fetches the correct IP address via DHCP. > Nonetheless, the bridge picks up the IPv6 EUI64 local link (fe80) of one > of the USB WiFi dongles. When I need to remove the dongle, it makes the > bridge collapse. Well, we are talking about this also on #979963, but anyway, what you are descriving here is a different thing, as you are telling me that bridge_hw is being ignored and that you are using also hwaddress. What I need to be able to replicate this is more info on your setup, I mean, I need your network/interfaces (you can change macs and IPs of course) and the "ip a" output with everything plugged and up like you have it setup and then the same but without hwaddress applied (I'm supposing here that you don't need hwaddress if bridge_hw works ok). If you change macs or IPs, please make it consistant in the sense that MAC X is always MAC X and you don't leave it unchanged on the IPv6 or somewhere else, and the same with the IPs. I want to get the same feeling as you get there to try to replicate that here. > See also: Bug#980752. I have looked at it and I don't like some of the things I read... You say: If the WiFi dongles are declared on the allow-hotplug line I have said this on the doc and also on other bugs, please, don't put the interfaces of the bridge on their own entries on network/interfaces, instead, if you need something set up for the bridge, please use the bridge's declaration, like for example... pre-up service hostapd start || true post-down service hostapd stop || true in your case you'll be starting hostapd by hand, well, do it there, on a pre-up and kill them on post-down. Please provide the info I asked for, if you can, try to adapt your setup to what I have explained and we'll try to arrive somewhere with all this. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#979963: bridge-utils: bridge often collapses when removing USB WiFi dongle
Hi again! > What I DO notice is that because the bridge is stupid enough to use the > MAC address of a removable device to build the EUI64 address for fe80 > local link (despite bridge_hw specifying the MAC address of a fixed > device), disconnecting that removable device collapses the bridge. I've just done an IPv6 setup just to be able to debug the problems that I've been reported on bridge-utils, so let's see what I have... 1: lo: ... 2: eth0: mtu 1500 qdisc mq master br0 state UP group default qlen 1000 link/ether 00:23:88:7c:cd:11 brd ff:ff:ff:ff:ff:ff 3: wlan0: mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000 link/ether 00:ea:cd:26:fc:e4 brd ff:ff:ff:ff:ff:ff 4: br0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:ea:cd:26:fc:e4 brd ff:ff:ff:ff:ff:ff inet 192.168.1.222/24 brd 192.168.1.255 scope global br0 valid_lft forever preferred_lft forever inet6 2001:X:X:X:2ea:cdff:fe26:fce4/64 scope global dynamic mngtmpaddr valid_lft 85748sec preferred_lft 13748sec inet6 fe80::2ea:cdff:fe26:fce4/64 scope link valid_lft forever preferred_lft forever You can see here that I'm using the MAC address from the wlan0 on the bridge instead of the address of the ethernet which is lower and which in older kernels would be automatically assigned to it, on current (5.10) kernel the MAC address of the bridge would be completelly made up (like it was reported on #980505), but that's not the case because I'm using the new overloadinf of bridge_hw we did for #966244 available since bridge-utils 1.6-5, I have specified "bridge_hw wlan0". Getting back to your problem... if you have a device that is not hot pluggable on the bridge, I'd set up bridge_hw to that device, that way you won't get any MAC or any IPv6 address from the hotplugged devices, like you can see on my example, the only place where the mac of the ethernet MAC is used is on the ethernet MAC address, the rest is taken from wlan0's MAC. I'd suggest you try this, but I don't think it will make any difference. I mean try it, but I believe the problem is not related to the addresses or anything related to the networking code but to the driver doing weird things when the card is unplugged and not what it should, and that is causing the problems. I have at work and at home usb network cards and never had any problem like the one you are experiencing here, I'm not plugging them in and out all the time, but I do it from time to time and I've had no problems at all, that's why I think the driver may be the difference here. Try the bridge_hw thing set to the static device and let me know how it went. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#765098: bridge-utils: examples missing
Hi! I'm rereading this and I still don't know what kind of example are you asking for, let's see... > "# The primary network interface > allow-hotplug eth0 > #iface eth0 inet dhcp > iface eth0 inet manual > > auto br0 > iface br0 inet dhcp > bridge_ports eth0 This is a problem, it shouldn't be like that, if you are using eth0 on your bridge it shouldn't have its own section there. The README.Debian file says: If you are configuring the bridges this way you mustn't include the interfaces you use as bridge ports on your /etc/network/interfaces configuration, bridge-utils will take care of configuring the ports for you if needed, bridge-utils won't touch the ports config at all if not needed, if you need to set something up do it using a pre-up option on the bridge interface definition. So... that part shouldn't be part of an example ever, but... > Here if NM is installed, and there's a bridge that needs eth0 (eth0 is not > listed/defined in interfaces with "iface eth0 .."), then it's possible NM > might try to use it. I read here that the problem you are trying to fix with the example is NetworkManager trying to use the eth0 interface, well, I'm not a NetworkManager user, so I wouldn't know how to achieve this :-( I think NetworkManager should state clearly how to mark interfaces so that it doesn't mess with them, but if anybody tells me clearly what I should add to our doc at bridge-utils, I don't have any problem with that. Please note that there is not only NetworkManager but connman (which clearly has NetworkInterfaceBlacklist (setting it to br,eth would probably help with this), we also have wicd, ... so, if I have to add examples for every network manager around... it will be hard for me. > If I recall this package previously had examples that were particularly > helpful and I'm not sure where they went so can someone re-add them back ? > :) I don't remember having any examples removed, and I don't remember anything related to NetworkManager around, like I said, I don't have any problem with adding things to clarify usage, but I need the info as I don't use those products. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#966244: bridge-utils: add bridge_via to specify device for default route
> > iface br0 inet dhcp > > bridge_ports all > > bridge_hw enp6s0 > > This would obviously change the syntax of bridge_hw but it would > accomplish what we need with a syntax that follows the Consistent > Network Device Naming idea. I think I didn't express myself well, I don't mean to change the syntax but to overload it a bit, you could specify: bridge_hw enp6s0 or bridge_hw 00:11:22:33:44:55 whatever you prefer. Is this ok to you? or will it confuse people? I'll try to explain the two usages on the doc and the news if we implement this. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#966244: bridge-utils: add bridge_via to specify device for default route
Hi! > I suggest a new option called bridge_via to specify the routing interface: I've been thinking a bit on this as I didn't like the bridge_via naming as this is just to specify the interface that we take the MAC address from, it doesn't specify a via in the sense that the packages will go out through that interface or similar. I came with the idea that specifying the name of the card that we want to take the address from on bridge_hw instead of its mac would make more sense and shouldn't be too difficult to implement. So... you would write something like this: iface br0 inet dhcp bridge_ports all bridge_hw enp6s0 What do you think about this? I have just uploaded a package with a news file that talks about the change of how the kernel assigns the mac but doesn't have this implemented yet, so if we agree on this I would need to add a new news entry as it looks like this is important. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#980507: How to get STP and IPv6
Hi! It was Stephen who put some light on the original bug, as this is quite a kernel thing... > need both. The correct solution is to run DAD after the port has gone > to forwarding. I agree. > Please document how to accomplish this on Linux where you document that > it doesn't work with bridge-utils. > Even if the best solution we've got is to go frob a sysctl setting > before and after enabling stp, document that. You seem to know more on how to get this working than me, so if you could send an example of how to do this, it would be great. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#966319: correction to previous message
Hi! > Thus the regex for wireless seems to be wl* to catch all variants. Adding wifi cards is problematic, you can only bridge cards if they are in master mode, not if they are on client mode or similar, besides, naming of wifi master devices can also be virtual and thus done by other software, so I think that for bridging wireless cards it is better if people does it by hand. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#932114: bridge-utils: outdated scripts make the kernel complain
> That doesn't reflect what's happening here. The host in question has no > firewalling whatsoever. This is the result of merely launching a bridge. > Whatever commands bridge-utils issue as a result of reading the > /etc/network/interfaces stanza for br0 is what produces this. Like I said, this is not related to bridge-utils of course bridge-utils does things, it sets up a bridge, but nothing more. However to be able to create a bridge the kernel needs to have bridge support and it if is not available the bridge module gets loaded, it is this module which outputs this warning, that's it. You can test this on any machine without even bridge-utils loaded, you do a modprobe bridge and you'll get the kernel warning. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#979963: bridge-utils: bridge often collapses when removing USB WiFi dongle
> Whenever I need to perform maintenance at the console, I have to remove the > USB dongles, because their casings are wide enough to prevent access to the > VGA connector. Removing the USB dongles tends to collapse the bridge. > Restoring the bridge requires issuing the "sudo invoke-rc.d networking > restart" command. You haven't added any meaningfull information, I have a USB card on a bridge in use at work and whenever I needed to remove the USB card it worked ok, I suspect it is a problem with the kernel drivers but I'm quite sure it isn't something that bridge-utils should be blamed for. If you still think that it is because of bridge-utils we'd need to collect more data about the status of the net after you remove the usb adaptors, logs and all that kind of stuff. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#966395: Double building?
Hi! I believe that would be messy for everybody, I think we should stick with just one brand, otherwise people will find it harder to know what to install. For what I know, the openssl enabled binary will have all the features, it is only that some options are gnutls specific, and this options are not standard ones, I mean, the standard config or a normal cache usage doesn't have any of those options, right? If so... either we add a note about this posible breakage on the changes file or we write something up for translating that, is this possible? Just my thoughts ;-) Regards... -- Manty/BestiaTester -> http://manty.net
Bug#966395: Any plans on doing this for Bullseye?
Hi! I'd like to know if there are any plans on having Bullseye version compiled with --with-openssl, I'm currently running 4.13 with this option on Buster and would love to stop having to compile with --with-openssl on Bullseye. If anything is needed for this to happen on Bullseye please just let me know and maybe I can give a hand on it. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#966534: RM: autodns-dhcp -- ROM; Old package with better alternatives on the archive.
Package: ftp.debian.org Severity: normal The functionality of the package is not exactly covered by any other package but similar functionality is achieved by other packages and this old one hasn't been really tested on current software versions, even though it should work, so if somebody wants to use it he can always get it from old releases. Thanks.
Bug#868220: ifupdown should support vlan-aware bridges
Hi! On Xuñ 02 2020, Gianluigi Tiesi wrote: > Looks like bridge-utils already does it in: > /lib/bridge-utils/ifupdown.sh > > # Activate VLAN filtering on VLAN aware bridges > > if [ "$IF_BRIDGE_VLAN_AWARE" = "yes" ]; then > ip link set dev $IFACE type bridge vlan_filtering 1 > > else > ip link set dev $IFACE type bridge vlan_filtering 0 > > fi > > > the problem is I get operation not supported when setting vlan_filtering 0 > on my bridge, does the else really make sense here? Well, this was added due to bugs.debian.org/950879 reported by Benedikt who kindly supplied the patch, the patch didn't cause any trouble on the tests I did and that's why I applied it like he sent it. I have added Benedikt to my reply for him to comment on this. As I understand it, Gianluigi, if we remove the else there we won't set vlan filtering to 0 and thus you won't get the error, right? We have two options here, one is to remove it and the other to send the possible errors on the setting to 0 case to /dev/null. As I see it, maybe the second option is better, as if one has set this to yes and then sets it to no without rebooting, he wouldn't get the expected behaviour. Benedikt and Gianluigi, what do you think? Regards. -- Manty/BestiaTester -> http://manty.net
Bug#868220: Issue still open
We still haven't talked about how to land bridge setup on ifupdown yet :-( However recently Benedikt Spranger asked for us to enable vlan filtering for vlan-aware switches, so next version of bridge-utils will allow enabling this from the interfaces file. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#945466: Thanks for the info
Hi! Looks like we are too fast if we change the hw address right after creating the bridge... well, we could maybe fix this some other way, but the sleep of 1 second in the case where you are changing the hw address doesn't look like a big issue to me and I'd rather be on the safe side. If somebody else sees that waiting 1 second here is a problem and finds some other solution just let me know, right now I'll go with your fix. Thanks again! Regards... -- Manty/BestiaTester -> http://manty.net
Bug#958230: Please add libpam0g-dev as buid-dep (solves auth not working on shadow)
Source: freerdp2 Severity: normal Hi! First, sorry about the almost empty mail to the list, I was trying to abort, but somehow I managed to send :-( The thing is that when I tested freerdp2-shadow-x11 I saw that auth was not working when being run as a user, I couldn't authenticate with current user password. Googling a bit I came across some old reports, namely: https://github.com/FreeRDP/FreeRDP/issues/2775 https://github.com/FreeRDP/FreeRDP/issues/3144 That say that you need to compile with libpam0g-dev for that to work. I have tested that with 2.0.0~git20190204.1.2693389a+dfsg1-2 and yes, it worked Ok after compiling with libpam0g-dev enabled, so, if there isn't any security risks in doing so, can you please add this build-dep in order to fix the auth bug? Thanks in advance. -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (990, 'stable'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), LANGUAGE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#950879: bridge-utils: DSA and other VLAN aware bridges needs VLAN filtering
Hi! > The attached patch adds the missing bridge_vlan_aware aka > enable VLAN filtering support. Great, thanks for the patch, I'll take a look at it and do some tests, if everything looks ok I'll upload a new version soon. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#945466: bridge_hw sometimes appears to be ignored or overridden
Hi! On Nov 25 2019, Boris Kolpackov wrote: > After upgrading to the latest testing version of all the packages, I now > observe what appears to be the bridge_hw address most of the time being > ignored and some random address being used instead (76:95:e6:8c:c3:9e). I have some questions, let's see if you can answer them. I'm reading that this did not happen before, what was the status before, pure buster? Wha packages related to networking do you have installed and got upgraded? Regards... -- Manty/BestiaTester -> http://manty.net
Bug#882056: Isn't this an avoidable bug?
Hi! I arrived to this bug because of the --format error which I was seing when trying to backport something for Jessie, it looked just like this bug but this bug didn't solve anything and I had build previously from Buster for Jessie, so I thought I had to have another look at the build. It resulted that I had some dependencies problem and fixing the Control file changing the dependencies there made the build work. I'm not saying this was the case of the original submitter and maybe there is really a bug there, but maybe it can be avoided, like in my case, by setting the good dependencies for building for that distro or similar. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#930039: cannot allocate memory in static TLS block
Hi! > Control: reassign -1 php7.3 Maybe assigning it to php is the right thing to do, but googling more after sending the bug I found this bug on launchpad, it is dated 10 years ago, but seems similar: https://bugs.launchpad.net/ubuntu/+source/gcc-4.2/+bug/235070 And it points to a gcc related thing, maybe it has nothing to do with the problem in buster, I'm commenting it just in case. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#930039: cannot allocate memory in static TLS block
Package: libgomp1 Version: 8.3.0-6 Severity: important Hi! I don't really know if libgcomp1 is the one to blame here, but when using PHP based software lige nextcloud on top of Buster I'm seing this error: PHP Startup: Unable to load dynamic library 'imagick.so' (tried: /usr/lib/php/20180731/imagick.so (/lib/aarch64-linux-gnu/libgomp.so.1: cannot allocate memory in static TLS block), /usr/lib/php/20180731/imagick.so.so (/usr/lib/php/20180731/imagick.so.so: cannot open shared object file: No such file or directory)) at Unknown#0 Which seems to point to libgomp1, I have tried the versions on unstable (-7) without changes. I don't know what else to add here but if you want me to do any tests, please don't hesitate to ask. Regards. -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 4.19.0-5-arm64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), LANGUAGE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgomp1 depends on: ii gcc-8-base 8.3.0-6 ii libc6 2.28-10 libgomp1 recommends no packages. libgomp1 suggests no packages. -- no debconf information
Bug#916042: Leafpad no longer on the archive
Hi! Per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913765 leafpad has been removed, it is no longer taking part on Buster. I think it is time for lxde on Debian to remove the leafpad dependency. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#767232: Configuration problem, closing the bug
I haven't received more info on this and it looks to me like a config problem, I'm closing the bug. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#856505: Bug#911443: linux-image-4.18.0-2-arm64: wlan0 no longer present
> > >> And could we have the patch I sent on #856505 to enable sound on this > > >> machines applied as well? > > > > i assume you are talking about: > > > > arm: bcm2835-audio: Document the device tree node to enable > > bcm2835-audio driver > > > > This patch will not be accepted. For a explanation please refer to: > > > > https://lkml.org/lkml/2018/10/16/1615 > > > > The proper solution is called: > > > > staging: bcm2835-audio: Drop DT dependency > > > > and is in linux-next since a week. I've been playing with those patches for a while on 4.19, but those patches won't work on their own, they depend on some other stuff that has been commited as well. All that would mean a lot of changes. So, it seems that 4.21 will have a solution for this through a lot of changes and updates on the drivers, ... But, if we are going to go with 4.19 I believe that the simple change I was proposing which works as expected is going to give us audio on the pi and only affects the pi, is a clean solution that would solve the problem. I don't see the problem on applying this patch on Debian while upstream evolves the drivers even more on 4.21 and next versions, all we do is enable what is available on 4.19 like it was coded. Any chance for this to happen? Regards. -- Manty/BestiaTester -> http://manty.net
Bug#856505: Bug#911443: linux-image-4.18.0-2-arm64: wlan0 no longer present
> I just added the commit from v4.20-rc7 that fixes this problem to the > Linux package git repository. It will be part of the next upload of > v4.19.x to unstable. And could we have the patch I sent on #856505 to enable sound on this machines applied as well? I sent this to the lkml as you sugested but with little luck, it looks like nobody cares. For me it would be good to recover not only the wifi but also the audio. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#856505: Patch sent to lkml
Hi! After mailing Michael Zoran to see if he would be willing to submit the patch as it was on his TODO, and getting a reply encouraging me to do it... I have submitted the patch to the lkml: https://lkml.org/lkml/2018/12/12/835 Let's see if I did it Ok and gets accepted, meanwhile, I think it would be great if we could have it as a Debian patch on our next 4.19 kernel, now that we are going to have a fix for wifi (#911443), it would be great to have sound as well. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#915808: Current dtb for raspberry pi 3b doesn't allow wifi to be used
Package: src:linux Version: 4.18.20-2 Severity: normal Tags: patch Hi! After kernel 4.17 the dtb for raspberry pi 3 b is not ok and thus the wifi is not found and cannot be used. Looking at the differences from 4.17 to 4.18 I have discovered that if you revert this single patch affecting only the pi3b model the wifi is discovered and works again. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/bcm2837-rpi-3-b.dts?id=b1b8f45b3130dbd8704e5ea0d82b49b1d929498e I have tested this both on Linus kernel 4.20-rc5 and on Debian 4.19.5 as currently on experimental, on both reverting this patch makes the wifi work again. Regards -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information Device Tree model: Raspberry Pi 3 Model B Rev 1.2 ** PCI devices: not available ** USB devices: Bus 001 Device 006: ID 0bc2:2322 Seagate RSS LLC Bus 001 Device 005: ID 0b95:772b ASIX Electronics Corp. AX88772B Bus 001 Device 004: ID 0939:0b15 Lumberg, Inc. Toshiba Stor.E Alu 2 Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 4.19.5 (SMP w/4 CPU cores) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), LANGUAGE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-4.18.0-3-arm64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.132 ii kmod25-2 ii linux-base 4.5 Versions of packages linux-image-4.18.0-3-arm64 recommends: ii apparmor 2.13.1-3+b1 ii firmware-linux-free 3.4 ii irqbalance 1.5.0-0.1 Versions of packages linux-image-4.18.0-3-arm64 suggests: pn debian-kernel-handbook pn linux-doc-4.18 Versions of packages linux-image-4.18.0-3-arm64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x ii firmware-brcm8021120180825+dfsg-1 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic ii firmware-realtek 20180825+dfsg-1 pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#856505: This patch should solve the audio problem
Hi!
Based on eHenry's instructions I have created this patch which I have tested
on Debian's 4.19 kernel now on experimental, where we have already enabled
the sound driver which was not working.
The result is that with this patch the sound is finally working, so, please
apply this to the 4.19 kernel to enable sound.
--- bcm283x.dtsi.orig 2018-12-03 00:07:55.0 +0100
+++ bcm283x.dtsi2018-12-05 13:36:02.718569539 +0100
@@ -634,6 +634,10 @@
vc4: gpu {
compatible = "brcm,bcm2835-vc4";
};
+audio: audio {
+ compatible = "brcm,bcm2835-audio";
+ brcm,pwm-channels = <8>;
+};
};
clocks {
Regards.
--
Santiago García Mantiñán
Bug#856505: Sound working on the pi3b with eHenry's patch
I've compiled a Debian 4.19 kernel with your sugested patch to enable audio and reverting another one to fix the WiFi problem and I now have both audio and WiFi working. I'll send proper patches as soon as I have time, but it works. Regards. -- Santiago García Mantiñán
Bug#890817: One more
Hi! While this bug is not fixed I came across it while doing a crosscompile of a pi3 kernel, aplying Kevin's patch (thanks a lot) almost fixed compiling, but I found another place whre it got stuck, so here is an addon for the patch that Kevin had sent: --- /usr/share/kernel-package/ruleset/targets/common.mk.orig2016-02-17 00:35:18.0 +0100 +++ /usr/share/kernel-package/ruleset/targets/common.mk 2018-12-04 13:46:11.719595467 +0100 @@ -177,7 +177,7 @@ $(eval $(which_debdir)) ifeq ($(DEB_HOST_ARCH_OS), linux) @$(MAKE) --no-print-directory -sf $(DEBDIR)/ruleset/kernel_version.mk \ - ARCH=$(KERNEL_ARCH) $(CROSS_ARG) debian_conf_var >> debian/stamp/conf/mak + ARCH=$(KERNEL_ARCH) $(CROSS_ARG) debian_conf_var > debian/stamp/conf/mak endif @echo "do_parallel = $(do_parallel)" >> debian/stamp/conf/mak @echo "fast_dep = $(fast_dep)" >> debian/stamp/conf/mak This worked ok for compiling upstream 4.20-rc5. Regards. -- Santiago García Mantiñán
Bug#900821: vers=2.1 won't solve it
Hi! I have tested vers=2.1 parameter on a current Buster installation and at least if the server is a Samba (samba as in Buster with a standard setup) the version of the protocol won't solve anything, the wget still breaks: Saving to: 'STDOUT' -16%[> ] 1.01M --.-KB/s in 0.008s 2018-12-03 13:55:39 (124 MB/s) - Read error at byte 1056768/6538880 (Bad address). Retrying. The only working solution still is EnableSendFile On This was tested with: ii linux-image-4.18.0-2-amd644.18.10-2+b1amd64 Linux 4.18 for 64-bit PCs ii samba 2:4.9.2+dfsg-2 amd64 SMB/CIFS file, print, and login server for Unix ii apache2 2.4.37-1amd64 Apache HTTP Server Regards. -- Santiago García Mantiñán
Bug#856505: snd_bcm2835 included on 4.19 kernel in experimental
Hi! This module is now included in the 4.19 kernel recently uploaded to experimental (linux-image-4.19.0-trunk-arm64 4.19.5-1~exp1), you can add experimental to your sources.list like this: deb http://deb.debian.org/debian ../project/experimental main However on my first tests this hasn't solved the problem, looks like the driver is not finding the hardware or similar, I'm getting: snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned. but not the: bcm2835_alsa bcm2835_alsa: card created with 8 channels message, so it doesn't work. We know that the current dtb is broken since at lease 4.18, this breaks wifi and it might affect the sound so that it is not found, but I don't really know. If you test it and get it to work just let us know how you managed it. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#911121: Please compile with CONFIG_SND_BCM2835=m
Hi! > I don't have an rpi3 to test, but I wonder if it is really necessary to > enable CONFIG_SND_BCM2835 to get sound. After our talk on irc I thought you had commited this change, but a new version of the kernel has been uploaded and doesn't include this. What has happened? Regards.
Bug#910790: Testing again.
Hi again. I've tested latest update, working ok, config file got moved with all the old stuff inside. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#910790: Testing the proposal
The only caveat I found was that on the raspi3-firmware package upgrade the changes I had done to /etc/kernel/postinst.d/50-raspi3-firmware were not copied to /etc/kernel/postinst.d/z50-raspi3-firmware. I had modified the root fs, as I boot from /dev/md1 not from the mmc device, and thus after upgrading the raspi3-firmware I ended up with a config.txt that would have tried to boot from the mmc. Also on another device I had set cma=96M at the postinst script and that had also been lost. Other than that everything is fine for me. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#910790: Testing the proposal
Hi! I've built a package using your salsa fork and everything looks fine, I always ended with the highest version on the firmware dir and on the config.txt, so that is ok. The only "weird" thing I found was when installing 4.18 having installed 4.19-rc7, thus installing a lower version, the lower version didn't end up on the firmware dir, but that is expected if you look at the code, and as the config.txt only has room for a kernel... then there is no reason why it should be on the firmware dir, furthermore, when I later uninstalled the 4.19-rc7 kernel the 4.18 stuff got propagated to firmware and config.txt as expected. So, as far as I can tell the changes look ok to me. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#911121: Please compile with CONFIG_SND_BCM2835=m
Package: src:linux Version: 4.18.10-2 Severity: wishlist Hi! I'm currently running this kernel on Raspberry Pi 3b without much trouble, however no sound devices are found, After reading and looking at raspbian modules, it seems that sound is handled by this module, so if you would please enable it with a little luck we'll have sound working on Pi 3b on standard buster. Thanks in advance. -- Package-specific info: ** Version: Linux version 4.18.0-2-arm64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-29)) #1 SMP Debian 4.18.10-2 (2018-10-07) ** Command line: bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 dma.dmachans=0x7f35 bcm2709.boardrev=0xa02082 bcm2709.serial=0xff0fa6ff bcm2709.uart_clock=4800 smsc95xx.macaddr=B8:27:EB:0F:A6:FF vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 console=tty0 console=ttyS1,115200 root=/dev/md1 rw elevator=deadline fsck.repair=yes net.ifnames=0 cma=64M rootwait ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information Device Tree model: Raspberry Pi 3 Model B Rev 1.2 ** Loaded modules: nf_log_ipv4 nf_log_common xt_LOG xt_pkttype xt_limit ipt_REJECT nf_reject_ipv4 xt_owner xt_conntrack iptable_filter ipt_MASQUERADE xt_REDIRECT xt_nat xt_tcpudp xt_addrtype iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_connmark nf_conntrack xt_mark iptable_mangle bridge stp llc vc4 snd_soc_core nls_ascii nls_cp437 snd_pcm_dmaengine vfat fat snd_pcm brcmfmac snd_timer snd soundcore cec brcmutil drm_kms_helper cfg80211 drm asix sg bcm2835_rng rng_core smsc95xx libphy bcm2835_thermal leds_gpio usbnet mii rfkill pwm_bcm2835 bcm2835_wdt ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 fscrypto ecb aes_arm64 sd_mod raid10 uas raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx usb_storage xor scsi_mod raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod dwc2 udc_core usbcore sdhci_iproc sdhci_pltfm usb_common sdhci bcm2835 phy_generic ** PCI devices: not available ** USB devices: Bus 001 Device 006: ID 0bc2:2322 Seagate RSS LLC Bus 001 Device 005: ID 0b95:772b ASIX Electronics Corp. AX88772B Bus 001 Device 004: ID 0939:0b15 Lumberg, Inc. Toshiba Stor.E Alu 2 Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: arm64 (aarch64) Kernel: Linux 4.18.0-2-arm64 (SMP w/4 CPU cores) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), LANGUAGE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-4.18.0-2-arm64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.132 ii kmod25-1 ii linux-base 4.5 Versions of packages linux-image-4.18.0-2-arm64 recommends: ii apparmor 2.13-8 ii firmware-linux-free 3.4 ii irqbalance 1.3.0-0.1+b1 Versions of packages linux-image-4.18.0-2-arm64 suggests: pn debian-kernel-handbook pn linux-doc-4.18 Versions of packages linux-image-4.18.0-2-arm64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x ii firmware-brcm8021120180825+dfsg-1 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic ii firmware-realtek 20180825+dfsg-1 pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#910790: Acknowledgement (new initrd file was not found)
Hi again! After that install of the kernel I tried a reinstall via... # apt-get install --reinstall linux-image-4.18.0-2-arm64 Lendo as listas de paquetes... Feito Construindo a árbore de dependencias Lendo a información do estado... Feito 0 anovados, 0 instalados, 1 reinstalados, Vanse retirar 0 e deixar 51 sen anovar. Ten que recibir 0 B/36,5 MB de arquivos. Despois desta operación ocuparanse 0 B de disco adicionais. (A ler a base de datos ... 31785 files and directories currently installed.) Preparing to unpack .../linux-image-4.18.0-2-arm64_4.18.10-2_arm64.deb ... Unpacking linux-image-4.18.0-2-arm64 (4.18.10-2) over (4.18.10-2) ... A configurar linux-image-4.18.0-2-arm64 (4.18.10-2) ... /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-4.18.0-2-arm64 raspi3-firmware: deferring update via initramfs-tools (hook will be called later by the kernel What I saw there was that the propagation to /boot/firmware had been done by raspi3-firmware before the update-initramfs had built the new initrd and later the new initrd is not propagated to firmware, so I ended up with an older -2 initrd on the firmware dir. Regards. -- Manty/BestiaTester -> http://manty.net
