Re: How long will this take?
On 6/9/2020 5:39 AM, Nicolas George wrote: How do you add "status=progress" to a process that has already been running for three days? You can't, of course. I was merely suggesting using this in future invocations. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message.
Re: How long will this take?
On 6/8/2020 11:01 PM, David Wright wrote: I, too, determine progress with # kill -USR1 I'd suggest simply adding "status=progress" which gives you a summary every second including bytes written, elapsed time, and average transfer rate. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message.
Re: USB HDD issue with buster-backports kernel
On 6/8/2020 10:56 AM, Christopher David Howie wrote: > * On the 5.5 kernel, I was getting throughput between 10MB/sec and > 20MB/sec. At apparently random points, dd would stop reporting any > progress and a "usb-storage" process in top would be consuming 100% > CPU. Any commands against the HDD (even smartctl) would hang until > the device was physically replugged. Also, I should mention: I only got this behavior when using the crypt container. If I ran dd with /dev/urandom against the raw partition, the throughput was much closer to 30MB/sec and the device never stopped responding. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message.
Re: USB HDD issue with buster-backports kernel
On 6/8/2020 11:38 AM, Andrei POPESCU wrote: > What about dmesg? Sorry, yes... I forgot to mention. dmesg was absolutely silent when the drive stopped responding. After unplugging it, I of course got a flood of errors from dm-crypt about being unable to write to the disk. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message. signature.asc Description: OpenPGP digital signature
Re: Firefox over JACK in Debian Testing
On 6/6/2020 11:25 PM, riveravaldez wrote: Hi, here's the thing: AFAIK Firefox lacks JACK support (in the sense that you can start JACK and then Firefox and then, automatically, all I/O audio-ports Firefox generated, appear as available JACK connections, let's say) Is there any Debian package that can serve this purpose? I have a JACK setup that runs all audio through Ardour so I can perform compression and EQ either system-wide or per-application. I accomplish this by using pulseaudio. If JACK is already running when pulseaudio starts, pulseaudio will create a single JACK sink and JACK source that redirects audio to/from a matching JACK source/sink. I then use the following script to create additional sinks in PA that each have an independent source in JACK: -- #!/bin/sh exec pactl load-module module-jack-sink \ client_name=pulse_sink_"$1" \ connect=no \ channels=2 -- Run like "./make-jack-sink music" which gives me a "music" PA sink connected to the "music" JACK source. You don't automatically get a JACK port per audio stream, but you can make as many separate PA sinks as your system can handle and use the PA volume control application to switch audio streams between different PA sinks (and therefore JACK sources). Then you can wire everything up on the JACK side, as usual. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message.
USB HDD issue with buster-backports kernel
Hello, I recently upgraded to the buster-backports kernel (5.5.17). After this upgrade I needed to prepare an external HDD (WD Elements 2TB) for encryption and so I used the "write zeroes to a plain crypto container" approach: # cryptsetup open --type plain -d /dev/urandom /dev/sde1 to_be_wiped # dd if=/dev/zero of=/dev/mapper/to_be_wiped bs=64K status=progress I verified that the container was properly aligned. I had drastically different results on the 5.5 kernel versus the buster 4.19 kernel: * On the 4.19 kernel, I was getting throughput between 30MB/sec and 50MB/sec. The operation completed successfully. * On the 5.5 kernel, I was getting throughput between 10MB/sec and 20MB/sec. At apparently random points, dd would stop reporting any progress and a "usb-storage" process in top would be consuming 100% CPU. Any commands against the HDD (even smartctl) would hang until the device was physically replugged. Since everything seems to work fine on 4.19 I do not suspect any issues with the drive itself. It seems there is some problem with the 5.5 kernel? What can I do to further troubleshoot this? -- lsusb -- Bus 005 Device 002: ID 8087:8000 Intel Corp. Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 8087:8008 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 003: ID 1058:25a2 Western Digital Technologies, Inc. Elements 25A2 Bus 004 Device 002: ID 1058:25a2 Western Digital Technologies, Inc. Elements 25A2 Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 004: ID 1058:1042 Western Digital Technologies, Inc. Elements SE Portable (WDBPCK) Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub --- The device in question is device 2 on bus 4. Buster kernel uname: Linux liz 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux Buster-backports kernel uname: Linux liz 5.5.0-0.bpo.2-amd64 #1 SMP Debian 5.5.17-1~bpo10+1 (2020-04-23) x86_64 GNU/Linux -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message.
Re: Backup Times on a Linux desktop
On 11/2/2019 3:24 PM, Konstantin Nebel wrote: Whoever read till the end Im thankful and ready to hear your opinion. I use restic (the static binaries from the Github release page, not the Debian package which falls out of date too quickly) and invoke it from crontab. On my LAN server, the script creates LVM snapshots of the volumes to back up and the backup runs against that to get a true point-in-time backup. The local backup repository is stored on a RAID1. A remote system regularly runs "rclone copy --immutable" to pull new data, but ignore deleted and changed data (preventing corruption/loss of data already copied off-site). The remote system also syncs its local copy to B2, so I have three geographically-distributed copies. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message.
Re: question about network connections
On 10/26/2019 8:35 AM, to...@tuxteam.de wrote: > Yep. Something along the lines of > > tcpdump -w data.pcap > > then scp that to your box and > > wireshark data.pcap > > Refinements, of course, possible :-) I'd also suggest giving tcpdump the name of either the internal or external interface with -i, because otherwise you're going to see duplicated packets -- which _could_ be helpful to figure out what is going on if a packet is not forwarded, but there is no annotation in the dump file for which interface a packet was received/sent on. You could wind up with a mess of packets and some may not even be physical interfaces (do you _need_ to also capture lo? probably not). Depending on the version of tcpdump, you may also need to set -s to some reasonable value, as I recall on older versions the default was not large enough to capture entire packets. Of course, if you don't need the whole payload then this might not matter. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message. signature.asc Description: OpenPGP digital signature
Re: GRUB not applying Intel Microcode?
On 10/23/2019 9:16 PM, Kyle K wrote: > In my grub.cfg I don't see anything that resembles "initrd > /intel-ucode.img /initrd.img-4.19.0-6-amd64". On Debian, microcode updates are embedded in the main initrd, not put in a secondary initrd. The /usr/share/initramfs-tools/hooks/intel_microcode script is responsible for adding the appropriate update files, scripts, and tools to the initrd. > 1. Is microcode getting applied? If you have this package installed and have rebooted since the last microcode update, then almost certainly. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message.
Re: dropbear-initramfs possible with open-iscsi during boot, using different NICs? [SOLVED]
On 10/22/2019 12:22 PM, Christopher David Howie wrote:
>> In a way, yes, but the kernel commandline is unsuitable for this.
>> What you need is a init-premount script (see initramfs-tools(7)) which
>> configures either second or both NICs with "ip" from busybox or
>> "udhcpc".
>
> Thanks for this pointer. I'll set up a scratch VM to experiment with
> these tools.
Alright, I got a working config and filed a bug report.
My test VM has a local SATA disk with two partitions: /boot and an
md-raid physical device. The iSCSI disk has one partition: an md-raid
physical device.
The raid PVs were combined to create an md-raid mirror. The mirror
contains a LUKS volume, which (when unlocked) holds an LVM PV. The /
volume and swap are LVs.
Here's the lsblk summary for those of us who process information
visually (sda is SATA, sdb is iSCSI):
8<
$ lsblk /dev/sd?
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:008G 0 disk
├─sda1 8:10 487M 0 part /boot
└─sda2 8:20 7.5G 0 part
└─md0 9:00 7.5G 0 raid1
└─md0_crypt 253:00 7.5G 0 crypt
├─vgtest-lvswap 253:10 952M 0 lvm [SWAP]
└─vgtest-lvroot 253:20 6.6G 0 lvm /
sdb 8:16 08G 0 disk
└─sdb1 8:17 08G 0 part
└─md0 9:00 7.5G 0 raid1
└─md0_crypt 253:00 7.5G 0 crypt
├─vgtest-lvswap 253:10 952M 0 lvm [SWAP]
└─vgtest-lvroot 253:20 6.6G 0 lvm /
8<
As mentioned before, the sticking point was wanting to run iSCSI and
dropbear-initramfs on two different NICs. The idea to use an initramfs
init-premount script was a good suggestion, and is what I ended up
doing. However, it was much easier to use ipconfig than either ip or
udhcpc -- particularly because the other initramfs scripts use ipconfig,
and ipconfig stores configuration state in /run in the initrd
environment meaning that multiple things trying to configure the network
won't stomp on each other. Rather, the first thing to run ipconfig
against an interface "wins."
So, I created /etc/initramfs-tools/scripts/init-premount/network with
the following contents, chmodded it +x, and rebuild the initramfs:
8<
#!/bin/sh
PREREQ=""
prereqs()
{
echo "$PREREQ"
}
case $1 in
prereqs)
prereqs
exit 0
;;
esac
# iSCSI interface
ipconfig 192.168.7.3:::255.255.255.0::ens4:static
# Internet-facing interface
ipconfig :ens3:dhcp
8<
This works like a charm. In /etc/network/interfaces, I simply leave out
configuration for these interfaces altogether and they remain configured
after the box comes up. (In a real environment I might still configure
the Internet-facing interface, but leave the iSCSI interface out because
we absolutely don't want that interface going away because some script
is mucking with ifupdown.)
One last caveat that I ran into is that open-iscsi shutdown scripts will
try to avoid closing the session for / by looking through several
layers, including LVM and crypto. However, md-raid is not considered at
all. Since the scripts didn't think that the iSCSI device was in use,
they closed the session during shutdown. This caused the iSCSI
partition to be kicked out of the mirror during shutdown, requiring a
manual "mdadm /dev/md0 --re-add missing" on every boot to fully
reassemble the array.
This was solved by setting ISCSI_ROOT_KEEP_ALL_SESSIONS_AT_SHUTDOWN=1 in
/etc/default/open-iscsi. I have also filed bug #943347, requesting that
open-iscsi skip stopping sessions for any devices that are in use by
md-raid during shutdown.
--
Chris Howie
http://www.chrishowie.com
http://en.wikipedia.org/wiki/User:Crazycomputers
If you correspond with me on a regular basis, please read this document:
http://www.chrishowie.com/email-preferences/
PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5
IMPORTANT INFORMATION/DISCLAIMER
This document should be read only by those persons to whom it is
addressed. If you have received this message it was obviously addressed
to you and therefore you can read it.
Additionally, by sending an email to ANY of my addresses or to ANY
mailing lists to which I am subscribed, whether intentionally or
accidentally, you are agreeing that I am "the intended recipient," and
that I may do whatever I wish with the contents of any message received
from you, unless a pre-existing agreement prohibits me from so doing.
This overrides any disclaimer or statement of confidentiality that may
be included on your message.
Re: Debian Installer, Manual Partitioning is a Joke
On 10/23/2019 10:37 AM, Wayne Sallee wrote: > Select "Partition disk" > > You will then see a number of options; one being guided partitioning, > but no option for manual partition. What? This screen _is_ the manual partition editor! The "guided" option is displayed here so you can go back and change your mind if you want to do guided partitioning after entering the manual editor. All of your disks and existing partitions are displayed here; if a disk is empty, select it and press enter to create a partition table. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message.
Re: Signs of hard drive failure?
On October 22, 2019 9:17:15 PM UTC, elvis wrote: >Raid is really simple, till something goes wrong :-) I reckon most data > >loss is from people taking wrong options to fix things from >inexperience >rather than raid losing the data. Also from the wrong assumption that RAID levels with redundancy are a substitute for backups. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Signs of hard drive failure?
On 10/22/19 1:01 PM, Ken Heard wrote: > smartctl considers my two hard drives three years old and > consequently prone to failure I'm not seeing that anywhere in the smartctl output. All of the information there suggests that there is nothing wrong with the drives. Where are you seeing these indications of failure in the smartctl output? -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message.
Re: Debian Installer, Manual Partitioning is a Joke
On 10/13/19 6:56 PM, Wayne Sallee wrote: > The non-graphical needs work too: > There's no manual partitioning option without going first to guided > partitioning This is patently false. Every Debian setup I have done in the last ten years I've done with manual partitioning in the text-mode installer. The option to do partitioning manually is among the guided options, you just have to select it. See the attached screenshot. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message.
Re: dropbear-initramfs possible with open-iscsi during boot, using different NICs?
On 10/22/19 2:57 AM, Reco wrote: >> Is there a supported way to configure two interfaces in the initrd to >> accomplish this? > > In a way, yes, but the kernel commandline is unsuitable for this. > What you need is a init-premount script (see initramfs-tools(7)) which > configures either second or both NICs with "ip" from busybox or > "udhcpc". Thanks for this pointer. I'll set up a scratch VM to experiment with these tools. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message.
dropbear-initramfs possible with open-iscsi during boot, using different NICs?
I have a system with dropbear-initramfs to unlock crypto containers during boot. The system has a second NIC that I will be using to attach iSCSI disks to the system, some of which / may wind up moving to. (/boot will remain attached locally.) It seems that there is support for iSCSI during boot, however it's not clear to me how to get the kernel to bring up _both_ NICs so that dropbear and open-iscsi can run on different ones. (Based on my research, the ip= kernel parameter can only be specified once.) Is there a supported way to configure two interfaces in the initrd to accomplish this? -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message.
Re: Screensaver issues after distro upgrade (SOLVED)
On 9/11/2019 7:01 PM, Miroslav Skoric wrote: > Well, I noticed that issue after I recently upgraded to Stretch, but not > had it in Jessie. Whatever. Having in mind that Stretch is oldstable for > a while, and you had the issue in Buster, it seems that the issue goes > through the versions intact :-) Yes, light-locker has not changed much recently and the threads I was able to find on the issue spanned many years and Linux distributions. Debian is not unique to have this problem. I believe this is the relevant bug. It may be useful to add any additional information beyond what has already been reported there: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913062 Perhaps the problem is hardware-specific. It doesn't seem like everyone has this problem, so there must be something our systems all have in common to trigger this. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message.
Re: black screen (only mouse visible) after resume with xfce4 on kernel 5.2.0
On 9/11/2019 9:58 AM, Andrea Borgia wrote: > unlock xfce4, stare at mouse pointer alone on a black screen If this is the same problem I had (and discussed prior on this list), there is a bug in light-locker that seems to cause this behavior randomly even without hibernation. Consider switching from light-locker to xscreensaver; this resolved the problem for me. If it resolves the problem for you as well then I would hesitate to say immediately that it's a kernel bug, even if the kernel version is somehow related to the problem. See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913062 -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message.
Re: Screensaver issues after distro upgrade
On 9/10/19 4:30 AM, Miroslav Skoric wrote: > After upgrading the old laptop from Jessie to Stretch, I noticed that > the screensaver in Mate environment does not work for me as before. For > example, when the screen goes black after some time of inactivity, for > returning back it is not enough just to touch the touchpad or press any > key. Instead, pressing any key or touching the touchpad makes the screen > just some 1% lighter than the full black (or better to say, it remains > 99% black). However, the last working GUI does not return. I have this same issue with the default configuration of XFCE on Buster, where the problem was not present on Stretch. Is light-locker installed, and do you use lightdm? light-locker appears to be the source of this issue. Googling "light-locker black screen" returns dozens of posts across many sites complaining about the same problem. I resolved this issue by removing light-locker and installing xscreensaver instead. Note that this required removing a few metapackages, and then marking the dependent packages that I wanted to keep as manually installed to prevent apt from removing most of my desktop tools. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am "the intended recipient," and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message.
Re: System freeze during boot with nvidia GPU on jessie
On 03/23/2014 10:31 PM, Christopher David Howie wrote: I have an Nvidia GeForce GTX 760 card, and I've been unable to get this card working correctly in jessie, including even booting the system after installing. The system hangs at Waiting for /dev to be fully populated unless I specify the nomodeset kernel parameter. Blacklisting nouveau does not keep the system from freezing without nomodeset. Modprobing nouveau or the proprietary driver, or trying to start X with both modules blacklisted will immediately freeze the system. I am not sure how to go about diagnosing this problem, but it seems that the kernel (3.13) is not terribly happy with this video card in general. After fiddling with an... ahem... particular Debian-based distribution's live CD, I was able to figure out what the problem was. When booting this CD, the system would appear to boot normally, but when I would expect to be dumped into a desktop environment, both monitors turned off instead... what I would expect to see if the desktop were being displayed on some other monitor... Long story short, my motherboard's onboard Intel GPU was enabled in addition to the PCI-e nVIDIA GPU. Disabling the onboard GPU has resolved all of the problems I was experiencing. In fact, it's entirely possible that the onboard display was being activated. I didn't think of this because in Debian the attached monitors would still display whatever they last were displaying. Perhaps the system just wasn't completely deactivating the nVIDIA GPU, and so they displayed whatever they were, forever. I may turn the onboard GPU back on and attach a monitor to it to satisfy my curiosity. -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers If you correspond with me on a regular basis, please read this document: http://www.chrishowie.com/email-preferences/ PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5 IMPORTANT INFORMATION/DISCLAIMER This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it. Additionally, by sending an email to ANY of my addresses or to ANY mailing lists to which I am subscribed, whether intentionally or accidentally, you are agreeing that I am the intended recipient, and that I may do whatever I wish with the contents of any message received from you, unless a pre-existing agreement prohibits me from so doing. This overrides any disclaimer or statement of confidentiality that may be included on your message. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/532fdaf1.3000...@chrishowie.com
System freeze during boot with nvidia GPU on jessie
Hello, I am not subscribed to this list so please CC me on replies (and quote this line so others know to as well). Also I was not sure if jessie issues belong here or on the debian-testing list, but the latter doesn't have very much activity at all and appears to be geared more towards install/upgrade issues. If debian-user is the wrong list I have no problem going there. I have an Nvidia GeForce GTX 760 card, and I've been unable to get this card working correctly in jessie, including even booting the system after installing. The system hangs at Waiting for /dev to be fully populated unless I specify the nomodeset kernel parameter. Blacklisting nouveau does not keep the system from freezing without nomodeset. Modprobing nouveau or the proprietary driver, or trying to start X with both modules blacklisted will immediately freeze the system. I am not sure how to go about diagnosing this problem, but it seems that the kernel (3.13) is not terribly happy with this video card in general. Any suggestions would be much appreciated. If there is other information I can gather let me know. -8- # lspci -vnn 00:00.0 Host bridge [0600]: Intel Corporation 4th Gen Core Processor DRAM Controller [8086:0c00] (rev 06) Subsystem: Gigabyte Technology Co., Ltd Device [1458:5000] Flags: bus master, fast devsel, latency 0 Capabilities: [e0] Vendor Specific Information: Len=0c ? 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller [8086:0c01] (rev 06) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: d000-db0f Capabilities: [88] Subsystem: Gigabyte Technology Co., Ltd Device [1458:5000] Capabilities: [80] Power Management version 3 Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [a0] Express Root Port (Slot+), MSI 00 Capabilities: [100] Virtual Channel Capabilities: [140] Root Complex Link Capabilities: [d94] #19 Kernel driver in use: pcieport 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06) (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd Device [1458:d000] Flags: fast devsel, IRQ 16 Memory at db40 (64-bit, non-prefetchable) [size=4M] Memory at c000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06) Subsystem: Intel Corporation Device [8086:2010] Flags: bus master, fast devsel, latency 0, IRQ 46 Memory at db834000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Kernel driver in use: snd_hda_intel 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 04) (prog-if 30 [XHCI]) Subsystem: Gigabyte Technology Co., Ltd Device [1458:5007] Flags: bus master, medium devsel, latency 0, IRQ 42 Memory at db82 (64-bit, non-prefetchable) [size=64K] Capabilities: [70] Power Management version 2 Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ Kernel driver in use: xhci_hcd 00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04) Subsystem: Gigabyte Technology Co., Ltd Device [1458:1c3a] Flags: bus master, fast devsel, latency 0, IRQ 44 Memory at db83f000 (64-bit, non-prefetchable) [size=16] Capabilities: [50] Power Management version 3 Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+ Kernel driver in use: mei_me 00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I217-V [8086:153b] (rev 04) Subsystem: Gigabyte Technology Co., Ltd Device [1458:e000] Flags: bus master, fast devsel, latency 0, IRQ 41 Memory at db80 (32-bit, non-prefetchable) [size=128K] Memory at db83d000 (32-bit, non-prefetchable) [size=4K] I/O ports at f080 [size=32] Capabilities: [c8] Power Management version 2 Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
