Bug#1089513: New 535.230.02 release

I found the release notes under https://www.nvidia.com/en-us/drivers/details/238990/ and tab "Release Highlights"

Bug#1089513: New 535.230.02 release

If I have understood the release note of the today released Nvidia 535.230.02 version correctly, this bug should be fixed by it. Here are the release notes Updated the kernel module build process to use CONFIG_CC_VERSION_TEXT from the Linux kernel's Kconfig to detect the compiler used to buil

Bug#918322: initramfs-tools: kernel fails to boot with "Gave up waiting for root file system device"

On Sat, 5 Jan 2019 22:30:27 +0100 Michael Biebl wrote: > Am 05.01.19 um 22:09 schrieb Axel Ludszuweit: > > Hello Michael, > > > > yes, I am willing to try your package tomorrow, but I have the following > > questions: > > - in the initramfs rescue shell the k

Bug#918322: initramfs-tools: kernel fails to boot with "Gave up waiting for root file system device"

On Sun, 6 Jan 2019 11:53:49 + =?UTF-8?Q?Jakub_Soko=C5=82owski?= wrote: > I suspect this might be hardware related since I saw another person having > the same issue on a forum, and were both using motherboards using Intels X99 > chipset. I also use a motherboard with X99 chipset, manufact

Bug#918322: initramfs-tools: kernel fails to boot with "Gave up waiting for root file system device"

On Sat, 5 Jan 2019 21:41:35 +0100 Michael Biebl wrote: > Hi Axel! > > Am 05.01.19 um 21:33 schrieb Axel Ludszuweit: > > I have read bug > > > > #917607: udev240 makes system unbootable; rootfs not found > > > > Because my working and failing initrd fil

Bug#918322: More info

On Sat, 05 Jan 2019 19:39:59 + Ben Hutchings wrote: > Control: tag -1 moreinfo > > On Sat, 5 Jan 2019 02:22:33 + Jakub Sokołowski > wrote: > > Seems like I failed to add additional info: > > > > Picture of error: > https://mega.nz/#!LehDlKbB!x_pFGX3wlq-Kgo6v5jUC6ydbqTQ4R43bft7mAC6j_ms >

Bug#918322: initramfs-tools: kernel fails to boot with "Gave up waiting for root file system device"

I have read bug #917607: udev240 makes system unbootable; rootfs not found Because my working and failing initrd files contain different udev versions, the failing one udev240, it may be possible, that this is the cause of failed boot. Bug #917607 description sounds very similar to beh

Bug#918322: More info

Same behaviour here. Booting ends in initramfs rescue shell. Keyboard inputs are not possible. The root directory uses btrfs as filesystem. I have compared the contents of - /boot/initrd.img-4.18.0-3-amd64 (working) - /boot/initrd.img-4.19.0-1-amd64 (failed) with the folling results:

Bug#848242: libnvidia-glcore: version 375.20 causes mpv to crash (Was: mpv crashes with libnvidia-glcore.so.375.20)

Dear Maintainer, I want to reproduce my error, to get the mpv output in terminal, which you need But now, its work. I have no explanation for this behavior, I can't remember, to change everything between the failing and working execution of mpv. I used the same file, no updates and no booting betw

Bug#848242: mpv crashes with libnvidia-glcore.so.375.20

