Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
Funny, I had this problem (unbootable system, couldn't find net.mod even though it was there ls on the grub_rescue prompt didn't see it) with a XFS V4 partition, and rebuilding that as V5 and copying everything over seemed to have fixed it... but maybe I just got lucky on the first try. Interestingly, once I've got grub actually able to load normal.mod it doesn't seem to have problems finding any files on the V4 partition. For the sake of comparison here's are the full details of the two (lvm) volumes in question: The partition that initially broke w/2.12~rc1-9: # xfs_db -r /dev/mapper/S-root xfs_db> version versionnum [0xb4b4+0xa] = V4,NLINK,DIRV2,ATTR,ALIGN,LOGV2,EXTFLG,MOREBITS,ATTR2,LAZYSBCOUNT # xfs_info /dev/mapper/S-root meta-data=/dev/mapper/S-root isize=256agcount=4, agsize=524288 blks = sectsz=512 attr=2, projid32bit=0 = crc=0finobt=0, sparse=0, rmapbt=0 = reflink=0bigtime=0 inobtcount=0 nrext64=0 data = bsize=4096 blocks=2097152, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 And the partition that seems to be working OK (but maybe it's just luck?): # xfs_db -r /dev/mapper/S-root23 xfs_db> version versionnum [0xb4a5+0x18a] = V5,NLINK,DIRV2,ALIGN,LOGV2,EXTFLG,MOREBITS,ATTR2,LAZYSBCOUNT,PROJID32BIT,CRC,FTYPE,FINOBT,SPARSE_INODES,REFLINK,INOBTCNT,BIGTIME # xfs_info /dev/mapper/S-root23 meta-data=/dev/mapper/S-root23 isize=512agcount=4, agsize=524288 blks = sectsz=512 attr=2, projid32bit=1 = crc=1finobt=1, sparse=1, rmapbt=0 = reflink=1bigtime=1 inobtcount=1 nrext64=0 data = bsize=4096 blocks=2097152, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 Do we know if the breakage related to bigtime feature? -- Jamie Heilman http://audible.transient.net/~jamie/
Bug#1000265: typo in fix for CVE-2021-21996 breaks file.managed on stretch
Package: salt-common Version: 2016.11.2+ds-1+deb9u8 Severity: grave The patch for 994016 in the /usr/lib/python2.7/dist-packages/salt/fileclient.py file included: +# clean_path returns an empty string if the check fails +root_path = salt.utils.path.join(cachedir, "extrn_files", saltenv, netloc) which might work for newer versions of salt, but in stretch that has to be salt.utils.path_join(...) as the salt.utils.path module didn't exist yet. As-is, the security update for CVE-2021-21996 makes file.managed states fail with: Unable to manage file: 'module' object has no attribute 'path' which makes salt on stretch pretty much unusable. -- Jamie Heilman http://audible.transient.net/~jamie/
Bug#949257: xserver-xorg-core: Segmentation fault w/ 1.20.7
Vincent Lefevre wrote: > On 2020-01-19 00:09:13 +0000, Jamie Heilman wrote: > > Package: xserver-xorg-core > > Version: 2:1.20.7-2 > > Severity: grave > > > > Setup is a NVIDIA GF108GL [Quadro 600] driving two monitors in > > portrait orientation. Kernel 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 > > (2020-01-05) > > > > xorg.conf is: > > Section "Device" > > Identifier "GF108GL" > > Driver "nouveau" > [...] > > Crash is consistent, and goes away once downgraded to 1.20.6, other > > relevant package versions: > > > > libdrm-nouveau2:amd64 2.4.100-4 > > xdm 1:1.1.11-3+b1 > > xserver-xorg-video-nouveau 1:1.0.16-1 > > > > Crash: > > > > [ 590.914] (II) NOUVEAU(0): NVEnterVT is called. > > [ 590.914] (EE) > > [ 590.914] (EE) Backtrace: > [...] > > I wonder whether the problem could be related to the nouveau driver. > I've had lots a problems (crashes...) with it, on a machine I do not > use very much. The last one a few weeks ago: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946524 > (trapped write in the nouveau driver) > > Try to look at the system logs too... Wasn't anything else in the system logs, I did look, but this happens entirely in userspace. It does not happen on my system that uses a NVIDIA G86 Quadro NVS 290, but that also only drives a single monitor with no rotation. -- Jamie Heilman http://audible.transient.net/~jamie/
Bug#949257: xserver-xorg-core: Segmentation fault w/ 1.20.7
=y@entry=0) at ../../../../../../hw/xfree86/modes/xf86Crtc.c:319 #14 0x55a933be387a in xf86SetDesiredModes (scrn=scrn@entry=0x55a9340ad360) at ../../../../../../hw/xfree86/modes/xf86Crtc.c:2831 #15 0x7fb9d6548080 in NVEnterVT (arg=arg@entry=0x55a9340ad360) at ../../src/nv_driver.c:513 #16 0x7fb9d65483ce in NVCreateScreenResources (pScreen=0x55a9340b7680) at ../../src/nv_driver.c:627 #17 0x55a933bde6fe in xf86CrtcCreateScreenResources (screen=0x55a9340b7680) at ../../../../../../hw/xfree86/modes/xf86Crtc.c:744 #18 0x55a933b747b9 in dix_main (argc=7, argv=0x7fffcfe334e8, envp=) at ../../../../dix/main.c:213 #19 0x7fb9d6dbcbbb in __libc_start_main (main=0x55a933b5e710 , argc=7, argv=0x7fffcfe334e8, init=, fini=, rtld_fini=, stack_end=0x7fffcfe334d8) at ../csu/libc-start.c:308 #20 0x55a933b5e74a in _start () at ../../../../../../hw/xfree86/modes/xf86Crtc.c:2033 -- Jamie Heilman http://audible.transient.net/~jamie/
Bug#949257: xserver-xorg-core: Segmentation fault w/ 1.20.7
Bernhard Übelacker wrote: > Hello Jamie Heilman, > I just tried to retrieve some line information from the backtrace. > Unfortunately I could not match the addresses with the > binary from the debian repository. > Was this backtrace by any chance built with a local > rebuild of the xserver-xorg-core package? Nope, vanilla amd64 package from the repo, not a rebuild. -- Jamie Heilman http://audible.transient.net/~jamie/
Bug#949257: xserver-xorg-core: Segmentation fault w/ 1.20.7
Package: xserver-xorg-core Version: 2:1.20.7-2 Severity: grave Setup is a NVIDIA GF108GL [Quadro 600] driving two monitors in portrait orientation. Kernel 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) xorg.conf is: Section "Device" Identifier "GF108GL" Driver "nouveau" Option "Monitor-DVI-I-1" "Left Dell U2312HM" Option "Monitor-DP-1" "Right Dell U2312HM" EndSection Section "Monitor" Identifier "Left Dell U2312HM" Option "Rotate" "right" EndSection Section "Monitor" Identifier "Right Dell U2312HM" Option "RightOf" "Left Dell U2312HM" Option "Rotate" "right" EndSection Crash is consistent, and goes away once downgraded to 1.20.6, other relevant package versions: libdrm-nouveau2:amd64 2.4.100-4 xdm 1:1.1.11-3+b1 xserver-xorg-video-nouveau 1:1.0.16-1 Crash: [ 590.914] (II) NOUVEAU(0): NVEnterVT is called. [ 590.914] (EE) [ 590.914] (EE) Backtrace: [ 590.914] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x138) [0x5618c21dfeb8] [ 590.915] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) [0x7f574e2d956f] [ 590.915] (EE) 2: /usr/lib/xorg/Xorg (DamageRegister+0x1d) [0x5618c2160abd] [ 590.915] (EE) 3: /usr/lib/xorg/Xorg (xf86RandR12PreInit+0x3c1) [0x5618c20fef31] [ 590.915] (EE) 4: /usr/lib/xorg/Xorg (xf86CrtcRotate+0x321) [0x5618c20ff5d1] [ 590.915] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 590.915] (EE) 5: /usr/lib/xorg/modules/drivers/nouveau_drv.so (?+0x0) [0x7f574d8ccf30] [ 590.915] (EE) 6: /usr/lib/xorg/Xorg (xf86CrtcSetModeTransform+0x280) [0x5618c20f5330] [ 590.915] (EE) 7: /usr/lib/xorg/Xorg (xf86SetDesiredModes+0xea) [0x5618c20f587a] [ 590.915] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 590.915] (EE) 8: /usr/lib/xorg/modules/drivers/nouveau_drv.so (?+0x0) [0x7f574d8b5f90] [ 590.916] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 590.916] (EE) 9: /usr/lib/xorg/modules/drivers/nouveau_drv.so (?+0x0) [0x7f574d8b6370] [ 590.916] (EE) 10: /usr/lib/xorg/Xorg (InitExtensions+0x61e) [0x5618c20f0cee] [ 590.916] (EE) 11: /usr/lib/xorg/Xorg (InitFonts+0x279) [0x5618c20867f9] [ 590.916] (EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xeb) [0x7f574e12abbb] [ 590.916] (EE) 13: /usr/lib/xorg/Xorg (_start+0x2a) [0x5618c207074a] [ 590.916] (EE) [ 590.916] (EE) Segmentation fault at address 0x10 [ 590.916] (EE) Fatal server error: [ 590.916] (EE) Caught signal 11 (Segmentation fault). Server aborting [ 590.916] (EE) full Xorg and xdm logs attached; appears to die at the point when the screen gets resized -- Jamie Heilman http://audible.transient.net/~jamie/ [ 590.560] X.Org X Server 1.20.7 X Protocol Version 11, Revision 0 [ 590.560] Build Operating System: Linux 4.19.0-6-amd64 x86_64 Debian [ 590.560] Current Operating System: Linux jamiehe1 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) x86_64 [ 590.560] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-2-amd64 root=/dev/mapper/W-root ro cgroup_no_v1=all [ 590.560] Build Date: 14 January 2020 10:13:49AM [ 590.560] xorg-server 2:1.20.7-2 (https://www.debian.org/support) [ 590.560] Current version of pixman: 0.36.0 [ 590.560]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 590.560] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 590.560] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Jan 18 23:24:40 2020 [ 590.560] (==) Using config file: "/etc/X11/xorg.conf" [ 590.560] (==) Using config directory: "/etc/X11/xorg.conf.d" [ 590.560] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 590.560] (==) No Layout section. Using the first Screen section. [ 590.560] (==) No screen section available. Using defaults. [ 590.560] (**) |-->Screen "Default Screen Section" (0) [ 590.560] (**) | |-->Monitor "" [ 590.560] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [ 590.560] (**) | |-->Device "GF108GL" [ 590.560] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 590.560] (==) Automatically adding devices [ 590.560] (==) Automatically enabling devices [ 590.560] (==) Automatically adding GPU devices [ 590.560] (==) Max clients allowed: 256, resource mask: 0
Bug#865822: mutt: Enter key disabled with latest upgrade
> It behaves like all the sane compile time defaults were replaced > with something unusable. I was able to restore most functionality by running mutt -D with 1.8.0, and then again with 1.8.3 and then sourcing a file that restores all the settings I lost. Hopefully that helps somebody else who's trying to figure out all the regressions this version introduced. -- Jamie Heilman http://audible.transient.net/~jamie/
Bug#865822: mutt: Enter key disabled with latest upgrade
It goes beyond just the tmpdir setting; for those of us who start our mutt configs with "reset all" we wind up with a more or less unusable mail client. In my case it screwed up decoding my aliases with "Warning: Bad IDN" for every single alias I had, ment that I didn't start in my inbox as defined by my $MAIL environment variable, and couldn't decode html email despite having set a tmpdir ... and so forth. It behaves like all the sane compile time defaults were replaced with something unusable. -- Jamie Heilman http://audible.transient.net/~jamie/
Bug#845728: undefined symbol: ChangeWindowProperty
Package: xserver-xorg-video-dummy Version: 1:0.3.7-1+b6 Severity: grave dummy driver doesn't work at all anymore; /usr/lib/xorg/Xorg: symbol lookup error: /usr/lib/xorg/modules/drivers/dummy_drv.so: undefined symbol: ChangeWindowProperty may or may not be related to https://bugs.freedesktop.org/show_bug.cgi?format=multiple=93462 or https://bugzilla.redhat.com/show_bug.cgi?id=1393114 regardless, very very lame
Bug#823459: ldlinux.c32 module only loads default label
Package: syslinux-common Version: 3:6.03+dfsg-12 Severity: grave Given a fairly simple config of: SERIAL 0 115200 DISPLAY boot.txt PROMPT 1 TIMEOUT 250 DEFAULT local LABEL local LOCALBOOT -1 LABEL memtest KERNEL mt86plus it's now impossible to load anything other than the default label. Hitting tab at the boot: prompt still displays all available labels, but entering any other label at the prompt always results in execution of the default. Reverting syslinux-common to 3:6.03+dfsg-11 resolves the problem. Platform in use is amd64. -- Jamie Heilman http://audible.transient.net/~jamie/
Bug#816227: ping: socket: Address family not supported by protocol (raw socket required by specified options).
Package: iputils-ping Version: 3:20150815-1 Severity: grave root@cucamonga:~# ping 127.0.0.1 ping: socket: Address family not supported by protocol (raw socket required by specified options). I actually can't ping anything at all, it all fails with the above error message. I wouldn't be stunned to learn this is because I have no ipv6 connectivity and no ipv6 support in my kernel, but I don't think that makes this behavior anymore OK. -- Jamie Heilman http://audible.transient.net/~jamie/
Bug#802035: fping segfaults on amd64
Axel Beckert wrote:
> Control: tag -1 + unreproducible moreinfo
>
> Hi Jamie,
>
> Jamie Heilman wrote:
> > fping[4709]: segfault at 1 ip 7f2c04511e2c sp 7fffe869a550 error 4
> > in libc-2.19.so[7f2c044c7000+19f000]
> >
> > [New LWP 4709]
> > Core was generated by `fping -a'.
> > Program terminated with signal SIGSEGV, Segmentation fault.
>
> I'm sorry, but I can't reproduce that issue, neither on Sid amd64 or
> on Sid amd64.
>
> Please use reportbug (or equivalent) to report bugs because without
> your bug report doesn't contain any meta information about your system
> (i.e. what release you're using, at which version all of fping's
> dependencies were at the time of writing, etc.).
Not relevant information.
The "%s from %s for ICMP Echo sent to %s" format being passed to
vfprintf only exists in a single spot in the software. That makes it
obvious where this is occuring. A diff between the 3.10 and 3.12
made for interesting reading, and I spotted the problem. Here's a
patch:
--- fping-3.12.orig/src/fping.c
+++ fping-3.12/src/fping.c
@@ -1741,7 +1741,7 @@ int handle_random_icmp(FPING_ICMPHDR *p,
addr_ascii, h->host );
}
else {
-print_warning("%s from %s for ICMP Echo sent to %s",
icmp_code, addr_ascii, h->host);
+print_warning("%s from %s for ICMP Echo sent to %s",
icmp_unreach_str[icmp_code], addr_ascii, h->host);
}
if( inet_addr( h->host ) == INADDR_NONE )
> BTW, what should "fping -a", i.e. without any target do? The man page
> doesn't mention any default target.
>
> For me it just seems to hang infinitely without any output. (Haven't
> waited for long, though.) I'd rather expect that either exits
> immediately and successfully or exits unsuccessfully with an error
> message stating that at least one target is required.
What any program that expects input on stdin should do, block and wait
for the end of file.
--
Jamie Heilman http://audible.transient.net/~jamie/
Bug#802035: fping segfaults on amd64
Package: fping Version: 3.12-1 Severity: grave This is new: fping[4709]: segfault at 1 ip 7f2c04511e2c sp 7fffe869a550 error 4 in libc-2.19.so[7f2c044c7000+19f000] [New LWP 4709] Core was generated by `fping -a'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7f2c04511e2c in _IO_vfprintf_internal (s=, format=, ap=) at vfprintf.c:1642 1642vfprintf.c: No such file or directory. (gdb) bt #0 0x7f2c04511e2c in _IO_vfprintf_internal (s=, format=, ap=) at vfprintf.c:1642 #1 0x7f2c04512b61 in buffered_vfprintf ( s=s@entry=0x7f2c0486b060 <_IO_2_1_stderr_>, format=format@entry=0x4052b0 "%s from %s for ICMP Echo sent to %s", args=args@entry=0x7fffe869d280) at vfprintf.c:2348 #2 0x7f2c0450d3de in _IO_vfprintf_internal ( s=s@entry=0x7f2c0486b060 <_IO_2_1_stderr_>, format=0x4052b0 "%s from %s for ICMP Echo sent to %s", ap=0x7fffe869d280) at vfprintf.c:1296 #3 0x7f2c045bb3fd in ___vfprintf_chk ( fp=0x7f2c0486b060 <_IO_2_1_stderr_>, flag=1, format=, ap=) at vfprintf_chk.c:33 #4 0x00402182 in ?? () #5 0x00402448 in ?? () #6 0x00403aee in ?? () #7 0x00403fff in ?? () #8 0x00401ef2 in ?? () #9 0x7f2c044e8b45 in __libc_start_main (main=0x4014e0, argc=2, argv=0x7fffe869d738, init=, fini=, rtld_fini=, stack_end=0x7fffe869d728) at libc-start.c:287 #10 0x00401f76 in ?? () Haven't tested any other platforms, reverting to 3.10-3 fixes it. -- Jamie Heilman http://audible.transient.net/~jamie/
Bug#802035: fping segfaults on amd64
Axel Beckert wrote: > Thanks. Nevertheless I'm still not able to reproduce the issue. Make yourself an /etc/hosts entry to an unused IP on your network. echo whatever-hostname-you-chose | fping -a This is pretty obvious if you'd looked at the context of format message in the backtrace from my original bug report, the only place it exists is in the icmp unreachable handling path. -- Jamie Heilman http://audible.transient.net/~jamie/
Bug#802035: fping segfaults on amd64
Axel Beckert wrote: > Control: tag -1 -unreproducible > > Jamie Heilman wrote: > > Axel Beckert wrote: > > > Thanks. Nevertheless I'm still not able to reproduce the issue. > > > > Make yourself an /etc/hosts entry to an unused IP on your network. > > > > echo whatever-hostname-you-chose | fping -a > > Thanks for the hint about an hostname instead of an IP is required to > reproduce this. You can reproduce it with an IP too. cucamonga<~/>echo 192.168.2.99 | fping -a Segmentation fault -- Jamie Heilman http://audible.transient.net/~jamie/
Bug#757609: [Pkg-libvirt-maintainers] Bug#757609: libvirtd internal error: Unable to parse /proc/meminfo
Guido Günther wrote: On Sat, Aug 09, 2014 at 06:50:56PM +, Jamie Heilman wrote: Package: libvirt-daemon Version: 1.2.7-6 Severity: grave The parsing of /proc/meminfo in the latest versions of the libvirt packages is flawed. Please remove it until upstream figures out what they're doing. There have been reports of the parsing failing when running under Xen, but it fails in in other scenarios too; In my case Linux 3.16 (I tested 3.15.8 too) with: [2]cucamonga~/grep -i huge /boot/config-3.1* /boot/config-3.15.8:CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y /boot/config-3.15.8:CONFIG_ARCH_WANT_GENERAL_HUGETLB=y /boot/config-3.15.8:CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y /boot/config-3.15.8:CONFIG_TRANSPARENT_HUGEPAGE=y /boot/config-3.15.8:CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y /boot/config-3.15.8:# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set /boot/config-3.15.8:# CONFIG_HUGETLBFS is not set /boot/config-3.15.8:# CONFIG_HUGETLB_PAGE is not set /boot/config-3.16.0:CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y /boot/config-3.16.0:CONFIG_ARCH_WANT_GENERAL_HUGETLB=y /boot/config-3.16.0:CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y /boot/config-3.16.0:CONFIG_TRANSPARENT_HUGEPAGE=y /boot/config-3.16.0:CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y /boot/config-3.16.0:# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set /boot/config-3.16.0:# CONFIG_HUGETLBFS is not set /boot/config-3.16.0:# CONFIG_HUGETLB_PAGE is not set In any case, /proc/meminfo does not always have the items libvirtd assumes it does, and handles that failure poorly. 2014-08-09 18:32:30.722+: 3589: info : libvirt version: 1.2.7, package: 6 (root 2014-08-08-16:09:22 bogon) 2014-08-09 18:32:30.722+: 3589: error : virAuditOpen:62 : Unable to initialize audit layer: Protocol not supported 2014-08-09 18:32:31.720+: 3712: error : virFileGetDefaultHugepageSize:2958 : internal error: Unable to parse /proc/meminfo 2014-08-09 18:32:31.720+: 3712: error : virStateInitialize:749 : Initialization of QEMU state driver failed: internal error: Unable to parse /proc/meminfo 2014-08-09 18:32:31.720+: 3712: error : daemonRunStateInit:922 : Driver state initialization failed Reverting to libvirt-bin 1.2.4 allows libvirtd to work again. Please attach your /proc/meminfo as well. -- Guido MemTotal:3981644 kB MemFree: 1022420 kB MemAvailable:1183012 kB Buffers: 0 kB Cached: 564648 kB SwapCached:38448 kB Active: 1830420 kB Inactive: 901504 kB Active(anon):1744072 kB Inactive(anon): 508600 kB Active(file): 86348 kB Inactive(file): 392904 kB Unevictable: 82584 kB Mlocked: 82584 kB SwapTotal: 8388172 kB SwapFree:8228692 kB Dirty: 4 kB Writeback: 0 kB AnonPages: 2238356 kB Mapped: 108016 kB Shmem: 83528 kB Slab: 61840 kB SReclaimable: 38484 kB SUnreclaim:23356 kB KernelStack:3824 kB PageTables:13680 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit:10378992 kB Committed_AS:2930912 kB VmallocTotal: 34359738367 kB VmallocUsed: 338292 kB VmallocChunk: 34359338248 kB HardwareCorrupted: 0 kB AnonHugePages: 1826816 kB DirectMap4k: 106500 kB DirectMap2M: 4020224 kB -- Jamie Heilman http://audible.transient.net/~jamie/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757609: [Pkg-libvirt-maintainers] Bug#757609: libvirtd internal error: Unable to parse /proc/meminfo
Guido Günther wrote:
Hi,
On Sat, Aug 09, 2014 at 06:50:56PM +, Jamie Heilman wrote:
[..snip..]
2014-08-09 18:32:30.722+: 3589: info : libvirt version: 1.2.7, package:
6 (root 2014-08-08-16:09:22 bogon)
2014-08-09 18:32:30.722+: 3589: error : virAuditOpen:62 : Unable to
initialize audit layer: Protocol not supported
2014-08-09 18:32:31.720+: 3712: error :
virFileGetDefaultHugepageSize:2958 : internal error: Unable to parse
/proc/meminfo
2014-08-09 18:32:31.720+: 3712: error : virStateInitialize:749 :
Initialization of QEMU state driver failed: internal error: Unable to parse
/proc/meminfo
2014-08-09 18:32:31.720+: 3712: error : daemonRunStateInit:922 : Driver
state initialization failed
Reverting to libvirt-bin 1.2.4 allows libvirtd to work again.
Any chance you can test the attached patch? It fixes the above problem
but there may be other hugetlb surprises working with your setup.
Yep, that works. Although the build was made rather annoying by the
policykit-1 build-dep, and the poison that brings.
2014-08-10 22:16:26.387+: 25357: info : libvirt version: 1.2.7, package: 6
(jamie 2014-08-10-19:06:36 jimmy)
2014-08-10 22:16:26.387+: 25357: error : virAuditOpen:62 : Unable to
initialize audit layer: Protocol not supported
2014-08-10 22:16:26.460+: 25370: error : virFileGetDefaultHugepageSize:2959
: this function is not supported by the connection driver: Hugepagesize: not
found in /proc/meminfo
2014-08-10 22:16:26.524+: 25370: error : virNodeSuspendSupportsTarget:332 :
internal error: Cannot probe for supported suspend types
2014-08-10 22:16:26.524+: 25370: warning : virQEMUCapsInit:983 : Failed to
get host power management capabilities
2014-08-10 22:16:31.836+: 25370: error : virNodeSuspendSupportsTarget:332 :
internal error: Cannot probe for supported suspend types
2014-08-10 22:16:31.836+: 25370: warning : umlCapsInit:74 : Failed to get
host power management capabilities
--
Jamie Heilman http://audible.transient.net/~jamie/
___
Pkg-libvirt-maintainers mailing list
pkg-libvirt-maintain...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers
From 930402215c050e52cab1ccf1960ad06123cd7c7e Mon Sep 17 00:00:00 2001
Message-Id:
930402215c050e52cab1ccf1960ad06123cd7c7e.1407671364.git@sigxcpu.org
From: =?UTF-8?q?Guido=20G=C3=BCnther?= a...@sigxcpu.org
Date: Sun, 10 Aug 2014 12:42:37 +0200
Subject: [PATCH] Don't fail qemu driver intialization if we can't determine
hugepage size
To: libvir-l...@redhat.com
Otherwise we fail like
libvirt version: 1.2.7, package: 6 (root 2014-08-08-16:09:22 bogon)
virAuditOpen:62 : Unable to initialize audit layer: Protocol not supported
virFileGetDefaultHugepageSize:2958 : internal error: Unable to parse
/proc/meminfo
virStateInitialize:749 : Initialization of QEMU state driver failed:
internal error: Unable to parse /proc/meminfo
daemonRunStateInit:922 : Driver state initialization failed
if the data can't be determined.
Reference: http://bugs.debian.org/757609
---
src/util/virfile.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/util/virfile.c b/src/util/virfile.c
index f9efc65..b6f5e3f 100644
--- a/src/util/virfile.c
+++ b/src/util/virfile.c
@@ -2953,8 +2953,9 @@ virFileGetDefaultHugepageSize(unsigned long long *size)
goto cleanup;
if (!(c = strstr(meminfo, HUGEPAGESIZE_STR))) {
-virReportError(VIR_ERR_INTERNAL_ERROR,
- _(Unable to parse %s),
+virReportError(VIR_ERR_NO_SUPPORT,
+ _(%s not found in %s),
+ HUGEPAGESIZE_STR,
PROC_MEMINFO);
goto cleanup;
}
--
2.0.1
--
Jamie Heilman http://audible.transient.net/~jamie/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757609: libvirtd internal error: Unable to parse /proc/meminfo
Package: libvirt-daemon Version: 1.2.7-6 Severity: grave The parsing of /proc/meminfo in the latest versions of the libvirt packages is flawed. Please remove it until upstream figures out what they're doing. There have been reports of the parsing failing when running under Xen, but it fails in in other scenarios too; In my case Linux 3.16 (I tested 3.15.8 too) with: [2]cucamonga~/grep -i huge /boot/config-3.1* /boot/config-3.15.8:CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y /boot/config-3.15.8:CONFIG_ARCH_WANT_GENERAL_HUGETLB=y /boot/config-3.15.8:CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y /boot/config-3.15.8:CONFIG_TRANSPARENT_HUGEPAGE=y /boot/config-3.15.8:CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y /boot/config-3.15.8:# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set /boot/config-3.15.8:# CONFIG_HUGETLBFS is not set /boot/config-3.15.8:# CONFIG_HUGETLB_PAGE is not set /boot/config-3.16.0:CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y /boot/config-3.16.0:CONFIG_ARCH_WANT_GENERAL_HUGETLB=y /boot/config-3.16.0:CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y /boot/config-3.16.0:CONFIG_TRANSPARENT_HUGEPAGE=y /boot/config-3.16.0:CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y /boot/config-3.16.0:# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set /boot/config-3.16.0:# CONFIG_HUGETLBFS is not set /boot/config-3.16.0:# CONFIG_HUGETLB_PAGE is not set In any case, /proc/meminfo does not always have the items libvirtd assumes it does, and handles that failure poorly. 2014-08-09 18:32:30.722+: 3589: info : libvirt version: 1.2.7, package: 6 (root 2014-08-08-16:09:22 bogon) 2014-08-09 18:32:30.722+: 3589: error : virAuditOpen:62 : Unable to initialize audit layer: Protocol not supported 2014-08-09 18:32:31.720+: 3712: error : virFileGetDefaultHugepageSize:2958 : internal error: Unable to parse /proc/meminfo 2014-08-09 18:32:31.720+: 3712: error : virStateInitialize:749 : Initialization of QEMU state driver failed: internal error: Unable to parse /proc/meminfo 2014-08-09 18:32:31.720+: 3712: error : daemonRunStateInit:922 : Driver state initialization failed Reverting to libvirt-bin 1.2.4 allows libvirtd to work again. -- Jamie Heilman http://audible.transient.net/~jamie/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691769: zita-a2j segfaults on 64bit systems
Package: libzita-resampler1 Version: 1.1.0-2 Severity: grave Due to an issue now fixed upstream, applications using libzita-resampler1 on 64bit platforms may not work. This is particularly true of the tools in the zita-ajbridge package which don't work on x86_64 systems currently. For example: [2]cucamonga~/zita-a2j -d hw:0 Starting synchronisation. Segmentation fault [3]cucamonga~/uname -m x86_64 [4]cucamonga~/ltrace zita-a2j -d hw:0 __libc_start_main(0x402350, 3, 0x7fff8539cda8, 0x404620, 0x404610 unfinished ... _Znam(64, 16, 0x7fff8539cdc8, 32, 0x7f333ae9c320) = 0xb8c050 __cxa_atexit(0x404570, 0x605f90, 0x605e40, 0xb8c040, 0x7f333ae9cef8) = 0 _Znam(4096, 256, 0, 579, 24) = 0xb8c4c0 __cxa_atexit(0x404490, 0x605fb0, 0x605e40, 0xb8c4b0, 24) = 0 _Znam(6144, 256, 0, 2, 0xb8c0a0) = 0xb8d4d0 __cxa_atexit(0x404500, 0x605fd0, 0x605e40, 0xb8d4c0, 0xb8c0a0) = 0 getopt(3, 0x7fff8539cda8, hvLj:d:r:p:n:c:Q:) = 100 getopt(3, 0x7fff8539cda8, hvLj:d:r:p:n:c:Q:) = -1 _Znwm(1488, 0x7fff8539cda8, 0x605e80, 0, 0) = 0xb8ece0 _ZN9Alsa_pcmiC1EPKcS1_S1_(0xb8ece0, 0, 0x7fff8539dd63, 0, 48000) = 0 _Znwm(120, 0, 2, 0, 0) = 0xb9f6c0 _Znwm(920, 0xb8ece0, 1, 0xb9f6b0, 0xb9f6b0) = 0xba1040 _ZN10VResamplerC1Ev(0xba1310, 0x40470a, 0, 1, 2) = 1 jack_client_open(0x40470a, 1, 0x7fff8539cbdc, 1, 2) = 0xb8f6b0 jack_set_process_callback(0xb8f6b0, 0x4042d0, 0xba1040, 1, 1) = 0 jack_set_freewheel_callback(0xb8f6b0, 0x403c80, 0xba1040, 0xb8f6b0, 1) = 0 jack_set_buffer_size_callback(0xb8f6b0, 0x403240, 0xba1040, 0xb8f6b0, 1) = 0 jack_on_shutdown(0xb8f6b0, 0x403c30, 0xba1040, 0xb8f6b0, 1) = 0xb8f6b0 jack_activate(0xb8f6b0, 0x403c30, 0x403c30, 0xb8f6b0, 1) = 0 jack_get_client_name(0xb8f6b0, 0x7fff8539cad8, 0x7f333bfad690, -1, 0x7f333c4b1700) = 0x7f333c5d100e jack_get_buffer_size(0xb8f6b0, 0x7fff8539cad8, 0xb8f6b0, -1, 0x7f333c4b1700) = 1024 jack_get_sample_rate(0xb8f6b0, 0x7fff8539cad8, 0xb8f6b0, -1, 0x7f333c4b1700) = 48000 sprintf(NULL, )= 9 jack_port_register(0xb8f6b0, 0x7fff8539cb90, 0x404e20, 2, 0) = 5 sprintf(NULL, )= 9 jack_port_register(0xb8f6b0, 0x7fff8539cb90, 0x404e20, 2, 0) = 6 jack_client_thread_id(0xb8f6b0, 0, 1, 1, 0x7f333ae9cfc8) = 0x7f333c4b1700 pthread_getschedparam(0x7f333c4b1700, 0x7fff8539cbd8, 0x7fff8539cbd0, 1, 0x7f333ae9cfc8) = 0 sched_get_priority_max(1, 1, 0x7fff8539cbd0, 1, 0x7f333ae9cfc8) = 99 _Znam(8192, 1, 0x7fff8539cbd0, -1, 0x7f333ae9cfc8) = 0xbadca0 usleep(10) = void _Znwm(32, 0, 0, -1, 262144) = 0xb8f520 _Znam(32768, 4096, 2, 0xb8f510, 0xb8f510)= 0xbafcb0 sched_get_priority_min(1, 1, 0xffac, 65536, 0xffac) = 1 sched_get_priority_max(1, 1, 0xffac, -1, 0xffac) = 99 pthread_attr_init(0x7fff8539cbb0, 1, 0xffac, -1, 0xffac) = 0 pthread_attr_setdetachstate(0x7fff8539cbb0, 1, 4096, 0, 0xffac) = 0 pthread_attr_setschedpolicy(0x7fff8539cbb0, 1, 4096, 0, 0xffac) = 0 pthread_attr_setschedparam(0x7fff8539cbb0, 0x7fff8539cbf0, 4096, 0, 0xffac) = 0 pthread_attr_setscope(0x7fff8539cbb0, 0, 15, -1, 0xffac) = 0 pthread_attr_setinheritsched(0x7fff8539cbb0, 1, 15, -1, 0xffac) = 0 pthread_attr_setstacksize(0x7fff8539cbb0, 65536, 15, -1, 0xffac) = 0 pthread_create(0xb9f6c8, 0x7fff8539cbb0, 0x404300, 0xb9f6c0, 0xffac) = 0 pthread_attr_destroy(0x7fff8539cbb0, 1, 0x7f333c430d38, -1, 0x7f333c430700) = 0 _ZN10VResampler5setupEdjj(0xba1310, 2, 48, 0x605fb0, 0x3ff0) = 0 _ZN10VResampler10set_rrfiltEd(0xba1310, 384, 0xb9f5b0, 0xbc4b10, 0x7f333ae9d038) = 1 _ZNK10VResampler7inpsizeEv(0xba1310, 0x7f333b10da00, 0x3ff0, 0x7f333b10c3c0, 902) = 96 signal(2, 0x00402b30)= NULL usleep(25) = void puts(Starting synchronisation.Starting synchronisation. )= 26 usleep(25 unfinished ... +++ killed by SIGSEGV +++ See announcement: http://lists.linuxaudio.org/pipermail/linux-audio-dev/2012-October/033986.html -- Jamie Heilman http://audible.transient.net/~jamie/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626450: lost /lib64 - /lib symlink on amd64; upgrade fails
Package: libc6 Version: 2.13-3 Severity: critical Unpacking replacement libc6 ... dpkg (subprocess): unable to execute rm command for cleanup (rm): No such file or directory dpkg: error while cleaning up: subprocess rm cleanup returned error exit status 2 Could not exec dpkg! I see lib64 is gone from / and /usr in /var/lib/dpkg/info/libc6.list ... once I added the /lib64 - /lib symlink back, things more or less worked again. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#335976: /etc/init.d/nvidia-kernel contains bashisms
New version is still broken. The way 20051026+1 is written, if NVIDIA_CARDS is 0 then make_nodes is still run, possibly creating /dev/nvidiactl needlessly. Also, expr in bash apparently lets you get away with the form of variable expansion you used, but dash does not. Look at the patch I gave you again, it was correct, and now here's patch against version 20051026+1: @@ -6,7 +6,7 @@ [ -r /etc/default/nvidia-kernel ] . /etc/default/nvidia-kernel # test if anything is requested -if [ -z $NVIDIA_CARDS ] || [ $NVIDIA_CARDS -lt 0 ]; then +if [ -z $NVIDIA_CARDS ] || [ $NVIDIA_CARDS -lt 1 ]; then # Nothing to do but exit. exit 0 fi @@ -16,7 +16,7 @@ mknod -m 0660 /dev/nvidiactl c 195 255 chgrp video /dev/nvidiactl fi - for i in $(seq 0 $((NVIDIA_CARDS - 1))); do + for i in $(seq 0 $(($NVIDIA_CARDS - 1))); do if ! [ -e /dev/nvidia$i ]; then mknod -m 0660 /dev/nvidia$i c 195 $i chgrp video /dev/nvidia$i -- Jamie Heilman http://audible.transient.net/~jamie/ Most people wouldn't know music if it came up and bit them on the ass. -Frank Zappa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#196590: acknowledged by developer (Re: testing bug triage)
Debian Bug Tracking System wrote: It has been marked as closed by one of the developers, namely Joey Hess [EMAIL PROTECTED]. Again, please leave this bug open until Woody is deprecated by the security team and all bets are officially off. It affects Woody's zope, it has not been fixed in Woody, nor will it be, and it was tagged appropriately. Thanks. -- Jamie Heilman http://audible.transient.net/~jamie/ I was in love once -- a Sinclair ZX-81. People said, No, Holly, she's not for you. She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway. -Holly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#196590: acknowledged by developer (Zope (= 2.5) in woody is missing security updates)
Now that sarge has been released, woody version of zope is not a problem=20 anymore, so this bug report can be closed. What, so the security team isn't maintaining old releases anymore? http://www.debian.org/security/faq#lifespan Look, its obvious nobody cares enough to actually fix these holes, but if you're going to close the bug atleast do it under more accurate pretenses. -- Jamie Heilman http://audible.transient.net/~jamie/ You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid. -Buddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#196590: acknowledged by developer (Zope (= 2.5) in woody is missing security updates)
martin f krafft wrote: also sprach Jamie Heilman [EMAIL PROTECTED] [2005.06.16.2057 +0200]: What, so the security team isn't maintaining old releases anymore? http://www.debian.org/security/faq#lifespan It certainly should, and it does. I don't think Fabio should have closed the bug. Good. Look, its obvious nobody cares enough to actually fix these holes, but if you're going to close the bug atleast do it under more accurate pretenses. If you actually care, I would be happy to work with you on fixing the problems once and for all. However, when zope 2.5 was current, I didn't even know about zope yet, so I'll rely on you to help. I don't care. I just think people should know what they're in for if they install this software. I gave up trying to get the Zope developers to think about security; they'd rather rewrite everything from the ground up every few years and replace one set of bugs with another, which is fine it is their perogative to do that, but as a result I haven't followed Zope development for about a year, so backporting all the fixes between 2.5 and now, even if I had the time, isn't somthing I really want to help with. I don't expect to see these bugs fixed, but until woody is burried it wouldn't hurt to just leave this bug open. -- Jamie Heilman http://audible.transient.net/~jamie/ I was in love once -- a Sinclair ZX-81. People said, No, Holly, she's not for you. She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway. -Holly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291011: arggg fix the real problem.
Martin Pitt wrote: Jamie Heilman [2005-01-18 10:42 -0800]: Changes: sysfsutils (1.2.0-2) unstable; urgency=low . * sysfsutils.init: Use shell bash instead of sh. (closes: #291011) Please do not use bash, just fix the real problem, I offered a patch in #291022 which does this (and more). What is the _real_ problem? The 'real problem' I was referring to was the use bash substitution syntax when it wasn't necessary... Using awk is a problem because it might not be available at the time the init script runs (there is a reason that init script can only use programs in /bin, not in /usr/bin). Well, for some init scripts sure, however: [98]stink-foot/etc/rcS.d/ls *sysfsutils ls: *sysfsutils: No such file or directory Seeing as you didn't have a link in rcS.d I didn't figure you cared about what was or wasn't mounted yet. (ISTR your bash substitution syntax also didn't trim leading whitespace from the component value, which may or may not be important, mine doesn't trim leading whitespace from the key, or trailing from the value, though thats easy to fix with gsub; I haven't check to see if its a real problem though.) -- Jamie Heilman http://audible.transient.net/~jamie/ Most people wouldn't know music if it came up and bit them on the ass. -Frank Zappa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291011: arggg fix the real problem.
Changes: sysfsutils (1.2.0-2) unstable; urgency=low . * sysfsutils.init: Use shell bash instead of sh. (closes: #291011) Please do not use bash, just fix the real problem, I offered a patch in #291022 which does this (and more). Additional bugs in the current script: Your replacement of '.' to '/' isn't a good idea because there are paths in sysfs which can contain '.' -- my patch accounted for that as well. You defined a configuration file variable, and then didn't use it, my patch took care of that too. -- Jamie Heilman http://audible.transient.net/~jamie/ I was in love once -- a Sinclair ZX-81. People said, No, Holly, she's not for you. She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway. -Holly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
