Bug#1055205: chrony: SysV problems after upgrade
Hi Richard, Le 2023-11-02 09:01, Richard Lucassen a écrit : > Package: chrony > Version: 4.4-3 > Severity: normal > > I run chronyd supervised. Therefore I removed symlinks in /etc/rc2.d/ > (update-rc.d chrony remove). > But after an upgrade the deb package installs new symlinks in /etc/rc2.d/ and > starts chronyd, even though chronyd is SysV disabled. > > Please check if /etc/rc2.d/*chrony symlinks exist, if not, don't add these > and do not start chronyd. Maybe it's a good idea to just display a warning in > that case. > I'm closing this bug report as this is, to me, not something that should handled on the packaging side. From update-rc.d(8): A common system administration error is to delete the links with the thought that this will "disable" the service, i.e., that this will prevent the service from being started. However, if all links have been deleted then the next time the package is upgraded, the package's postinst script will run update-rc.d again and this will reinstall links at their factory de- fault locations. The correct way to disable services is to configure the service as stopped in all runlevels in which it is started by default. In the System V init system this means renam- ing the service's symbolic links from S to K. .P The script .BI /etc/init.d/ name must exist before update-rc.d is run to create the links. Running 'update-rc.d chrony disable' as root should work too. > Richard. Have a good day, Vincent signature.asc Description: PGP signature
Bug#1051822: installed chrony package post-installation script subprocess returned error exit status 1
Control: tags -1 + moreinfo Hi Anibal, Le 2023-09-13 13:52, Anibal Monsalve Salazar a écrit : > Package: chrony > Version: 4.2-2 > Severity: critical > > # dpkg -i /mnt/apt/archives/chrony_4.4-1_i386.deb > (Reading database ... 34682 files and directories currently installed.) > Preparing to unpack .../archives/chrony_4.4-1_i386.deb ... > Failed to stop chronyd-restricted.service: Unit chronyd-restricted.service > not loaded. > Unpacking chrony (4.4-1) over (4.3-4) ... > Setting up chrony (4.4-1) ... > Unknown option: comment > adduser [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID] > [--firstuid ID] [--lastuid ID] [--gecos GECOS] [--ingroup GROUP | --gid ID] > [--disabled-password] [--disabled-login] [--add_extra_groups] USER >Add a normal user > > adduser --system [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID] > [--gecos GECOS] [--group | --ingroup GROUP | --gid ID] [--disabled-password] > [--disabled-login] [--add_extra_groups] USER >Add a system user > > adduser --group [--gid ID] GROUP > addgroup [--gid ID] GROUP >Add a user group > > addgroup --system [--gid ID] GROUP >Add a system group > > adduser USER GROUP >Add an existing user to an existing group > > general options: > --quiet | -q don't give process information to stdout > --force-badname allow usernames which do not match the > NAME_REGEX configuration variable > --help | -h usage message > --version | -vversion number and copyright > --conf | -c FILE use FILE as configuration file > > dpkg: error processing package chrony (--install): > installed chrony package post-installation script subprocess returned error > exit status 1 > Processing triggers for man-db (2.11.2-3) ... > Errors were encountered while processing: > chrony I don't seem to be able to reproduce this issue. Could you please give me more information on the system on which you were upgrading chrony? It seems you were upgrading from chrony 4.3-4, so I guess this system is running testing/unstable‽ Cheers, Vincent signature.asc Description: PGP signature
Bug#995608: linux-image-5.14.0-1-amd64: Boot immediately hangs.
Hi, Le 2021-10-03 11:40, Nathanael Schweers a écrit : > > Salvatore Bonaccorso writes: > > > Control: tags -1 + moreinfo > > > > Hi Nathanael, > > > > On Sun, Oct 03, 2021 at 10:02:35AM +0200, Nathanael Schweers wrote: > >> Package: src:linux > >> Version: 5.14.6-3 > >> Severity: grave > >> Justification: renders package unusable > >> > >> Dear Maintainer, > >> > >> using this kernel, my machine no longer boots. Instead of showing a > >> prompt to > >> enter the LUKS passphrase (as is done in version > >> linux-image-5.10.0-7-amd64) a > >> non-blinking cursor is shown. Nothing happens afterwards. > >> > >> Version linux-image-5.10.0-7-amd64 still works, but newer versions > >> (linux-image-5.10.0-8-amd64 and the version this report is for) produce the > >> behaviour mentioned above. > >> > >> I’m afraid that I don’t have a decent idea on what extra information to > >> provide. > > > > Could you please confirm that booting with the 'mem_encrypt=off' > > kernel command line heps? > > With this option the kernel does indeed boot. Thanks for the tip! Salvatore, given the increase in bug reports that this feature generates, I think it would be sensible to unset AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT until those incompatibilities are fixed, like I proposed in [1]. One would have to use the "mem_encrypt=on" command line option to enable the AMD Secure Memory Encryption. If it sounds reasonable to you and the rest of the kernel team, I can send a merge request. Cheers, Vincent signature.asc Description: PGP signature
Bug#995260: chrony: Mismatched filename for UNIX socket between client and daemon
Hi,
Le 2021-09-28 11:55, Steve Egbert a écrit :
> Package: chrony
> Version: 4.0-8
> Severity: grave
> Tags: upstream
> Justification: renders package unusable
> X-Debbugs-Cc: s.egb...@sbcglobal.net
>
> Dear Maintainer,
>
>
> The filename construct for a UNIX socket to be shared
> between the Chrony (chronyd) daemon and its Chrony CLI (chronyc) client
> admin tool are not in sync, as client's UNIX filename uses a PID value
> whereas server's UNIX filename does not use PID value.
>
> This appears to be a Debian-only issue.
What makes you think that this issue, if at all, is specific to Debian?
> Fired up its daemon and doubled checked that a UNIX socket was made:
>
> $ ls -1 /run/chrony
> chrony.sock
> chrony.pid
chrony in Debian will create by default the chronyd.{pid,sock} files. The
above shows that you are tweaked chronyd's configuration. What changes did you
make?
> Execute the client and no successful UNIX socket opened.
>
> Using List Open File (lsof) tool, I show the daemon's opened files:
>
> COMMAND PID USER FD TYPE NODE NAME
>
> chronyd 3597 _chrony3u unix 0x \
> type=DGRAM
> chronyd 3597 _chrony5u IPv4 UDP 127.0.0.1:323
> chronyd 3597 _chrony6u IPv6 UDP [::1]:323
> chronyd 3597 _chrony7u unix 0x \
> /run/chrony/chronyd.sock type=DGRAM
> chronyd 3597 _chrony8u unix 0x type=SEQPACKET
> chronyc 3809johnd3u IPv4 UDP \
> 127.0.0.1:33911->127.0.0.1:323
>
> No socket in the dispatcher part of the daemon, now to check the other
> forked part of the daemon used to carry on the connection with
> its chronyc client, same 'lsof' output.
>
> COMMAND PID USER FD TYPE NODE NAME
>
> chronyd 3597 _chrony5u IPv4 UDP 127.0.0.1:323
> chronyd 3597 _chrony6u IPv6 UDP [::1]:323
> chronyd 3598 _chrony9u unix 0x type=SEQPACKET
> chronyc 3809johnd3u IPv4 UDP \
> 127.0.0.1:33911->127.0.0.1:323
>
> Appears that client failed socket open and fell back to a
> different approach which is using an IP loopback address.
>
> Investigated why socket open failed... by using 'strace -f chrony[c|d]'.
>
> For the chronyd v4.0 having opened a Debian-tweaked '/run/chrony/chrony.sock',
> I show the corresponding chronyc v4.0 version:
>
> $ chronyc -v
> chronyc (chrony) version 4.0 (+READLINE +SECHASH +IPV6 -DEBUG)
>
> And ran strace against this v4.0 client and grep'd for 'sock' word pattern:
>
> $ strace -f /usr/bin/chronyc
> socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
> unlink("/run/chrony/chronyc.3875.sock") = -1 EACCES (Permission denied)
>
> bind(3, {sa_family=AF_UNIX, sun_path="/run/chrony/chronyc.3875.sock"},
> 110) = -1 EACCES (Permission denied)
> getsockname(3, {sa_family=AF_UNIX}, [112->2]) = 0
> close(3)= 0
>
> socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
> connect(3, {sa_family=AF_INET, sin_port=htons(323),
> sin_addr=inet_addr("127.0.0.1")}, 16) = 0
>
> Noticed the 'PID' number being inserted into the
> '/run/chrony/chronyc.3875.sock'?
> This is the chronyc client doing "PID-sock" filenaming convention, whereas
> its daemon is doing a different "just-sock" filenaming convention.
The PID is included to have the ability to run multiple chronyc instances at
the same time. Nothing wrong with that.
> The v4.1 client does exactly the same.
>
> chronyc (chrony) version DEVELOPMENT (-READLINE -SECHASH +IPV6 +DEBUG)
>
> socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
> unlink("/var/run/chrony/chronyc.3885.sock") = -1 EACCES (Permission
> denied)
>
> bind(3, {sa_family=AF_UNIX,
> sun_path="/var/run/chrony/chronyc.3885.sock"}, 110) = -1 EACCES (Permission
> denied)
> getsockname(3, {sa_family=AF_UNIX}, [112->2]) = 0
> close(3)= 0
>
> socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
> connect(3, {sa_family=AF_INET, sin_port=htons(323),
> sin_addr=inet_addr("127.0.0.1")}, 16) = 0
> fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
> read(0, ^Cstrace: Process 3885 detached
>
>
> It would be nice to use consistent filenaming convention for the UNIX socket
> for both client and daemon.
Cheers,
Vincent
signature.asc
Description: PGP signature
Bug#995207: chrony: Using 'bindacqdevice' directive causes a SIGSYS error
Control: tags -1 - upstream + moreinfo Control: severity -1 important Hi, Le 2021-09-27 17:31, Steve Egbert a écrit : > Package: chrony > Version: 4.0-8 > Severity: critical > Tags: upstream > X-Debbugs-Cc: s.egb...@sbcglobal.net > > Dear Maintainer, > > > Wanted to use the 'bindacqdevice' due to my host having a dynamic IP > interface. > > Using that 'bindacqdevice' directive keyword anywhere in my > /etc/chrony/chrony.conf file results in a signal 31 (according to Linux > auditd). > > My guess is that attempts to do a Chrony as a NTP server (disbursing out > NTP beacons), we need to have an socket open on this dynamic IP interface. > > This is the setting of the systemd resource. > > Removing the 'bindacqdevice' directive, and all works perfectly. > > Was half-expecting to be able to use 'bindacqdevice' configuration directive > here. After having stopped chronyd, please run the command below when using the 'bindacqdevice' directive and attach the chronyd_debug.txt file. # strace -o chronyd_debug.txt chronyd -d -F -1 Cheers, Vincent signature.asc Description: PGP signature
Bug#994453: Bug confirmation
Le 2021-09-24 16:44, Alexander Kernozhitsky a écrit : > Hello, > > > Is it still reproducible when adding 'mem_encrypt=off' to the kernel command > > line? > > with `mem_encrypt=off` parameter, the kernel boots fine. Thanks for testing, Alexander! Jens-Michael, Gert, how does your system behave when disabling AMD Secure Memory Encryption? > -- > Alexander Kernozhitsky Cheers, Vincent signature.asc Description: PGP signature
Bug#994453: Bug confirmation
Hi, Le 2021-09-24 03:02, Alexander Kernozhitsky a écrit : > Control: found -1 5.14.6-2 > > I have just tried installing the kernel from unstable. After reboot, the > booting process just hung at the very early stage. Nothing was printed onto > the screen, and I cannot find the logs, as it happened during booting from > initramfs. > > The problem may be specific to Debian, as I tried booting openSUSE Tumbleweed > from LiveUSB with kernel 5.14.5, and it worked fine. > > I am using Lenovo Thinkpad E495 with AMD Ryzen 5 3500U CPU. Is it still reproducible when adding 'mem_encrypt=off' to the kernel command line? > -- > Alexander Kernozhitsky Cheers, Vincent signature.asc Description: PGP signature
Bug#924272: decopy: FTBFS (mv: cannot stat 'README.1': No such file or directory)
Package: decopy Version: 0.2.4.1-1 Followup-For: Bug #924272 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, The attached patch fixes this issue. Please apply! Cheers, Vincent -BEGIN PGP SIGNATURE- iQJLBAEBCgA1FiEE/VQBlxWoTJPh4vI5ipzudlpxp4AFAlyH9ZUXHHZpbmNlbnQu ZGViaWFuQGZyZWUuZnIACgkQipzudlpxp4DP/w/9FRwUyxTb4xR5wMWcRXYLSOwz 2I0M+L0sjiOEFGxMd/imKhm/ekOMYr8kS+wDHbkEVRhtDNDsES33s2DSJwVrV3Cm aRJJWPbDa/hH5QTkWbNthrST7gnGlhnMZb40MlJdnLgHHqy12mKnzgrP4ymyqSCZ +xtnMHvU/8LxVbVeFvujTFbpSLcxBguQWG+/ilEUh8/p/fzWkrbjssX+WCm+iNAu UxpQ0E+fH1qguPabqF88vaNLNvq39AymL/F/2BZqAYqPrQ1JOoQmvum0SzquMiO6 KPTC51J2UUfjNqKc0avESxVJdKlJw4KRyfFo4SePpG2tuvHLh//nfBlmJR7Plbxr qLNm0UxFCDJKrvlgPAUyLI4eMiEuGuR/kQTvst5yV6siuA0ExFKtAJpLx5VlYaPA 0Va+MpxCQ3uu70oQaeUUe2rDjLpu/hw1Nsma8tYS2asEFL1egEqDWBW3EtvHUEOh nHvHfcl3V4vyZ/dgqTZL3tIUw57WvIL6q0XeCFirYuxEcPIpt1Qs6OE9O9CjfqO6 v3ttOdfISBDksY0bd8CfW7rgpY8RcTOCGsy/rf3XcA5tpPbZatrGRPWsQc46Wx+B ps0jsEdqIC7mYzCsGTCFtE90VlPlq8uPQ8yuXXOTRyMB1+9wiJ2nTcL0ynFyAN+s 63iakMVP3MsuFTHrZYI= =7aks -END PGP SIGNATURE- >From 6a7f600b19b024e48fd38f1b1a9069d55a74c7ab Mon Sep 17 00:00:00 2001 From: Vincent Blut Date: Tue, 12 Mar 2019 18:36:49 +0100 Subject: [PATCH] Fix FTBFS due to incorrect filename Closes #924272 --- debian/rules | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/rules b/debian/rules index f5a0731..f50f790 100755 --- a/debian/rules +++ b/debian/rules @@ -8,8 +8,8 @@ override_dh_auto_build: dh_auto_build ronn README.md - mv README.1 decopy.1 - mv README.1.html decopy.1.html + mv README.md.1 decopy.1 + mv README.md.1.html decopy.1.html override_dh_auto_test: LC_ALL=C.UTF-8 dh_auto_test -- 2.20.1
Bug#870076: marked as done (src:chrony: maintainer address bounces)
On Sat, Jul 29, 2017 at 03:53:28PM -0400, Paul Gevers wrote: Hi, Hello Paul, On 29-07-17 10:15, Debian Bug Tracking System wrote: The maintainer address for chrony bounces, see below. Indeed, that seems to happen from time to time. Sadly, my provider remains silent about these issues. I’m naively closing the bug report in the hope that things will improve. As sponsor for Vincent, I vouch that indeed it can't be "failing for a long time" in general as I generally contact Vincent via that e-mail-address as well. Thanks you for your support. The issue is severe though. Vincent, is there any way to bug your provider a bit more? Sure, I will try again. I wonder if it is similar to my issues with my ISP where DKIM is broken in the BTS, i.e. my ISP puts responses that arrive via the BTS and that are DKIM signed in my SPAM box (including my own). According to the message reported by the MTA (all hosts for 'free.fr' have been failing for a long time…), it looks more like a temporary failure of the service provided by my ISP. Also my ISP doesn't respond to my queries. Seems to be common these days. :( Paul Cheers, Vincent signature.asc Description: PGP signature
Bug#802694: gnome-music: Missing dependency on python3-requests
Le jeu. 22 oct. 2015 à 19:40, Michael Biebl a écrit : Control: severity -1 serious Am 22.10.2015 um 18:56 schrieb Vincent Blut: Package: gnome-music Version: 3.18.0-1 Severity: important Hello, Could you please add a dependency on python3-requests to prevent the following trace: Traceback (most recent call last): File "/usr/bin/gnome-music", line 82, in from gnomemusic.application import Application File "/usr/lib/python3/dist-packages/gnomemusic/application.py", line 37, in from gnomemusic.window import Window File "/usr/lib/python3/dist-packages/gnomemusic/window.py", line 39, in from gnomemusic.player import Player, SelectionToolbar File "/usr/lib/python3/dist-packages/gnomemusic/player.py", line 50, in import requests ImportError: No module named 'requests' Thanks for your bug report. And thanks to you for your promptness Michael! Bumping severity to RC. My bad, I should have done so… -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#795096: nftables: Missing license in d/copyright.
Le mar. 11 août 2015 à 14:18, Arturo Borrero Gonzalez
a écrit :
Control: tags -1 + pending
On 10 August 2015 at 17:22, Vincent Blut
wrote:
The file from which the man page is generated ('doc/nft.xml') is
licensed under the terms of the CC BY-SA 4.0, so let’s add that to
'debian/copyright'. Patch attached!
Applied, thanks Vincent.
I mangled the commit message [0] a bit.
Perfect, thanks for your work on nftables, that’s greatly appreciated!
best regards.
Cheers,
Vincent
[0]
https://github.com/aborrero/pkg-nftables/commit/0fc181f9062e6128addf5dac57334067ea184b01
--
Arturo Borrero González
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#795096: nftables: Missing license in d/copyright.
Package: nftables
Version: 0.4-6
Severity: serious
Tags: patch
Justification: Policy 12.5
Hi Arturo,
The file from which the man page is generated ('doc/nft.xml') is
licensed under the terms of the CC BY-SA 4.0, so let’s add that to
'debian/copyright'. Patch attached!
Cheers,
Vincent
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages nftables depends on:
ii init-system-helpers 1.23
ii libc62.19-19
ii libgmp10 2:6.0.0+dfsg-7
ii libmnl0 1.0.3-5
ii libnftnl01.0.3-4
ii libreadline6 6.3-8+b3
nftables recommends no packages.
nftables suggests no packages.
-- no debconf information
>From 031929e6502671b782867ca82496c63bf9687116 Mon Sep 17 00:00:00 2001
From: Vincent Blut
Date: Mon, 10 Aug 2015 01:51:37 +0200
Subject: [PATCH] d/copyright: Fix missing license
Signed-off-by: Vincent Blut
---
debian/copyright | 371 +++
1 file changed, 371 insertions(+)
diff --git a/debian/copyright b/debian/copyright
index c16fb1c..c3967f3 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -47,6 +47,10 @@ Copyright: 1999 Andrea Arcangelli
2002 David Woodhouse
License: GPL-2+
+Files: doc/nft.xml
+Copyright: 2008-2014 Patrick McHardy
+License: CC-BY-SA-4.0
+
License: GPL-2
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU Library General Public License as published by
@@ -79,3 +83,370 @@ License: GPL-2+
.
On Debian systems, the complete text of the GNU General
Public License version 2 can be found in "/usr/share/common-licenses/GPL-2".
+
+License: CC-BY-SA-4.0
+ Creative Commons Attribution-ShareAlike 4.0 International
+ .
+ Creative Commons Corporation (“Creative Commons”) is not a law firm and does
+ not provide legal services or legal advice. Distribution of Creative Commons
+ public licenses does not create a lawyer-client or other relationship.
+ Creative Commons makes its licenses and related information available on an
+ “as-is” basis. Creative Commons gives no warranties regarding its licenses,
+ any material licensed under their terms and conditions, or any related
+ information. Creative Commons disclaims all liability for damages resulting
+ from their use to the fullest extent possible. Using Creative Commons Public
+ Licenses Creative Commons public licenses provide a standard set of terms and
+ conditions that creators and other rights holders may use to share original
+ works of authorship and other material subject to copyright and certain other
+ rights specified in the public license below. The following considerations
+ are for informational purposes only, are not exhaustive, and do not form part
+ of our licenses. Considerations for licensors: Our public licenses are
+ intended for use by those authorized to give the public permission to use
+ material in ways otherwise restricted by copyright and certain other rights.
+ Our licenses are irrevocable. Licensors should read and understand the terms
+ and conditions of the license they choose before applying it. Licensors
+ should also secure all rights necessary before applying our licenses so that
+ the public can reuse the material as expected. Licensors should clearly mark
+ any material not subject to the license. This includes other CC-licensed
+ material, or material used under an exception or limitation to copyright.
+ More considerations for licensors. Considerations for the public: By using
+ one of our public licenses, a licensor grants the public permission to use
+ the licensed material under specified terms and conditions. If the licensor’s
+ permission is not necessary for any reason–for example, because of any
+ applicable exception or limitation to copyright–then that use is not
+ regulated by the license. Our licenses grant only permissions under copyright
+ and certain other rights that a licensor has authority to grant. Use of
+ the licensed material may still be restricted for other reasons, including
+ because others have copyright or other rights in the material. A licensor
+ may make special requests, such as asking that all changes be marked or
+ described. Although not required by our licenses, you are encouraged to
+ respect those requests where reasonable. More considerations for the public.
+ .
+ Creative Commons Attribution-ShareAlike 4.0 International Public License
+ .
+ By exercising the Licensed Rights (defined below), You accept and agree
+ to be bound by the terms and conditions of this Creative Commons
+ Attribution-ShareAlike 4.0 International Public License ("Pu
Bug#720466: cinnamon: Crashes when opening the menu, using command window or hot corner
Hi, Well, same here. At first I thought it was due to the cogl transition (which just happened in Jessie), but I saw that Michael gives priority to sid so it's clearly not related to this transition. So I searched what changes were committed to cinnamon 1.7.4-2.1+b1, but I didn't find any changelog about this version. Cheers, Vincent -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Le samedi 19 janvier 2013 à 19:23 +0100, Vincent Blut a écrit : > > Am 10.01.2013 09:39, schrieb Riku Voipio: > > > > > getting hangs on anything other than the Debian 3.2.32-1 has > > > been challenging. If if's just timing based, I might just have > > > been lucky during my bisects. > > > > Here vanilla 3.4.24 from kernel.org runs absolutely stable since a few > > weeks. But me came up another idea: > > > > 'modinfo i916' list an option which appears to be a watchdog function: > > > > "parm: enable_hangcheck:Periodically check GPU activity for > > detecting hangs. WARNING: Disabling this can cause system wide hangs. > > (default: true) (bool)" > > > > which actually describes the symptoms. Could it be that in the > > Debian-kernel either the hangs are not detected securely, or that it > > just fails to reset the module? > > > > /Ingo > > Hi guys, > > Well I have the same issue on my Ivybridge system: > > $ lspci -nnv | grep VGA > 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core > processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA > controller]) > > $ cat /var/log/Xorg.0.log | grep "Graphics Chipset" > […] > [ 8.388] (II) intel(0): Integrated Graphics Chipset: Intel(R) Ivybridge > Mobile (GT2) > > On my system I observed this behavior: > > Debian 3.2.35-2: random hangs (at least one per day) > Upstream 3.2.37: random hangs (at least one per day) > Upstream 3.3-rc1+: no hangs (tested for 2 weeks) > > So that seems to be close to Riku's experience. > > Anyway what strikes me a bell is the last Ingo's comment about > 'enable_hangcheck' module parameter > which was introduced in v3.1-rc1: > > $ git tag --contains 6e96e7757a01 > v3.1-rc1 > […] > v3.8-rc4 > > So I peeked about what kind of "hangcheck" changes could have been introduced > in v3.3-rc1 > and I found an interesting patch: > > commit e6bfaf854272ec4641a9ef7b1cb1ca963031ba95 > drm/i915: don't bail out of intel_wait_ring_buffer too early > > The commit message is particularly interesting! > > I'll give it a try but if someone could beat me to it that would be cool (ULV > CPU here). Unfortunately this commit has no positive effect! I got two freezes in less than 15 minutes, so I set up an SSH connection in order to catch some logs but after an uptime of 5h30 the system froze… the NIC too so absolutely nothing useful to report :-( > > Cheers, > Vincent > > > PS: Also, could you give a try to Julien Cristau's kernel images with DRM/KMS > subsystem backported from 3.4 > which might hit Wheezy? > http://people.debian.org/~jcristau/linux-image-3.2.0-4.drm-amd64_3.2.35-3~jcristau.1_amd64.deb > sha1sum f6711fe6d0d924aab82ec82fe1a86102a69a8c32 > (There are i686 and i486 flavours if you want) > > -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
> Am 10.01.2013 09:39, schrieb Riku Voipio: > > > getting hangs on anything other than the Debian 3.2.32-1 has > > been challenging. If if's just timing based, I might just have > > been lucky during my bisects. > > Here vanilla 3.4.24 from kernel.org runs absolutely stable since a few > weeks. But me came up another idea: > > 'modinfo i916' list an option which appears to be a watchdog function: > > "parm: enable_hangcheck:Periodically check GPU activity for > detecting hangs. WARNING: Disabling this can cause system wide hangs. > (default: true) (bool)" > > which actually describes the symptoms. Could it be that in the > Debian-kernel either the hangs are not detected securely, or that it > just fails to reset the module? > > /Ingo Hi guys, Well I have the same issue on my Ivybridge system: $ lspci -nnv | grep VGA 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) $ cat /var/log/Xorg.0.log | grep "Graphics Chipset" […] [ 8.388] (II) intel(0): Integrated Graphics Chipset: Intel(R) Ivybridge Mobile (GT2) On my system I observed this behavior: Debian 3.2.35-2: random hangs (at least one per day) Upstream 3.2.37: random hangs (at least one per day) Upstream 3.3-rc1+: no hangs (tested for 2 weeks) So that seems to be close to Riku's experience. Anyway what strikes me a bell is the last Ingo's comment about 'enable_hangcheck' module parameter which was introduced in v3.1-rc1: $ git tag --contains 6e96e7757a01 v3.1-rc1 […] v3.8-rc4 So I peeked about what kind of "hangcheck" changes could have been introduced in v3.3-rc1 and I found an interesting patch: commit e6bfaf854272ec4641a9ef7b1cb1ca963031ba95 drm/i915: don't bail out of intel_wait_ring_buffer too early The commit message is particularly interesting! I'll give it a try but if someone could beat me to it that would be cool (ULV CPU here). Cheers, Vincent PS: Also, could you give a try to Julien Cristau's kernel images with DRM/KMS subsystem backported from 3.4 which might hit Wheezy? http://people.debian.org/~jcristau/linux-image-3.2.0-4.drm-amd64_3.2.35-3~jcristau.1_amd64.deb sha1sum f6711fe6d0d924aab82ec82fe1a86102a69a8c32 (There are i686 and i486 flavours if you want) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683576: epiphany-browser: No option available to delete/clear cookies
Le 06/08/2012 12:53, sat...@gmail.com a écrit : > > Nope, when you'll launch epiphany, its menu will be available on > the top GNOME Shell bar (with the new brand: 'Web'), click on it > and you'll find the 'Personal Data' menu section. > > > Works fine, Thanks Vincent!! > -- > Satheesh Kumar Mohan > You're welcome ;-) Regards, Vincent
Bug#683576: epiphany-browser: No option available to delete/clear cookies
Le 06/08/2012 07:14, sat...@gmail.com a écrit : > > > You will find the 'Personal Data' menu in gnome-shell's global > menu, click on it and you'll find all you want ;-) > > > Do you mean by Alt + F1 -> Search for "Personal Data" ? Searching > above returns/shows nothing. Is there anyway to launch it from run > command ( alt + f2) or gnome-terminal? > > -- > Satheesh Kumar Mohan > Nope, when you'll launch epiphany, its menu will be available on the top GNOME Shell bar (with the new brand: 'Web'), click on it and you'll find the 'Personal Data' menu section. Have a good day Satheesh, Vincent
Bug#683576: epiphany-browser: No option available to delete/clear cookies
notfound 683576 epiphany-browser/3.4.2-1 close 683576 thanks Hi, > Subject: epiphany-browser: No option available to delete/clear cookies > Package: epiphany-browser > Version: 3.4.2-1 > Justification: serious > Severity: serious Not really ;-/ > Tags: upstream > > Dear Maintainer, > >* What led up to the situation? > I am trying to clear/delete the cookies. >* What exactly did you do (or not do) that was effective (or > ineffective)? > The doc says, "Epiphany stores your cookies and passwords in the Personal > Data Manager which can be accessed by choosing Edit ▸ Personal Data." and > also says that I can view/delete my cookies using Personal Data Manager. I > couldn't find either the Edit menu or any other way to access/delete my > cookies using the settings (the only) menu available at the top right > corner of the browser. >* What outcome did you expect instead? > When many browsers even allow the ability to clear cookies on closing > the browser automatically, the browser had atleast some handy way to clear > the cookies which is no longer available now. You will find the 'Personal Data' menu in gnome-shell's global menu, click on it and you'll find all you want ;-) Cheers, Vincent -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#641018: Kernel-OOPS (sometimes) when using lsof
Package: linux-2.6 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Same issue here, it appears (to me) only when you call 'lsof' with unprivileged user. Obviously this behavior was introduced by the last security upgrade (2.6.32-35squeeze1). Dmesg (with the stack trace) is attached. - -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (800, 'stable-updates'), (800, 'stable'), (96, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk5qQEkACgkQbO4uEp7kOBPK9gCfVeoCh+/rj+Mb4TwBmFtrqjmX NbkAnA1hwxxWsgESfbPSFoOgb7oKopqF =9UhI -END PGP SIGNATURE- [ 4704.125330] BUG: unable to handle kernel paging request at fff3 [ 4704.125335] IP: [] m_stop+0x15/0x4c [ 4704.125342] PGD 1003067 PUD 1004067 PMD 0 [ 4704.125346] Oops: [#11] SMP [ 4704.125348] last sysfs file: /sys/devices/virtual/sound/timer/uevent [ 4704.125352] CPU 0 [ 4704.125353] Modules linked in: fuse firewire_sbp2 loop snd_ca0106 snd_seq_midi snd_seq_midi_event snd_rawmidi snd_ac97_codec ac97_bus snd_pcm snd_seq snd_timer snd_seq_device radeon arc4 ttm snd ecb soundcore rt2500pci drm_kms_helper snd_page_alloc rt2x00pci rt2x00lib led_class pcspkr edac_core edac_mce_amd k8temp mac80211 psmouse serio_raw evdev cfg80211 rfkill drm i2c_nforce2 i2c_algo_bit eeprom_93cx6 i2c_core button processor ext4 mbcache jbd2 crc16 sg sr_mod usbhid hid sd_mod crc_t10dif cdrom ohci_hcd ata_generic sata_sil pata_amd sata_nv fan firewire_ohci thermal firewire_core crc_itu_t thermal_sys sky2 libata ehci_hcd forcedeth scsi_mod usbcore nls_base [last unloaded: scsi_wait_scan] [ 4704.125398] Pid: 3166, comm: lsof Tainted: G D2.6.32-5-amd64 #1 MS-7125 [ 4704.125400] RIP: 0010:[] [] m_stop+0x15/0x4c [ 4704.125405] RSP: 0018:880094767e88 EFLAGS: 00010286 [ 4704.125407] RAX: 8131fad0 RBX: 880094767ed8 RCX: 00d07c574067 [ 4704.125410] RDX: ff00 RSI: fff3 RDI: 8800bc205a80 [ 4704.125412] RBP: 88003761b200 R08: 880094767e78 R09: [ 4704.125414] R10: 1000 R11: 811516f3 R12: fff3 [ 4704.125417] R13: fff3 R14: R15: 1000 [ 4704.125420] FS: 7fbcd63a1700() GS:88000180() knlGS: [ 4704.125422] CS: 0010 DS: ES: CR0: 80050033 [ 4704.125424] CR2: fff3 CR3: 947a6000 CR4: 06f0 [ 4704.125427] DR0: DR1: DR2: [ 4704.125429] DR3: DR6: 0ff0 DR7: 0400 [ 4704.125432] Process lsof (pid: 3166, threadinfo 880094766000, task 8800374c46a0) [ 4704.125434] Stack: [ 4704.125435] 1000 880094767ed8 8800bc205a80 81105aa9 [ 4704.125439] <0> 01b4fc98 880094767f50 01b4ec90 8800945e1000 [ 4704.125443] <0> 8800bc205ab8 8001 1000 [ 4704.125447] Call Trace: [ 4704.125451] [] ? seq_read+0x269/0x388 [ 4704.125456] [] ? vfs_read+0xa6/0xff [ 4704.125459] [] ? sys_read+0x45/0x6e [ 4704.125463] [] ? system_call_fastpath+0x16/0x1b [ 4704.125465] Code: 48 89 df e8 e3 c2 f1 ff 31 c0 40 84 ed 49 0f 45 c4 5b 5d 41 5c c3 55 53 48 83 ec 08 48 85 f6 48 8b 6f 60 74 1a 48 3b 75 10 74 14 <48> 8b 1e 48 8d 7b 60 e8 dd 86 f3 ff 48 89 df e8 ac c2 f1 ff 48 [ 4704.125489] RIP [] m_stop+0x15/0x4c [ 4704.125493] RSP [ 4704.125495] CR2: fff3 [ 4704.125497] ---[ end trace c010ebc4cf0d5b6d ]---