Package: mpv Version: 0.22.0-1 Severity: normal Dear Maintainer, after upgrade to nvidia-driver 375.20 mpv crashes with the following error message shown by journalctl: kernel: mpv/vo[6182]: segfault at 80 ip 7fd9630239f5 sp 7fd965367cf8 error 6 in libnvidia-glcore.so.375.20[7fd962396000

Bug#788050: systemd-fsck : Check disks at each reboot

Hi, On Tue, 1 Dec 2015 23:23:52 +0100 Manuel Bilderbeek wrote: > Hi, > > On 29-11-15 01:28, Michael Biebl wrote: > > Does the problem go away if you use "systemctl mask > > systemd-fsckd.service systemd-fsckd.socket" > > Yes, it does. Using this I got to see the following while booting, which

Bug#791829: no passphrase prompt

Dear maintainer, in my opinion the bug is not solved. If I start my VPN connection via - systemctl start openvpn@my_connection no password/user question appears. If I start the connection via - /usr/sbin/openvpn --cd /etc/openvpn --config /etc/openvpn/my_connection.conf passwort/user request wo

Bug#788050: systemd-fsck : Check disks at each reboot

Dear Maintainer, I have converted my ext3 filesystem to ext4 to reduce time needed by fsck. But the behaviour is still unchanged, fsck of big partition fails. -- Axel Ludszuweit In der Horst 28E D-30900 Wedemark Telefon: +49 (0) 5130 373093 Mobil: +49 (0) 170 2736589

Bug#788050: systemd-fsck : Check disks at each reboot

Dear maintainer, according to the suggestion from message #65 I have increased the timeout to 30min. But fsck still ends with error 13 checking big partitions. Manually fsck ends succeesfully. It seems to be the same behaviour described in message #70.

Bug#788050: (no subject)

Dear maintainer, Konsole output axel@kruemel:~$ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.1.0-2-amd64 root=/dev/mapper/OS_1-root ro axel@kruemel:~$ Therefore I think, that I am not using the splash option. Plymouth is not installed. Maybe the fstab is helpful: Konsole output axel@kruemel:~$

Bug#788050: systemd-fsck : Check disks at each reboot

Dear maintainer, I also think there is is a timeout problem. I Use lvm2 with md software raid based on ext3. Systemd file system checks at boot-up on small partitions finish successfull on big partitions end with error 13. Manual executed file system check on these big partitions end successful

Bug#793026: kwin-x11: kwin is not started

> > that does appear to work. > > I've checked here and adding the symlink should be sufficient. I've reopened > this bug out of the several to cover it. Once the current kwin upload > migrates, I'll upload another revision that adds it. > > Scott K > > -- Axel Ludszuweit -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#793026: fixed in kwin 4:5.3.2-3

ble; urgency=high > . > [ Maximiliano Curia ] > * kwin-wayland: Add qtwayland5 dependency, for the wayland qt5 plugin. > . > [ Scott Kitterman ] > * Urgency high for RC but fix in testing > * Remove obsolete kwin alternative and add new alternative for kwin_x11 so > kwin wi

Bug#666928: Subject: udev: cant access scripts on /usr partition

f packages udev recommends: ii pciutils 1:3.1.8-2 ii usbutils 1:005-2 udev suggests no packages. -- debconf information: udev/new_kernel_needed: false udev/sysfs_deprecated_incompatibility: udev/title/upgrade: udev/reboot_needed: -- Axel Ludszuweit mailto:axel.ludszuw...@htp-tel.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#541145: Disable graphical terminal speeds up boot time

Package: grub-pc Version: 1.97~beta3-1 Severity: normal I have the same problem descibed by the bug creator. After disable graphical terminal only ~10 seconds needed between - Welcome Grub message and - boot select menu. The grub minimal shell does not appear any more. The /usr directory needed

Bug#541145: After disable graphic mode speed increase

Package: grub-pc Version: 1.97~beta3-1 Severity: normal I have the same speed problems described by the bug report creator. After disable graphical mode the speed increases significant. Between Welcome to Gub message and menu only some seconds needed, the grub shell does not appear any more. The

Bug#523503: kernel-image-2.6: Unbalanced enable for IRQ 16

Package: kernel-image-2.6 Version: linux-image Severity: normal Since two weeks I get a kernel oops message and dmesg shows the following information: snip - [6.632957] Unbalanced enable for IRQ 16 [6.632999] [ cut here ]-

Bug#433103: linux-image-2.6.21-2-686: Non GPL closed source drivers accepted

Package: linux-image-2.6.21-2-686 Version: 2.6.21-5 Severity: important After upgrading to linux-image-2.6.21-2-686 I cant compile drivers with closed source parts, in my case a fax driver for a old AVM ISDN pci card, because the kernel does not accecpt non GPL drivers. I get the following error

Bug#433101: exim4: non-ascii value in smarthost entry

Package: exim4 Version: 4.67-5 Severity: normal After upgrading to exim4 version 4.67-5 I get the following error message: - graf-zahl:/etc/exim4# /usr/sbin/update-exim4.conf /usr/sbin/update-exim4.conf: non-ascii value ${lookup{${address:$h_from:[EMAIL PROTECTED]/etc/exim4/smarthosts}} r

Bug#426117: exim4: unable to connect /var/run/clamav/clamd.ctl, but /var/run/clamav/clamd.ctl...

Hi Marc, yes its ok for me to clone and reassign to clamav-daemon. Thank you, for your help. Greetings Axel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#426117: exim4: unable to connect /var/run/clamav/clamd.ctl, but /var/run/clamav/clamd.ctl exists

Hi Marc, Here somee lines from /var/log/exim4/paniclog: -- snip - 2007-06-14 19:38:23 1HytH5-0001rX-8e malware acl condition: clamd: unable to connect to UNIX socket /var/run/clamav/clamd .ctl (No such file or directory) ( -- sn

Bug#426117: exim4: unable to connect /var/run/clamav/clamd.ctl, but /var/run/clamav/clamd.ctl exists

Marc Haber wrote: > On Sun, May 27, 2007 at 03:52:20PM +0200, Axel Ludszuweit wrote: >> Marc Haber wrote: > Connect "manually" to the clamav socket and talk directly to the > daemon. A helper program like socat should do the trick. If you cannot > do this due to lac

Bug#426117: exim4: unable to connect /var/run/clamav/clamd.ctl, but /var/run/clamav/clamd.ctl exists

Marc Haber wrote: > On Sat, May 26, 2007 at 02:10:07PM +0200, Axel Ludszuweit wrote: > What happens when you connect to the daemon from a shell? Are the > privileges on the directory OK? Please can you explain me, what do you mean with "connect to the daemon from a shell" But

Bug#426117: exim4: unable to connect /var/run/clamav/clamd.ctl, but /var/run/clamav/clamd.ctl exists

Package: exim4 Version: 4.63-17 Severity: normal Hello community, I have the below described behaviour on my Debian testing installation. I use the exim4 mail packet with the clamd virus scanner, spam assassin and fetchmail. After booting I get the following messages in file /var/log/exim4/pani

Bug#393006: The problem is kdesu not synaptic

I Think, the error is caused by kdesu and not by synaptic. - su -c "/usr/sbin/synaptic" works and - kdesu -c "/usr/sbin/synaptic" fails with the message wrong password. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#393006: After last update I can not start synaptic because the valid root passwort is not accepted.

Package: synaptic Version: 0.57.11 Severity: important If I want to start synaptic as non root user, I get the message that the password is wrong. This error occurs after my last update today. But the used password is ok, for example su works with the used password. -- System Information: Debian

Bug#337070: winbind: same malfunction here

Package: winbind Version: 3.0.20b-2 Followup-For: Bug #337070 After upgrading from winbind (3.0.14a-6) to 3.0.20b-2 and samba (3.0.14a-6) to 3.0.20b-2 I have the same behaviour. Additonally here the contents of the /var/log/samba/log.winbind file: [2005/11/05 21:14:34, 1] nsswitch/winbindd.c:ma