Bug#397774: apache2.2-common: Support mod_auth_ldap to mod_aunthz_ldap migration. Or at least warn!
Hi, i also stumbled over this apache ldap feature. require valid-user only works if you set AuthzLDAPAuthoritative off (found in http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html.en#reqvaliduser). So my solutions looks as follows: Directory /xxx AuthName Password AuthType Basic AuthBasicProvider ldap AuthLDAPUrl ldap://127.0.0.1:389/dc=dom,dc=com?uid?sub?(objectClass=*) AuthLDAPBindDN searchdn AuthLDAPBindPassword AuthzLDAPAuthoritative off require valid-user /Directory Alternative you can use require ldap-user thisuser onotheruser. require ldap-user without a username doesn't work! -- greetings eMHa pgpMVpdV2mFaG.pgp Description: PGP signature
Bug#390862: -bigmem version of xen kernels is really needed
great :-) so i can hope i've not to build my own xen-pae kernels when etch will be stable. -- greetings eMHa pgpFTBjuSC94N.pgp Description: PGP signature
Bug#419994: Missing memory in Xen due to wrong detection of e820 memory map in grub
Hi, i had the same problem and found a bug report on https://bugzilla.redhat.com/show_bug.cgi?id=250299 . My solution for Debian 4.0, for others who hit this problem: apt-get source grub apt-get build-dep grub cd grub-0.97/ cp -a stage2/common.c stage2/common.c.original vi stage2/common.c diff stage2/common.c.original stage2/common.c 145c145,146 unsigned long cont, memtmp, addr; --- unsigned long memtmp, addr; volatile unsigned long cont; debian/rules binary dpkg -i ../grub_0.97-27_i386.deb grub-install /dev/sda grub-install /dev/sdb After reboot all memory is seen by the xen hypervisor. -- greetings eMHa pgpvU11WHCHAG.pgp Description: PGP signature
Bug#306197: eject key doesn't work anymore
Package: ikeyd Version: 0.5.8 eject key with ikeyd doesn't work anymore. it's a little time ago when i recognized that. but now i've taken the time to analyze the problem. the patch/result/answer is as follows: # diff ikeyd.c.original ikeyd.c 258a259,260 last_keycode = 0; count = 0; 260,261d261 last_keycode = 0; count = 0; because last_keycode and count where only used for ejecting the cdrom we can reset the values only in the functions responsible for ejecting. i noticed that my eject key (by still holding down the key) is also sending release codes so the count of 15 where never reached. also the last_keycode was always 0. i think my patch is a clean solution for this problem. I don't know exactly when this behavior has happened the first time. -- System Information: Debian Release: sarge Architecture: powerpc Kernel: Linux enterprise 2.6.8-powerpc #1 Sun Mar 20 14:09:41 CET 2005 ppc Versions of packages ikeyd depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries and Timezone -- Gruß \|/ eMHa (o o) --oOO--U--OOo-- Markus Hochholdinger e-mail mailto:[EMAIL PROTECTED] .oooO www http://www.hochholdinger.net( ) Oooo. --\ (( )- \_)) / (_/
Bug#401073: redhat-cluster-source: does not repackage gnbd-kernel
hi there, perhaps the reason is that gnbd-kernel doesn't build against kernel 2.6.18? The problem is, that devfs was removed from the kernel. So i checked the source an with the following diff (removing devfs parts) i can compile the gnbd.ko and it works very well: $ cd redhat-cluster-1.03.00 $ diff gnbd-kernel/src/gnbd.c.original gnbd-kernel/src/gnbd.c 33d32 #include linux/devfs_fs_kernel.h 848d846 .devfs_name = gnbd_ctl, 929d926 devfs_mk_dir(gnbd_minor); 985d981 sprintf(disk-devfs_name, gnbd_minor/%d, i); 1039d1034 devfs_remove(gnbd); $ It would be nice to find this gnbd kernel module in redhat-cluster-modules and just another manual compile would disappear for me. Thx :-) -- greetings eMHa pgp1ZMknPkeqd.pgp Description: PGP signature
Bug#428685: kernel bugs when running xen in HVM mode
Hi, have you tried to set dom0 memory to a fixed value? Perhaps the explanation in this bug could help: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414040 The message Error: Device 5696 (vbd) could not be connected. Backend device not found. can occur if the device is (still) in use. I've found this sometimes if a domU was not normally shutdown. Possible solutions: + kill processe(s) accessing this device + restart xend + if a block device has really a problem (io blocking) you have to reboot -- greetings eMHa pgpq3u4MM0pCs.pgp Description: PGP signature
Bug#414040: kernel: xen_net: Memory squeeze in netback driver.
Hi, you have to limit dom0 memory on two places, xen hypervisor option and xend config. In this example below I limit memory to 256MB: /boot/grub/menu.lst 87c87 # xenhopt= --- # xenhopt=dom0_mem=256M /etc/xen/xend-config.sxp 120c120 (dom0-min-mem 196) --- (dom0-min-mem 256) After changing /boot/grub/menu.lst you have to run update-grub and reboot the machine. After changing /etc/xen/xend-config.sxp you have to restart xend with /etc/init.d/xend restart. With this I have no more problems with my netback driver on my ~10 dom0s running plain Debian 4.0. (My biggest machine has a uptime of over 45 days and handles ~20 domUs. Also a lot of live migration are happening to and from this host.) So for me this bug doesn't renders package unusable. I'm very happy with the xen packages from Debian 4.0 so i can setup a whole bunch of dom0s in a very short time. -- greetings eMHa pgp2ScEjE6ynq.pgp Description: PGP signature
Bug#478267: libnss-ldapd: Only return part of the group list
Hi, yesterday i had a very similar problem. With id $user i didn't get all the groups the user is in. Logged in as $user id returns all the groups. It took me a while to notice that only newly created groups (and not groups with highest group id) weren't displayed with id $user. For me it turns out that the sizelimit 500 option in slapd.conf was too low for my setup. Increasing the sizelimit helped me (it seems i exceed now 500 groups). In contrast, twiddling with the pagesize in /etc/libnss-ldap.conf didn't helped much. If also set to 500 i didn't get any groups with id $user anymore except his default group. (Where can i find detailed explanation of this pagesize option?) So my assumption is, that if you log in as $user all groups where particular checked for membership so you are effectiv in all groups. And with id $user all groups where get and after that the membership is checked within the result. I don't know if this matches exactly the reported problem, but perhaps its useful for someone else. -- greetings eMHa pgppRpABMqXx2.pgp Description: PGP signature
Bug#566740: iscsitarget-source: Module does not compile against 2.6.32 kernel (squeeze)
Hello, i also would like to have this patch included in the squeeze version. -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#534978: clock drift in Xen domU with clocksource=xen
Hi, Am 23.02.2010 um 22:36 Uhr schrieb Moritz Muehlenhoff j...@inutil.org: On Tue, Feb 23, 2010 at 02:06:41PM +0100, Markus Hochholdinger wrote: Here is my solution to this problem, lenny xen kernel: * dom0 with clocksource=jiffies and /proc/sys/xen/independent_wallclock=0 * domU with clocksource=jiffies and /proc/sys/xen/independent_wallclock=0 * ntpdate/ntp only in dom0, NOT in the domUs [..] It would be nice if you could add this information to http://wiki.debian.org/Xen I've just added this as workaround #2. For me, there're no problems so far. -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#534978: clock drift in Xen domU with clocksource=xen
Hi, [..] In my case this manifested itself when some PHP profiling via microtime() suddenly became useless, and it also caused occasional PostgreSQL errors with tables that had timestamp columns as keys, since it became possible for two independent transactions to come in at the exact same time. have you any service like ntp running on these boxes!? What will the app do if ntp corrects the time!? -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#534978: clock drift in Xen domU with clocksource=xen
Hello, Am 04.03.2010 um 17:24 Uhr schrieb Josip Rodin j...@debbugs.entuzijast.net: On Thu, Mar 04, 2010 at 05:21:31PM +0100, Markus Hochholdinger wrote: In my case this manifested itself when some PHP profiling via microtime() suddenly became useless, and it also caused occasional PostgreSQL errors with tables that had timestamp columns as keys, since it became possible for two independent transactions to come in at the exact same time. have you any service like ntp running on these boxes!? What will the app do if ntp corrects the time!? NTP always corrects time in a very subtle manner (see its documentation). I guess it's possible for it to screw with this, yet it never has. for me, i try to only run ntp on the dom0 and no ntp on the domus. I never had a problem with this running 2.6.18 as dom0 and i never had a problem with this running 2.6.26 as dom0. With older xen kernels (i believe it was 2.6.16) i had a problem that the domU clock went wrong while the dom0 clock was correct, so at this time i changed independent_wallclock to 1 and setup ntp in the domU. Some of this domUs run till today with independent_wallclock 1 and ntp inside the domU without problems. Another note about stability: Since linux-image-2.6-xen-686 (2.6.26-20, october 2009) my dom0s with the lenny dom0 kernel are stable and had no crashes (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542250). Now i try to use this kernel as domU kernel, but till now (2.6.26-22) it isn't stable enough for me, see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534880 . Also some combination of java, debian 3.1 and kernel doesn't work with 2.6.26. java segfaults, but only when started with 2.6.26 and not when startet with 2.6.18. Also the same java version on older or newer debian system works. So for now i will use 2.6.18 (redhat xen flavor) for my domUs. Also linux-image-2.6.32-4-686 seems very good as domU, but i only made a short test: live migration works, mem-set works and detach and attach of a block device works as expected. -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#534978: clock drift in Xen domU with clocksource=xen
Here is my solution to this problem, lenny xen kernel: * dom0 with clocksource=jiffies and /proc/sys/xen/independent_wallclock=0 * domU with clocksource=jiffies and /proc/sys/xen/independent_wallclock=0 * ntpdate/ntp only in dom0, NOT in the domUs I tested it the following way: While changing the time in the dom0 with date and/or hwclock doesn't change the time in the domU. But changing the time in the dom0 with ntpdate/ntpd changes the time in the domU. While ntpd is running in the dom0, I can change the time in the domU with date (hwclock --show in the domU prints nothing), but within 5 minutes, the time in the domU will be automatically corrected to the dom0 time. It seems ntp does this, because if i don't have a ntpd running in the dom0, the changed time in the domU wouldn't correct itself. Hope this helps somebody. If this setup is stable for me for a few weeks, perhaps I'll write it to http://wiki.debian.org/Xen#A.27clocksource.2BAC8-0.3ATimewentbackwards.27 . I still don't understand why ntp on the dom0 can change the time in the domU, while date and hwclock doesn't!? But it works as I expect it. -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#593648: grub-pc install fails on RAID1 (unknown filesystem)
Hi, I've here a similiar problem. After rebooting a 2.6.32-5-amd64 machine with raid1 grub wasn't able to boot the system. Last Messages where like Welcome to grub and then falls back to grub rescue shell. I've booted with a squeeze installer cd into rescue mode and found out that installing grub onto /dev/md0 solved my problem. Retesting this with dpkg-reconfigure grub-pc I've choosen sda and sdb to install grub and the system wasn't able to boot again. Doing the same dpkg-reconfigure grub-pc and choosing /dev/md0 (which is also available) makes my system boot again. For now I'm unsure if I also should install onto sda and sdb. I'll stick to /dev/md0 only and will test if I can still swap sda and sdb to boot successfully. Hope this helps someone. -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#593648: grub-pc install fails on RAID1 (unknown filesystem)
Hi, I've just investigated some more time. If I boot from a squeeze cd in rescue mode and let rescue mode put me in a shell on /dev/md0 I can run grub-install /dev/md0 and I'm able to boot from hard disk. After booting from hard disk and again running grub-install /dev/md0 I'm again not able to boot from the hard disk with the message: ---8- GRUB loading. Welcome to GRUB! error: no such disk. Entering rescue mode... grub rescue ---8- What is the different from the shell in rescue mode than the shell from the normally booted system? Why ist grub-install behaving different? I already tried to enter bash first in rescue mode before doing grub-install /dev/md0. I also tried to unset LANG from the normally booted system before executing grub-install /dev/md0. Nothing changes. -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#593648: grub-pc install fails on RAID1 (unknown filesystem)
Hi again, sorry for the noise, but I have to correct this. I've now a reason why the installing of grub fails although I don't know why. The server in question is also running a iscsi initiator (open-iscsi) and these devices are shown as sdc, sdd, .. It seems this confuses grub-install. Booted from cd in rescue mode, open-iscsi isn't running and all works fine. I've now discovered that stopping open-iscsi before executing grub-install /dev/md0 in the normally booted systems works correctly. I'm able to reboot afterwards normally. -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#526695: linux-image-2.6.26-2-xen-amd64: 64-Bit dom0 can't save/migrate 32-Bit domU
Package: linux-image-2.6.26-2-xen-amd64 Version: 2.6.26-15 Severity: normal Using the linux kernel from xen.org it is possible to save/migrate a 32-bit domU on a 64-bit dom0. With the lenny kernel it is not possible! The error message in /var/log/xen/xend.log: [2009-04-30 09:58:15 5118] INFO (XendCheckpoint:373) All memory is saved [2009-04-30 09:58:15 5118] ERROR (XendCheckpoint:144) Save failed on domain dns3 (1). Traceback (most recent call last): File /usr/lib/xen-3.2-1/lib/python/xen/xend/XendCheckpoint.py, line 112, in save forkHelper(cmd, fd, saveInputHandler, False) File /usr/lib/xen-3.2-1/lib/python/xen/xend/XendCheckpoint.py, line 361, in forkHelper raise XendError(%s failed % string.join(cmd)) XendError: /usr/lib/xen-3.2-1/bin/xc_save 5 1 0 0 1 failed [2009-04-30 09:58:36 5118] DEBUG (XendDomainInfo:1897) XendDomainInfo.destroy: domid=1 See also http://readlist.com/lists/lists.xensource.com/xen-users/4/24225.html To make it clear that it seems to be a issue with the dom0 kernel i've tested a plain Debian 5.0 installation as dom0 (xen-linux-system-2.6.26-2-xen-amd64) only with packages from Debian 5.0. Changing only the dom0 kernel to the kernel from xen.org live migration is possible! Another workaround is to use a 64-bit hypervisor on a 32-bit dom0 (http://lists.xensource.com/archives/html/xen-users/2008-12/msg00404.html). -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-2-xen-amd64 depends on: ii initramfs-tools 0.92o tools for generating an initramfs ii linux-modules-2.6.26-2-xen-am 2.6.26-15 Linux 2.6.26 modules on AMD64 linux-image-2.6.26-2-xen-amd64 recommends no packages. Versions of packages linux-image-2.6.26-2-xen-amd64 suggests: ii grub 0.97-47lenny2 GRand Unified Bootloader (Legacy v pn linux-doc-2.6.26 none(no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578578: sun-java6: crypto policy configuration files violate Debian policy
Hello, I've now testet: sudo dpkg-divert --rename /usr/lib/jvm/java-6-sun-1.6.0.20/jre/lib/security/local_policy.jar sudo dpkg-divert --rename /usr/lib/jvm/java-6-sun-1.6.0.20/jre/lib/security/US_export_policy.jar out of the README.Debian (6.20-dlj-4), but I tested this for Debian 5.0.4, so I had to use: dpkg-divert --rename /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security/local_policy.jar dpkg-divert --rename /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security/US_export_policy.jar After aptitude safe-upgrade the directory /usr/lib/jvm/java-6-sun-1.6.0.12 vanished and in /usr/lib/jvm/java-6-sun-1.6.0.20/jre/lib/security/ the files from the debian package were used. My changed files local_policy.jar and US_export_policy.jar were deleted! So I assume this workaround doesn't work if the version of java (like here 1.6.0.12 to 1.6.0.20) changes. (It's very dangerous because you notice the change only after the java vm is restartet. This can happen long after the upgrade of java, so the java developers will be puzzled what's suddenly wrong!) Isn't it possible to put these two files in /etc/java-6-sun/security/ , like the file cacerts, and symlink? With this I'll be asked if I want to overwrite my changes or not, with cacerts this works very well! Apropos configuration files in /etc, the file /etc/java-6-sun/security/cacerts doesn't seem to look well in vi, so i suppose local_policy.jar and US_export_policy.jar could be also there. Upstream - cacerts, local_policy.jar and US_export_policy.jar ARE in the same dirctory (lib/security/)! -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#586303: linux-image-2.6.32-5-vserver-amd64: Kernel Bug after upgrade from 2.6.32-3 to 2.6.32-5
Hi, I was hit by the same bug. I have also a bonding-vlan-bridge setup. After installing linux-image-2.6.32-5-amd64_2.6.32-18_amd64.deb (and linux-base_2.6.32-18_all.deb) from unstable the NULL pointer dereference is gone. Thank you for the good work :-) -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#580649: qemu-kvm: Guests hang after live migration
Hi, this is just a me too. Using 0.12.4+dfsg-1 migration is very unstable. With 0.11 I didn't get it down. When could we expect a new debian release with this fix? -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#580649: qemu-kvm: Guests hang after live migration
0.12.5+dfsg-1 solved the problem for me. Many Thanks! :-) -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#542250: repeatable crashes while copying 500G from NFS
Hello, in my case, the workaround to limit dom0-cpus=1 makes my dom0s stable. But i can't migrate (--live) any domUs any more. Also shutdown/halt of a domU hangs after shutdown/halt. This doesn't happen with dom0-cpus=0. Can anyone tell where to find 2.6.26-20? Till now i didn't find this on stable-proposed-updates. -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#613448: Use-after-free bug parsing wildcards in sudoers
Hello, I think I'm also hit by this bug. I've the command /srv/*/tomcat/tomcat in my sudoers and randomly some users complain, they can't execute the command while others can. For me it would be nice if this patch could go to the lenny (oldstable) sudo package. -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#599161: xen-linux-system-2.6.32-5-xen-amd64: Clock moved forward 50 minutes, caused Xen HVM domU restart
Hello, I can confirm that there are problems with the clock in PV domUs. I've setups like as follows: * Debian lenny dom0s running Debian squeeze and Debian lenny domUs (PV) * Debian squeeze doms running Debian squeeze and Debian lenny domUs (PV) I only have clock/time problems with my squeeze domUs. They use 2.6.32-5-amd64 and 2.6.32-5-686 kernels from Debian squeeze. It doesn't matter if they run on lenny (2.6.26-*-xen-686) or squeeze (2.6.32-*-xen-686) dom0s. With my Debian lenny dom0s I've set clocksource=jiffies and my lenny domUs also have clocksource=jiffies and independent_wallclock set to 0. All is fine here. I've running ntpd on the dom0s and the domUs use the time from the dom0s. (I've tested to change the time in the dom0 and the time change also show up in the domUs.) so I've no Problems with lenny domUs and time. With debian squeeze there's no clocksource jiffies anymore, so I use the default clocksource=xen in squeeze doms and squeeze domUs. Also there's no independent_wallclock anymore. So here's the problem I see: The time in my squeeze domUs is running slightly slower than the time on my dom0. Changing the time on the dom0 doesn't change the time in the squeeze domUs. But I can run ntpdate/ntp in my squeeze domUs and time gets correct. I'm wondering if I can set the former behavior of the domU clock to use the dom0s clock? -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#599161: xen-linux-system-2.6.32-5-xen-amd64: Clock moved forward 50 minutes, caused Xen HVM domU restart
Hello, Am 25.09.2011 um 20:23 Uhr schrieb Ian Campbell i...@hellion.org.uk: On Sun, 2011-09-25 at 15:09 +0200, Markus Hochholdinger wrote: I can confirm that there are problems with the clock in PV domUs. [..] I'm wondering if I can set the former behavior of the domU clock to use the dom0s clock? I'm afraid that the old dependent wallclock mode is not available with the upstream kernel so no. The current recommendation is to run ntpd in your guests. many thanks for this information. I'm now going to install and configure ntpd in all my domUs with squeeze-Kernel. -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#603832: grub-common: Xen hypervisor not default after installation
Hello, I just also stumbled over this bug. I suggest: mv /etc/grub.d/20_linux_xen /etc/grub.d/09_linux_xen update-grub Could the order be changed in the package grub-common? -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#664088: mdadm fails to initialize components for bitmap
Hello Michael, Am 12.04.2012 um 21:38 Uhr schrieb Michael Tokarev m...@tls.msk.ru: On 31.03.2012 01:28, Markus Hochholdinger wrote: Package: mdadm Version: 3.2.3-2 Followup-For: Bug #664088 Dear Maintainer, seems I've been stumbled over this bug. I'm running wheezy and can reproduce a crash: mdadm --grow /dev/md0 --bitmap=none mdadm --grow /dev/md0 --bitmap=internal A few seconds after this, the system is still alive, I see the newly created bitmap in /proc/mdstat, and then the system crashes: [ 342.437949] md0: bitmap file is out of date (0 322) -- forcing full recovery [ 342.437967] created bitmap (1 pages) for device md0 [ 347.949946] BUG: unable to handle kernel NULL pointer dereference at 0008 [ 347.949969] IP: [eda5edbd] bitmap_endwrite+0x138/0x199 [md_mod] [ 347.949991] *pdpt = 02660007 *pde = [ 347.950010] Oops: [#1] SMP Oh. This is a kernel bug, kernel should not crash like this even if incorrect bitmap is created. Marcus, what's your kernel version? Linux 3.2.0-2-686-pae from wheezy. Hm, perhaps I could use mdadm from squeeze to check weather the kernel also crashes. -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#664088: mdadm fails to initialize components for bitmap
Hello Michael, Am 12.04.2012 um 22:28 Uhr schrieb Michael Tokarev m...@tls.msk.ru: On 13.04.2012 00:22, Markus Hochholdinger wrote: Am 12.04.2012 um 21:38 Uhr schrieb Michael Tokarev m...@tls.msk.ru: On 31.03.2012 01:28, Markus Hochholdinger wrote: Package: mdadm Version: 3.2.3-2 Followup-For: Bug #664088 Dear Maintainer, seems I've been stumbled over this bug. I'm running wheezy and can reproduce a crash: mdadm --grow /dev/md0 --bitmap=none mdadm --grow /dev/md0 --bitmap=internal A few seconds after this, the system is still alive, I see the newly created bitmap in /proc/mdstat, and then the system crashes: [ 342.437949] md0: bitmap file is out of date (0 322) -- forcing full recovery [ 342.437967] created bitmap (1 pages) for device md0 [ 347.949946] BUG: unable to handle kernel NULL pointer dereference at 0008 [ 347.949969] IP: [eda5edbd] bitmap_endwrite+0x138/0x199 [md_mod] [ 347.949991] *pdpt = 02660007 *pde = [ 347.950010] Oops: [#1] SMP Oh. This is a kernel bug, kernel should not crash like this even if incorrect bitmap is created. Marcus, what's your kernel version? Linux 3.2.0-2-686-pae from wheezy. This was obvious from your initial message, but I wasn't clear. I meant to ask what kernel PACKAGE version is that. oh, sorry. The installed kernel package is: ii linux-image-3.2.0-2-686-pae 3.2.12-1Linux 3.2 for modern PCs ii linux-image-686-pae 3.2+44 Linux for moder I still can reproduce this: mdadm --grow /dev/md0 --bitmap=none mdadm --grow /dev/md0 --bitmap=internal And a few seconds later, the kernel crashes. Sigh, how many times I suggested kernel folks to include debian package version in the kernel OOPs test, but has been ignored every time... :( I understand and will include kernel package versions in the future. Hm, perhaps I could use mdadm from squeeze to check weather the kernel also crashes. I doubt it is easily reproducible. The original bug in mdadm (which is fixed upstream btw, in git, not any released version) does not initialize It's sad, that there's no released version of mdadm which fixes this issue. bitmap, leaving some garbage in it. Obviously not every garbage triggers the bug in kernel. So if another attempt will not crash your kernel it does not tell anything. Well, I can clearly reproduce this behaviour. I asked for the kernel package version in order to clone and reassign this bugreport to kernel properly. Wow, that would be very kind of you! So I'll do a little try and error, perhaps it helps for the kernel bugreport: * I've done aptitude update aptitude safe-upgrade now and rebooted. * Still using mdadm (3.2.3-2) and linux-image-3.2.0-2-686-pae (3.2.12-1). Doing mdadm --grow /dev/md0 --bitmap=none and mdadm --grow /dev/md0 --bitmap=internal still crashes the kernel as reported in this bug. * Now using (a very old) statically linked mdadm (v2.6.7 - 6th June 2008) which I used successful for years removing and making raid1 bitmaps. Doing mdadm.static --grow /dev/md0 --bitmap=none and mdadm.static --grow /dev/md0 --bitmap=internal works as expected and the kernel doesn't crash. * Using mdadm.static to remove the bitmap and mdadm to add it also crashes the kernel. * (mdadm from squeeze has a dependency problem with initscripts, so I can't simple use this version.) So far so good. Hope it helps a little. Now I will try this with arch amd64 instead of i386... -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#664088: mdadm fails to initialize components for bitmap
Hello Michael, I can reproduce this with Linux 3.2.0-2-amd64 (3.2.12-1) and mdadm (3.2.3-2): mdadm --grow /dev/md0 --bitmap=none mdadm --grow /dev/md0 --bitmap=internal And a few seconds later the kernel reboots: [ 75.119802] md0: bitmap file is out of date (0 147) -- forcing full recovery [ 75.119817] created bitmap (1 pages) for device md0 [ 80.797978] BUG: unable to handle kernel NULL pointer dereference at 0010 [ 80.797996] IP: [a00272c1] bitmap_endwrite+0x131/0x18f [md_mod] [ 80.798013] PGD 0 [ 80.798020] Oops: [#1] SMP [ 80.798028] CPU 0 [ 80.798032] Modules linked in: fuse evdev snd_pcm snd_page_alloc snd_timer snd soundcore pcspkr ext3 mbcache jbd raid1 md_mod xen_netfront xen_blkfront [ 80.798070] [ 80.798075] Pid: 0, comm: swapper/0 Not tainted 3.2.0-2-amd64 #1 [ 80.798086] RIP: e030:[a00272c1] [a00272c1] bitmap_endwrite+0x131/0x18f [md_mod] [ 80.798102] RSP: e02b:8800ffe5ec88 EFLAGS: 00010046 [ 80.798109] RAX: RBX: 8800031835c0 RCX: 0888 [ 80.798117] RDX: RSI: 0088 RDI: 8800031835c0 [ 80.798124] RBP: 01103d50 R08: R09: [ 80.798132] R10: 0246 R11: 0246 R12: 0008 [ 80.798140] R13: 8800031835fc R14: 880003180078 R15: 0001 [ 80.798154] FS: 7f9fe4ac57c0() GS:8800ffe5b000() knlGS: [ 80.798165] CS: e033 DS: ES: CR0: 8005003b [ 80.798172] CR2: 0010 CR3: f48cc000 CR4: 2660 [ 80.798181] DR0: DR1: DR2: [ 80.798189] DR3: DR6: 0ff0 DR7: 0400 [ 80.798198] Process swapper/0 (pid: 0, threadinfo 8160, task 8160d020) [ 80.798207] Stack: [ 80.798211] 0246 880003183678 0001c2b0 [ 80.798227] 8800032f0040 8800f57c00c0 88000309c3c0 8800032f2e48 [ 80.798243] 000b 8800030a54d0 a0006808 [ 80.798258] Call Trace: [ 80.798263] IRQ [ 80.798273] [a0006808] ? close_write+0x71/0x7d [raid1] [ 80.798284] [a0009677] ? r1_bio_write_done+0x1e/0x37 [raid1] [ 80.798295] [a00097a8] ? raid1_end_write_request+0x118/0x134 [raid1] [ 80.798309] [81006670] ? xen_force_evtchn_callback+0x9/0xa [ 80.798320] [81006c52] ? check_events+0x12/0x20 [ 80.798331] [811965e8] ? blk_update_request+0x18c/0x30a [ 80.798341] [8119677e] ? blk_update_bidi_request+0x18/0x63 [ 80.798351] [81197a0c] ? __blk_end_bidi_request+0xe/0x27 [ 80.798361] [81197a3f] ? __blk_end_request_all+0x1a/0x23 [ 80.798371] [a794] ? blkif_interrupt+0x23f/0x2ae [xen_blkfront] [ 80.798384] [81090581] ? handle_irq_event_percpu+0x50/0x180 [ 80.798394] [81070733] ? arch_local_irq_restore+0x7/0x8 [ 80.798405] [81062441] ? hrtimer_get_next_event+0x79/0x8f [ 80.798414] [810906e5] ? handle_irq_event+0x34/0x53 [ 80.798425] [81219206] ? ack_dynirq+0x17/0x2e [ 80.798435] [81092b21] ? handle_edge_irq+0xa2/0xc9 [ 80.798446] [81218f25] ? __xen_evtchn_do_upcall+0x157/0x1f2 [ 80.798457] [8106b8b3] ? arch_local_irq_restore+0x7/0x8 [ 80.798468] [8121a548] ? xen_evtchn_do_upcall+0x22/0x32 [ 80.798480] [813502be] ? xen_do_hypervisor_callback+0x1e/0x30 [ 80.798488] EOI [ 80.798496] [810013aa] ? hypercall_page+0x3aa/0x1000 [ 80.798505] [810013aa] ? hypercall_page+0x3aa/0x1000 [ 80.798515] [8100663a] ? xen_safe_halt+0xc/0x13 [ 80.798525] [810144fc] ? default_idle+0x47/0x7f [ 80.798535] [8100d252] ? cpu_idle+0xaf/0xf2 [ 80.798545] [816aab3d] ? start_kernel+0x3bd/0x3c8 [ 80.798554] [816ac64a] ? xen_start_kernel+0x590/0x596 [ 80.798561] Code: 77 0a 01 e1 48 8b 04 24 66 8b 10 ff ca 66 83 fa 02 66 89 10 77 2e 48 8b 4b 20 48 89 ee 48 89 df 83 e9 09 48 d3 ee e8 f9 f4 ff ff 48 8b 40 10 48 8b 53 58 8d 04 85 01 00 00 00 0f ab 02 c7 43 78 [ 80.798665] RIP [a00272c1] bitmap_endwrite+0x131/0x18f [md_mod] [ 80.798678] RSP 8800ffe5ec88 [ 80.798683] CR2: 0010 [ 80.798691] ---[ end trace 96c25711b3dbe8e9 ]--- [ 80.798697] Kernel panic - not syncing: Fatal exception in interrupt [ 80.798705] Pid: 0, comm: swapper/0 Tainted: G D 3.2.0-2-amd64 #1 [ 80.798712] Call Trace: [ 80.798716] IRQ [81342930] ? panic+0x95/0x1a5 [ 80.798731] [81070733] ? arch_local_irq_restore+0x7/0x8 [ 80.798741] [81349e86] ? oops_end+0xa9/0xb6 [ 80.798750] [8134227c] ? no_context+0x1ff/0x20e [ 80.798760] [8102bac8] ? pvclock_clocksource_read+0x42/0xb2 [
Bug#664088: mdadm fails to initialize components for bitmap
Hello karme, Am 13.04.2012 um 13:56 Uhr schrieb ka...@karme.de: I see the same? / similar problems. I removed the internal bitmap by accident. First I couldn't add a internal bitmap anymore later i got a kernel panic. for me, adding the bitmap works, but the kernel crashes afterwards. After rebooting the machine, the raid1 has a bitmap, but will do (need) a complete rebuild. Didn't have the time to really inspect this but found this one regarding the kernel bug part: http://www.spinics.net/lists/raid/msg37940.html myself using kernel: ii linux-image-3.2.0-2-amd643.2.12-1 Linux 3.2 for 64-bit PCs greetings, karme PS: i think this is a regression Yeah, I think also this is a regression. I'm using raid1 bitmaps, including removing and adding bitmaps for raid1 resizing, more than 5 years without problems. The crash is a kernel bug, but is triggered with mdadm from wheezy. PPS: would really help me if this gets fixed as i rely on the bitmap feature to sync my laptop to an external usb disk before leaving home If you use a older version of mdadm, it shouldn't crash the kernel. -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#664088: mdadm fails to initialize components for bitmap
Hello karme, Am 13.04.2012 um 14:50 Uhr schrieb Markus Hochholdinger mar...@hochholdinger.net: Am 13.04.2012 um 13:56 Uhr schrieb ka...@karme.de: [..] PPS: would really help me if this gets fixed as i rely on the bitmap feature to sync my laptop to an external usb disk before leaving home If you use a older version of mdadm, it shouldn't crash the kernel. I just compiled mdadm from squeeze and linked it static (on a squeeze system): cd /usr/local/src/ apt-get source mdadm apt-get build-dep mdadm cd mdadm-* diff Makefile.original Makefile 87,88c87,88 # LDFLAGS = -static # STRIP = -s --- LDFLAGS = -static STRIP = -s debian/rules binary With the resulting binary I have successful removed and added a raid1 bitmap within a wheezy system without kernel crash or reboot. -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#664088: mdadm fails to initialize components for bitmap
Package: mdadm Version: 3.2.3-2 Followup-For: Bug #664088 Dear Maintainer, seems I've been stumbled over this bug. I'm running wheezy and can reproduce a crash: mdadm --grow /dev/md0 --bitmap=none mdadm --grow /dev/md0 --bitmap=internal A few seconds after this, the system is still alive, I see the newly created bitmap in /proc/mdstat, and then the system crashes: [ 342.437949] md0: bitmap file is out of date (0 322) -- forcing full recovery [ 342.437967] created bitmap (1 pages) for device md0 [ 347.949946] BUG: unable to handle kernel NULL pointer dereference at 0008 [ 347.949969] IP: [eda5edbd] bitmap_endwrite+0x138/0x199 [md_mod] [ 347.949991] *pdpt = 02660007 *pde = [ 347.950010] Oops: [#1] SMP [ 347.950024] Modules linked in: fuse evdev snd_pcm snd_page_alloc snd_timer snd soundcore pcspkr ext3 mbcache jbd raid1 md_mod xen_netfront xen_blkfront [ 347.950090] [ 347.950098] Pid: 0, comm: swapper/0 Not tainted 3.2.0-2-686-pae #1 [ 347.950116] EIP: 0061:[eda5edbd] EFLAGS: 00010046 CPU: 0 [ 347.950130] EIP is at bitmap_endwrite+0x138/0x199 [md_mod] [ 347.950141] EAX: EBX: c2a4f080 ECX: c2a4f080 EDX: [ 347.950152] ESI: 00d0 EDI: EBP: c2a2d1a0 ESP: c13dfdd8 [ 347.950163] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0069 [ 347.950173] Process swapper/0 (pid: 0, ti=c13de000 task=c13e4fe0 task.ti=c13de000) [ 347.950185] Stack: [ 347.950191] 01a039f8 c2a4f0a4 c2a400a4 0001c608 c25b7880 c2a4f080 [ 347.950229] ea6be2ec eda396ca 0008 0001 c25b7880 ea51b540 [ 347.950266] c28a5c44 eda3c22b c25b7880 eda3c33c c28a5c44 000d [ 347.950303] Call Trace: [ 347.950316] [eda396ca] ? close_write+0x6a/0x78 [raid1] [ 347.950331] [eda3c22b] ? r1_bio_write_done+0x1b/0x32 [raid1] [ 347.950346] [eda3c33c] ? raid1_end_write_request+0xfa/0x10d [raid1] [ 347.950364] [c10ebf0c] ? bio_endio+0x22/0x23 [ 347.950380] [c114cdb3] ? blk_update_request+0x142/0x2a5 [ 347.950394] [eda2946d] ? do_blkif_request+0x33a/0x35c [xen_blkfront] [ 347.950409] [c114cf27] ? blk_update_bidi_request+0x11/0x4e [ 347.950424] [c114df73] ? __blk_end_bidi_request+0xf/0x26 [ 347.950438] [c114dfa3] ? __blk_end_request_all+0x19/0x22 [ 347.950452] [eda29705] ? blkif_interrupt+0x208/0x26a [xen_blkfront] [ 347.950470] [c10774d0] ? handle_irq_event_percpu+0x47/0x158 [ 347.950484] [c1077602] ? handle_irq_event+0x21/0x37 [ 347.950498] [c10792e2] ? handle_edge_irq+0x7f/0x98 [ 347.950514] [c11c2615] ? __xen_evtchn_do_upcall+0x126/0x1ad [ 347.950529] [c11c3874] ? xen_evtchn_do_upcall+0x18/0x26 [ 347.950544] [c12c5857] ? xen_do_upcall+0x7/0xc [ 347.950558] [c10023a7] ? hypercall_page+0x3a7/0x1000 [ 347.950573] [c100609a] ? xen_safe_halt+0xf/0x19 [ 347.950587] [c1010d6c] ? default_idle+0x52/0x87 [ 347.950601] [c100b22f] ? cpu_idle+0x95/0xaf [ 347.950615] [c141e708] ? start_kernel+0x32a/0x32f [ 347.950628] [c1420014] ? xen_start_kernel+0x58b/0x592 [ 347.950638] Code: 02 66 89 45 00 77 38 8b 4b 10 89 d8 8b 7c 24 04 8b 34 24 83 e9 09 0f ad fe d3 ef f6 c1 20 0f 45 f7 89 f2 e8 a5 f5 ff ff 8b 53 34 8b 40 08 8d 04 85 01 00 00 00 0f ab 02 c7 43 44 00 00 00 00 8b [ 347.950851] EIP: [eda5edbd] bitmap_endwrite+0x138/0x199 [md_mod] SS:ESP 0069:c13dfdd8 [ 347.950876] CR2: 0008 [ 347.950887] ---[ end trace 4852e9eea21e040c ]--- [ 347.950898] Kernel panic - not syncing: Fatal exception in interrupt [ 347.950910] Pid: 0, comm: swapper/0 Tainted: G D 3.2.0-2-686-pae #1 [ 347.950922] Call Trace: [ 347.950934] [c12bc219] ? panic+0x4d/0x144 [ 347.950949] [c12c1e2a] ? oops_end+0x8e/0x99 [ 347.950961] [c12bbd16] ? no_context+0x14b/0x155 [ 347.950975] [c12bbe34] ? bad_area_nosemaphore+0xa/0xc [ 347.950989] [c12c37c4] ? do_page_fault+0x15d/0x2fc [ 347.951002] [c10060da] ? xen_force_evtchn_callback+0xc/0x10 [ 347.951016] [c1006740] ? check_events+0x8/0xc [ 347.951029] [c1006737] ? xen_restore_fl_direct_reloc+0x4/0x4 [ 347.951046] [c105d572] ? arch_local_irq_restore+0x6/0x7 [ 347.951060] [c1032370] ? try_to_wake_up+0x14b/0x155 [ 347.951074] [c12c3667] ? notify_page_fault+0x37/0x37 [ 347.951087] [c12c17ff] ? error_code+0x67/0x6c [ 347.951103] [eda5edbd] ? bitmap_endwrite+0x138/0x199 [md_mod] [ 347.951118] [eda396ca] ? close_write+0x6a/0x78 [raid1] [ 347.951132] [eda3c22b] ? r1_bio_write_done+0x1b/0x32 [raid1] [ 347.951146] [eda3c33c] ? raid1_end_write_request+0xfa/0x10d [raid1] [ 347.951161] [c10ebf0c] ? bio_endio+0x22/0x23 [ 347.951173] [c114cdb3] ? blk_update_request+0x142/0x2a5 [ 347.951187] [eda2946d] ? do_blkif_request+0x33a/0x35c [xen_blkfront] [ 347.951202] [c114cf27] ? blk_update_bidi_request+0x11/0x4e [ 347.951216] [c114df73] ? __blk_end_bidi_request+0xf/0x26 [ 347.951229] [c114dfa3] ? __blk_end_request_all+0x19/0x22 [ 347.951243] [eda29705] ? blkif_interrupt+0x208/0x26a [xen_blkfront] [ 347.951258]
Bug#664088: mdadm fails to initialize components for bitmap
Hello, for me there are no problems anymore using: ii linux-image-3.2.0-2-686-pae 3.2.15-1Linux 3.2 for modern PCs ii linux-image-3.2.0-2-amd64 3.2.15-1Linux 3.2 for 64-bit PCs ii mdadm3.2.3-2 tool to administer Linux MD arrays (software RAID) I can do mdadm --grow /dev/md0 --bitmap=none mdadm --grow /dev/md0 --bitmap=internal now and the kernel keeps running. -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#701744: [xen] Update to hypervisor 4.0.1-5.6 or linux-image-2.6.32-5-xen-amd64 2.6.32-48 causes networking (VIF) failures
Hello, I was also hit by this problem. Perhaps it is related to the xen-netback module in the dom0 kernel? Have a look at: http://www.gossamer-threads.com/lists/xen/devel/275548 -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#702046: xen-utils-4.0: PyGrub VM Boot fails after xen-utils 4.0.1-5.6 - 4.0.1-5.7 Update
Hello, many thanks, this bug report and the debdiff helped me to boot a domU after the upgrade! -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#620098: [virtualbox-ose] Crash while guest screen resolution is changed (i.e. gdm started).
I encountered the same problem. After a lot of try and error I've found out that changing the audio host driver from PulseAudio to Alsa-Audio it suddenly worked! Perhaps some sounds were played while starting X? -- greetings eMHa signature.asc Description: This is a digitally signed message part.
Bug#1031860: kmail with akonadi stops working after security-upgrade of '*mariadb*'
Hi, I encountered the same issue and found the culprit: https://bugs.archlinux.org/task/71471 https://github.com/mariadb-corporation/mariadb-connector-c/commit/ a37b7c3965706f9a062baaba0c494dd6efb2c306 https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/sqldrivers/mysql/ qsql_mysql.cpp#n1279 I created the attached patch mariadb_lib.c.patch with the information from the above link and rebuilded: apt-get source mariadb-10.3 apt-get build-dep mariadb-10.3 cd mariadb-10.3-10.3.38 patch libmariadb/libmariadb/mariadb_lib.c < /tmp/mariadb_lib.c.patch debian/rules binary After installing the resulting packages mariadb-common_10.3.38-0+deb10u2_all.deb mariadb-server-core-10.3_10.3.38-0+deb10u2_amd64.deb mariadb-client-core-10.3_10.3.38-0+deb10u2_amd64.deb libmariadb3_10.3.38-0+deb10u2_amd64.deb kmail/qt/akonadi was working for me again. Please ensure you stopped akonadi after updating these packaes, e.g. with akondaictl stop Otherwise the updated packages/binaries wouldn't be used. Background from the above links: Instead of server version the api functions mysql_get_client_info and mysql_get_client_version should return MARIADB_PACKAGE_VERSION/ID. Apparently this breaks Qt's version detection. Hope this helps, cheers, Markus On Fri, 24 Feb 2023 13:07:41 +0100 =?ISO-8859-1?Q?J=FCrgen?= Leibner <201...@gmx.de> wrote: > Package: mariadb-server-core-10.3 > Version: 1:10.3.38-0+deb10u1 > > libmariadb3/oldstable 1:10.3.38-0+deb10u1 amd64 [aktualisierbar von: 1:10.3.36-0+deb10u2] > mariadb-client-core-10.3/oldstable 1:10.3.38-0+deb10u1 amd64 [aktualisierbar von: 1:10.3.36-0+deb10u2] > mariadb-common/oldstable 1:10.3.38-0+deb10u1 all [aktualisierbar von: 1:10.3.36-0+deb10u2] > mariadb-server-core-10.3/oldstable 1:10.3.38-0+deb10u1 amd64 [aktualisierbar von: 1:10.3.36-0+deb10u2] > > When I upgrade the above listed packages, kmail doesn't work anymore due to the following akonadi failures and kmail gets unusable. > I expected, that a security upgrade doesn't break any working application or environment. > > org.kde.pim.akonadicore: Creating/updating items from the akonadi database failed: "" > org.kde.pim.akonadicore: Creating/updating items from the akonadi database failed: "Failed to store merged item" > org.kde.pim.akonadicore: Error during ItemSync: "Failed to store merged item" > org.kde.pim.imapresource: Detected inconsistency in local cache, we're missing some messages. Server: 57 Local: 56 > org.kde.pim.imapresource: Refetching complete mailbox. > org.kde.pim.akonadiserver: Payload file "/home/jever/.local/share/akonadi/ file_db_data/01/685201_r0" could not be open for reading! > org.kde.pim.akonadiserver: Error: "No such file or directory" > org.kde.pim.akonadiserver: DATABASE ERROR: > org.kde.pim.akonadiserver: Error code: "1292" > org.kde.pim.akonadiserver: DB error: "Incorrect datetime value: '2023-02-23T12:59:27Z' for column `akonadi`.`pimitemtable`.`atime` at row 1" > org.kde.pim.akonadiserver: Error text: "Incorrect datetime value: '2023-02-23T12:59:27Z' for column `akonadi`.`pimitemtable`.`atime` at row 1 QMYSQL: Die Abfrage konnte nicht ausgeführt werden" > org.kde.pim.akonadiserver: Query: "UPDATE PimItemTable SET rev = :0, remoteId = :1, remoteRevision = :2, gid = :3, collectionId = :4, mimeTypeId = :5, datetime = :6, atime = :7, dirty = :8, size = :9 WHERE ( id = :10 )" > org.kde.pim.akonadiserver: Error during updating record with id 342547 in table "PimItemTable" "Incorrect datetime value: '2023-02-23T12:59:27Z' for column `akonadi`.`pimitemtable`.`atime` at row 1 QMYSQL: Die Abfrage konnte nicht ausgeführt werden" > > org.kde.pim.akonadicore: Creating/updating items from the akonadi database failed: "" > org.kde.pim.akonadicore: "" > org.kde.pim.akonadicore: Creating/updating items from the akonadi database failed: "Failed to store merged item" > org.kde.pim.akonadicore: Error during ItemSync: "Failed to store merged item" > org.kde.pim.akonadiserver: DATABASE ERROR: > org.kde.pim.akonadiserver: Error code: "1292" > org.kde.pim.akonadiserver: DB error: "Incorrect datetime value: '2023-02-23T13:13:54Z' for column `akonadi`.`pimitemtable`.`atime` at row 1" > org.kde.pim.akonadiserver: Error text: "Incorrect datetime value: '2023-02-23T13:13:54Z' for column `akonadi`.`pimitemtable`.`atime` at row 1 QMYSQL: Die Abfrage konnte nicht ausgeführt werden" > org.kde.pim.akonadiserver: Query: "UPDATE PimItemTable SET atime = :0 WHERE ( ( PimItemTable.id = :1 ) )" > org.kde.pim.akonadiserver: Unable to update item access time > org.kde.pim.akonadiserver: DATABASE ERROR: > org.kde.pim.akonadiserver: Error code: "1292" > org.kde.pim.akonadiserver: DB error: "Incorrect datetime value: '2023-02-23T13:13:54Z' for column `akonadi`.`pimitemtable`.`atime` at row 1" > org.kde.pim.akonadiserver: Error text: "Incorrect datetime value: '2023-02-23T13:13:54Z' for column `akonadi`.`pimitemtable`.`atime` at row 1
Bug#1031860: [debian-mysql] Bug#1031860: kmail with akonadi stops working after security-upgrade of '*mariadb*'
Yes, they look like the very same issue. The question is, where to fix it? qt or mariadb? Am Montag, 27. Februar 2023, 15:07:47 CET schrieb Faustin Lammler: > Thank you for your report! > Can you check if this looks similar to #1031770 and #1031863.
