Bug#1025141: powermgmt-base: Doesn't correctly detect we are on AC power
Package: powermgmt-base Version: 1.37 Severity: normal Dear Maintainer, I'm running Debian stable on a HP ProDesk 600 G6 Small Form Factor PC (Family: 103C_53307F HP ProDesk) It is a desktop machine which ovbiously runs on AC all the time, however on_ac_power returns 1 which is stopping things like unattended upgrades from being run. On /sys/class/power_supply/ there is only: lrwxrwxrwx 1 root root 0 Nov 29 14:53 ucsi-source-psy-USBC000:001 -> ../../devices/platform/USBC000:00/power_supply/ucsi-source-psy-USBC000:001 and there... /sys/class/power_supply/ucsi-source-psy-USBC000\:001/type says USB. I have opened the machine and the power supply seems to use only a couple of 12V 4 pin connectors like the one introduced with the P4, but that's it, no sign of USB. My guess is that the USB thing there is one USB-c connector on the front of the machine, in fact it says on usb_type [C] PD PD_PPS which I guess means that the connector is compatible with power delivery. I guess BIOS may be the one to blame here, I have updated to the latest, now it is running... Version: S07 Ver. 02.13.00 Release Date: 10/12/2022 It still happens with that BIOS, I even tried to use kernel 6.1 rc6 as available on experimental right now to see if that made any change, but that didn't change a thing. For what I see, acpi doesn't have info on power suppy, no sign of it executing acpi -V and /proc/acpi only has wakeup inside. And there is no pmu or apm info either. I don't know what other info to add here, but please don't hesitate to ask whatever you need. Regards. -- System Information: Debian Release: 11.5 APT prefers stable-security APT policy: (990, 'stable-security'), (990, 'stable'), (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-19-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_OOT_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 -- no debconf information
Bug#1013268: chromium: Broken kerberos authentication
Package: chromium
Version: 101.0.4951.41-1~deb11u1
Severity: normal
Dear Maintainer,
starting with version 101.0.4951.41-1~deb11u1 I have found that kerberos
authentication is broken, I have tested that on version
100.0.4896.127-1~deb11u1 everything was working ok.
To reproduce it I get a working ticket with kinit myuser, I then run a klist
to make sure the ticket is ok and then I try to logon on places I have
authorized at /etc/chromium/policies/recommended/auth.json
{
"AuthServerWhitelist": "*.internal.domain"
}
The result is that up to version 100 or in firefox it just works, and
version 101 and later don't work.
I don't know what other info I can provide, so don't hesitate to ask for it.
-- System Information:
Debian Release: 11.3
APT prefers stable-security
APT policy: (990, 'stable-security'), (990, 'stable'), (500,
'stable-updates'), (500, 'proposed-updates'), (500, 'oldstable-updates'), (500,
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500,
'oldstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-15-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 chromium depends on:
ii chromium-common102.0.5005.115-1~deb11u1
ii libasound2 1.2.4-1.1
ii libatk-bridge2.0-0 2.38.0-1
ii libatk1.0-02.36.0-2
ii libatomic1 10.2.1-6
ii libatspi2.0-0 2.38.0-4
ii libc6 2.31-13+deb11u3
ii libcairo2 1.16.0-5
ii libcups2 2.3.3op2-3+deb11u2
ii libdbus-1-31.12.20-2
ii libdrm22.4.104-1
ii libevent-2.1-7 2.1.12-stable-1
ii libexpat1 2.2.10-2+deb11u3
ii libflac8 1.3.3-2+deb11u1
ii libfontconfig1 2.13.1-4.2
ii libfreetype6 2.10.4+dfsg-1
ii libgbm120.3.5-1
ii libgcc-s1 10.2.1-6
ii libglib2.0-0 2.66.8-1
ii libgtk-3-0 3.24.24-4+deb11u2
ii libjpeg62-turbo1:2.0.6-4
ii libjsoncpp24 1.9.4-4
ii liblcms2-2 2.12~rc1-2
ii libminizip11.1-8+b1
ii libnspr4 2:4.29-1
ii libnss32:3.61-1+deb11u2
ii libopenjp2-7 2.4.0-3
ii libopus0 1.3.1-0.1
ii libpango-1.0-0 1.46.2-3
ii libpng16-161.6.37-3
ii libpulse0 14.2-2
ii libre2-9 20210201+dfsg-1
ii libsnappy1v5 1.1.8-1
ii libstdc++6 10.2.1-6
ii libwebp6 0.6.1-2.1
ii libwebpdemux2 0.6.1-2.1
ii libwebpmux30.6.1-2.1
ii libx11-6 2:1.7.2-1
ii libxcb11.14-3
ii libxcomposite1 1:0.4.5-1
ii libxdamage11:1.1.5-2
ii libxext6 2:1.3.3-1.1
ii libxfixes3 1:5.0.3-2
ii libxkbcommon0 1.0.3-2
ii libxml22.9.10+dfsg-6.7+deb11u2
ii libxrandr2 2:1.5.1-1
ii libxslt1.1 1.1.34-4
ii xdg-desktop-portal-gtk [xdg-desktop-portal-backen 1.8.0-1
ii zlib1g 1:1.2.11.dfsg-2+deb11u1
Versions of packages chromium recommends:
ii chromium-sandbox 102.0.5005.115-1~deb11u1
Versions of packages chromium suggests:
pn chromium-driver
ii chromium-l10n102.0.5005.115-1~deb11u1
ii chromium-shell 102.0.5005.115-1~deb11u1
Versions of packages chromium-common depends on:
ii libc6
Bug#943692: squid: crash on bug #4823 : assertion failed: stmem.cc:98: "lowestOffset () <= target_offset"
Package: squid Version: 4.6-1+deb10u1 Severity: important Tags: patch Dear Maintainer, Shortly after buster came out I updated the machines to it and after a little time we found out that squid had crashed with owestOffset () <= target_offset Amos was so kind to point me to bug #4823 on squid: https://bugs.squid-cache.org/show_bug.cgi?id=4823 And after adding the patch from http://www.squid-cache.org/Versions/v4/changesets/squid-4-10b699c30ef575d97e093d344ff85771654e7d8c.patch to the Debian source package and compiling it the system became stable and hasn't crashed anymore. I suggest we add that for the next point release. Thanks. -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/2 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 Versions of packages squid depends on: ii adduser 3.118 ii libc62.28-10 ii libcap2 1:2.25-2 ii libcom-err2 1.44.5-1+deb10u2 ii libdb5.3 5.3.28+dfsg1-0.5 ii libdbi-perl 1.642-1+b1 ii libecap3 1.0.1-3.2 ii libexpat12.2.6-2+deb10u1 ii libgcc1 1:8.3.0-6 ii libgnutls30 3.6.7-4 ii libgssapi-krb5-2 1.17-3 ii libkrb5-31.17-3 ii libldap-2.4-22.4.47+dfsg-3+deb10u1 ii libltdl7 2.4.6-9 ii libnetfilter-conntrack3 1.0.7-1 ii libnettle6 3.4.1-1 ii libpam0g 1.3.1-5 ii libsasl2-2 2.1.27+dfsg-1 ii libstdc++6 8.3.0-6 ii libxml2 2.9.4+dfsg1-7+b3 ii logrotate3.14.0-4 ii lsb-base 10.2019051400 ii netbase 5.6 ii squid-common 4.6-1+deb10u1 Versions of packages squid recommends: ii ca-certificates 20190110 ii libcap2-bin 1:2.25-2 Versions of packages squid suggests: pn resolvconf ii smbclient2:4.9.5+dfsg-5+deb10u1 pn squid-cgi pn squid-purge pn squidclient pn ufw pn winbind -- no debconf information
Bug#943317: dhis-server doesn't set source port when replying to clients
Package: dhis-server
Version: 5.3-2.1+b2
Severity: wishlist
Tags: patch
Dear Maintainer,
When I last tried to implement a dhis-server on our network at work we had
trouble getting the traffic through the firewalls.
It turned out that at least with our dhis setup (nothing special to be
honest) the server was returning the packets from a port that was not the
port that the client had sent the packet to, so the traffic was asymmetric
and the firewall, which was open only to reach the server and then
established and related traffic, didn't let the reply pass.
In order to fix this we went to the code and applied this patch which solves
the problem.
Index: dhis-server-5.3/network.c
===
--- dhis-server-5.3.orig/network.c 2015-01-15 13:27:27.0 +
+++ dhis-server-5.3/network.c 2015-01-20 12:31:14.830863637 +
@@ -239,12 +239,16 @@
int net_init(int port) {
struct sockaddr_in sa;
-
+int optval;
/* Create UDP socket */
udp_sock=socket(AF_INET,SOCK_DGRAM,0);
if(udp_sock<0) return(1);
+/* Set the UDP socket to REUSEADDR */
+optval = 1;
+if (setsockopt(udp_sock, SOL_SOCKET, SO_REUSEADDR, , sizeof
optval)) return(1);
+
/* Bind the UDP socket */
sa.sin_family=AF_INET;
sa.sin_port=htons(port);
@@ -327,7 +331,7 @@
*/
int net_write_message(msg_t *p,int toaddr,int toport) {
- struct sockaddr_in sa;
+ struct sockaddr_in sa,ss;
int s;
int len;
int r;
@@ -348,6 +352,15 @@
sa.sin_port=htons(toport);
sa.sin_addr.s_addr=toaddr;
+/* set source port */
+ ss.sin_family=AF_INET;
+ ss.sin_addr.s_addr=htonl(INADDR_ANY);
+ ss.sin_port=htons(rport);
+ r = 1;
+ if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, , sizeof r)) return (0);
+ if (bind(s,(struct sockaddr *),sizeof(ss))) return(0);
+ DSYSLOG(1,(LOG_DEBUG,"net_write_message(): source port set to %d\n",
rport));
+
/* Get message size */
len=msg_size_by_opcode(p->hdr.opcode);
-- System Information:
Debian Release: 10.1
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'oldoldstable'),
(500, 'unstable'), (500, 'oldstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-6-amd64 (SMP w/2 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
Versions of packages dhis-server depends on:
ii libc6 2.28-10
ii libgmp10 2:6.1.2+dfsg-4
Versions of packages dhis-server recommends:
ii dhis-dns-engine 5.3-2+b1
ii dhis-tools-dns 5.0-8+b1
Versions of packages dhis-server suggests:
pn dhis-mx-sendmail-engine
-- no debconf information
Bug#909563: mbr: Package is now Debian source but says to report bugs to Neil
Package: mbr Version: 1.2.0 Severity: normal At least on the help screen says: Report bugs to ne...@chiark.greenend.org.uk Which clearly doesn't apply to this 1.2.0 Debian version. -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mbr depends on: ii libc6 2.24-11+deb9u3 mbr recommends no packages. mbr suggests no packages. -- no debconf information
Bug#900821: linux-image-4.9.0-6-amd64: apache reads wrong data over cifs filesystems served by samba
Package: src:linux Version: 4.9.88-1+deb9u1 Severity: important Dear Maintainer, I've found that when you mount a filesystem being served by samba on a host running apache and serve the files on this filesystem over apache, you'll get garbage mixed with the file content. This means that you get the right length but the file's content gets corrupted. This only happens when serving the files from samba, if you serve them from Windows the problem doesn't appear. I have found this problem in a pure Debian stable installation (Stretch), but I have tested this on a pure testing (Buster) installation with even worst results, the download breaks and the kernel shows this: [ 649.547840] WARNING: CPU: 6 PID: 1573 at /build/linux-43CEzF/linux-4.16.12/lib/iov_iter.c:695 copy_page_to_iter+0x1dd/0x2f0 [ 649.547844] Modules linked in: cmac arc4 md4 nls_utf8 cifs ccm dns_resolver fscache amd64_edac_mod edac_mce_amd radeon ccp rng_core joydev kvm sg evdev ttm k10temp drm_kms_helper serio_raw pcspkr shpchp drm irqbypass i2c_algo_bit hpilo hpwdt ipmi_si ipmi_devintf button ipmi_msghandler ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb crypto_simd cryptd glue_helper aes_x86_64 hid_generic usbhid hid sd_mod ohci_pci qla2xxx hpsa nvme_fc scsi_transport_fc scsi_transport_sas psmouse uhci_hcd ohci_hcd ehci_pci nvme_fabrics ehci_hcd scsi_mod nvme_core usbcore bnx2 i2c_piix4 usb_common [ 649.547943] CPU: 6 PID: 1573 Comm: wget Tainted: GW 4.16.0-2-amd64 #1 Debian 4.16.12-1 [ 649.547945] Hardware name: HP ProLiant BL465c G6 , BIOS A13 12/08/2009 [ 649.547953] RIP: 0010:copy_page_to_iter+0x1dd/0x2f0 [ 649.547956] RSP: 0018:ad6602defc58 EFLAGS: 00010297 [ 649.547960] RAX: 8000 RBX: d65a085b1000 RCX: 0003 [ 649.547963] RDX: 8075 RSI: 017fffc08000 RDI: 085b1000 [ 649.547965] RBP: 148b R08: 2000 R09: 9ca6e457cd24 [ 649.547968] R10: 9ca6e20df8e8 R11: 548b R12: ad6602defdf0 [ 649.547970] R13: 6bea R14: 0040 R15: 0001 [ 649.547974] FS: 7f0978403780() GS:9ca6e7cc() knlGS: [ 649.547977] CS: 0010 DS: ES: CR0: 80050033 [ 649.547980] CR2: 5592e97b3078 CR3: 000223f6c000 CR4: 06e0 [ 649.547983] Call Trace: [ 649.548001] skb_copy_datagram_iter+0x175/0x280 [ 649.548010] tcp_recvmsg+0x279/0xb90 [ 649.548019] ? set_fd_set+0x38/0x50 [ 649.548024] ? core_sys_select+0x2a4/0x2d0 [ 649.548032] inet_recvmsg+0x58/0xd0 [ 649.548038] sock_read_iter+0x94/0xf0 [ 649.548047] new_sync_read+0xe9/0x140 [ 649.548060] vfs_read+0x89/0x130 [ 649.548066] SyS_read+0x52/0xc0 [ 649.548075] do_syscall_64+0x6c/0x130 [ 649.548082] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 649.548089] RIP: 0033:0x7f0976eb7061 [ 649.548091] RSP: 002b:7ffec8800db8 EFLAGS: 0246 ORIG_RAX: [ 649.548095] RAX: ffda RBX: 0003 RCX: 7f0976eb7061 [ 649.548097] RDX: 2000 RSI: 5592e97afc70 RDI: 0003 [ 649.548100] RBP: 0010113b R08: 7ffec8800cd0 R09: 7f0978403780 [ 649.548102] R10: R11: 0246 R12: 2000 [ 649.548105] R13: 5592e97afc70 R14: R15: 5592e97b1c80 [ 649.548108] Code: ff ff 48 89 c5 41 83 ae 28 0a 00 00 01 48 83 c4 10 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f b6 49 69 48 d3 e0 e9 a6 fe ff ff <0f> 0b 31 ed eb dc 85 c9 0f 84 ad 00 00 00 31 ed eb d0 4d 01 f5 [ 649.548180] ---[ end trace 5c988a789d68247f ]--- Doing several md5sums of the files directly on the cifs filesystem will allways result in the same md5, also doing dd if=file|md5sum, however wget http://localhost/file -O -|md5sum will result on a different code each time. The same tests running the same Stretch machine with Jessie's kernel will work Ok. Like I've said I've been able to replicate this on standard Stretch and Buster configs. These are the steps to replicate... install: apt-get install samba apache2 cifs-utils add to smb.conf to create a ftp share and then: service smbd reload [ftp] writable = no locking = no path = /srv/ftp public = yes browseable = no generate a file to be served: dd if=/dev/zero of=/srv/ftp/100Mzero bs=1024k count=100 mount the share on the web directory to serve it: mount.cifs //localhost/ftp /var/www/html/ test the local access of the cifs: md5sum /srv/ftp/100Mzero 2f282b84e7e608d5852449ed940bfc51 /srv/ftp/100Mzero Acces the file over apache: wget http://localhost/100Mzero -O - 2>/dev/null|md5sum 2b0ac997ed705924db55cf5f45ad3c88 - Like I said, changing to a Jessie's kernel this works ok, changing to a Buster 4.16 kernel or testing on a full Buster setup gives similar problem but http transfer is interrupted and kernel shows previous message. Also serving the
Bug#882851: live-config: Wrong time when RTC is set to local time
Package: live-config
Version: 5.20170112
Severity: normal
Hi!
This may be a follow up of #824197, I believe that the patches that were
introduced then don't fix the problem, at least not now.
I'm testing this on a live network image which was built using stretch and
has as boot parameters:
boot=live components config hostname=coru username=debian
locales=es_ES.UTF-8,gl_ES.UTF-8 keyboard-layouts=es timezone=Europe/Madrid
utc=no netboot=cifs nfsroot=//10.10.50.10/debian-live-amd64 noroot quiet
The important part here is that the clock is supposed to be in local time
(we have the utc=no to signal this and indeed the /etc/adjtime on the live
system file says LOCAL) and we are on CET (timezone=Europe/Madrid).
However, the system adds 1 hour to the rtc even though we are saying that it
is on local time anyway.
I believe that systemd is reading /etc/adjtime before live systems adds the
LOCAL label to it, or something similar (this is just my thought, no
evicence pointing at this yet). This is what timedatectl says after booting:
Local time: jue 2017-11-23 09:25:36 CET
Universal time: jue 2017-11-23 08:25:36 UTC
RTC time: jue 2017-11-23 08:25:35
Time zone: Europe/Madrid (CET, +0100)
Network time on: yes
NTP synchronized: no
RTC in local TZ: yes
As you can see it detects that we have the rtc on local time however the
info is incoherent, it is showing that the rtc has 8:25 and utc is is 8:25
with a TZ of +1 and the RTC in local TZ :-(
I did contact Raphael Hertzog about this and he was so kind to produce a
patch on which we changed live-config to use timedatectl instead of just
changing /etc/adjtime, but this didn't help either. Here is Raphael's patch
with a little typo fixed:
diff --git a/components/1120-util-linux b/components/1120-util-linux
index 8bb45e5..b078df5 100755
--- a/components/1120-util-linux
+++ b/components/1120-util-linux
@@ -43,25 +43,24 @@ Config ()
then
case "${LIVE_UTC}" in
yes)
-
-cat > /etc/adjtime << EOF
-0.0 0 0.0
-0
-UTC
-EOF
-
+ set_local_rtc=0
+ adjtime=UTC
;;
no)
-
-cat > /etc/adjtime << EOF
-0.0 0 0.0
-0
-LOCAL
-EOF
-
+ set_local_rtc=1
+ adjtime=LOCAL
;;
esac
+ if which timedatectl >/dev/null 2>&1; then
+ timedatectl set-local-rtc $set_local_rtc
--adjust-system-clock
+ else
+ cat > /etc/adjtime <<-EOF
+ 0.0 0 0.0
+ 0
+ $adjtime
+ EOF
+ fi
fi
# Creating state file
The problem seems to be that when this script is run timedatectl doesn't
have enough services to be able to do anything, so it doesn't do a thing.
I have done some tests and at the time 1120-util-linux just a few systemd
services are running:
root 441 0.6 0.4 39176 4400 ?Ss 15:04 0:00
/lib/systemd/systemd-journald
systemd+ 492 0.4 0.4 129344 4192 ?Ssl 15:04 0:00
/lib/systemd/systemd-timesyncd
in fact, no other service is running except for init, lvmetad, the kernel
processes and live-config itself.
So... the question here is... how to we tell systemd at this time of the
boot process that we have the RTC in LOCAL time if setting LOCAL on third
line of /etc/adjtime at this time doesn't work and we cannot use timedatectl?
I have tested this both with live-config from stable and unstable.
If you want me to do any tests or need any other info just let me know.
Regards.
Kernel: Linux 4.9.0-4-amd64 (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 /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages live-config depends on:
ii live-config-systemd [live-config-backend] 5.20170112+nmu1
Versions of packages live-config recommends:
ii iproute24.9.0-1
ii keyboard-configuration 1.164
ii live-config-doc 5.20170112
pn live-tools
ii locales 2.24-11+deb9u1
ii locales-all 2.24-11+deb9u1
ii sudo1.8.19p1-2.1
pn user-setup
Versions of packages live-config suggests:
ii pciutils 1:3.5.2-1
ii wget 1.18-5+deb9u1
-- no debconf information
