Bug#1029058: lvm2: lvmdevices symlink missing
Package: lvm2 Version: 2.03.16-2 Severity: normal Dear Maintainer, when using the use_devicesfile directive in LVM, the documented way to add devices to said file is to run `lvmdevices --adddev`. However, on Debian lvmdevices does not exist. As most (all?) LVM commands, it is a symlink to lvm itself, but this symlink is missing from Debian. thanks, -Christian -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/40 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lvm2 depends on: ii dmeventd 2:1.02.185-2 ii dmsetup2:1.02.185-2 ii libaio10.3.113-3 ii libblkid1 2.38.1-4 ii libc6 2.36-8 ii libdevmapper-event1.02.1 2:1.02.185-2 ii libedit2 3.1-20221030-2 ii libselinux13.4-1+b4 ii libsystemd0252.4-1 ii libudev1 252.4-1 ii lsb-base 11.5 ii sysvinit-utils [lsb-base] 3.06-2 Versions of packages lvm2 recommends: pn thin-provisioning-tools lvm2 suggests no packages. -- Configuration Files: /etc/lvm/lvm.conf changed [not included] -- no debconf information
Bug#1028541: lvm2: LVM filters render server unbootable
Dear Bastian, update: we were told by upstream that there is a known instability between lvm and udev-generated symlinks and a devices file should be used instead. So that's what we're going to do. In related news, I'll create another bug report shortly, but it's a small one. thanks, -Christian -- Dr. Christian Herzog support: +41 44 633 26 68 Head, IT Services Group, HPT H 8 voice: +41 44 633 39 50 Department of Physics, ETH Zurich 8093 Zurich, Switzerland http://isg.phys.ethz.ch/
Bug#1028541: lvm2: LVM filters render server unbootable
Dear Bastian,
thanks for picking up on this. We've done some more research, and we now
believe the issue to be upstream, so we've opened a bug report directly with
lvm: https://github.com/lvmteam/lvm2/issues/104
If you check the lvm debug log we posted there, you'll see that it correctly
picks up the filter, finds and scans the right device (sda3), but then rejects
it since at the time of scanning,
/dev/disk/by-path/pci-:04:00.0-sas-phy0-lun-0-part3 (the one in the
filter) doesn't exist. This might be a race condition, since on some reboots
it sees part1 and part2, on some only part1, but never part3.
I could also reproduce the problem in Arch (Fedora, surprisingly, has too old
of an LVM version).
to your questions:
> >- manually activating the root VG in busybox allows us to boot
> > (by copy/pasting the IMPORT{program} lines from the udev rule)
>
> Which one? "pvscan"? That one does not activate anything.
correct, but I don't think that's relevant any longer.
> >- replacing /usr/sbin/lvm and /lib/udev/rules.d/69-lvm.rules on
> > bookworm with the bullseye versions fixes the problem
>
> What are you replacing exactly? The bullseye version did not include
> /lib/udev/rules.d/69-lvm.rules at all, see
> https://packages.debian.org/bullseye/amd64/lvm2/filelist.
correct, I used bullseye's 69-lvm-metad.rules and renamed it to 69-lvm.rules
on bookworm.
> Please provide the output of "pvs", "vgs", "lvs" and the kernel log.
again, I don't think it's relevant, but to help understand the situation
better:
PV VG Fmt
Attr PSize PFree
/dev/disk/by-path/pci-:04:00.0-sas-phy0-lun-0-part3 test-bookworm-vg
lvm2 a-- <2.73t <2.45t
VG #PV #LV #SN Attr VSize VFree
test-bookworm-vg 1 10 4 wz--n- <2.73t <2.45t
LVVG Attr LSize Pool Origin Data% Meta% Move
Log Cpy%Sync Convert
home test-bookworm-vg owi-aos--- 10.00g
root test-bookworm-vg owi-aos--- 23.28g
swap_1test-bookworm-vg -wi-ao 976.00m
var test-bookworm-vg owi-aos--- 9.31g
and
pci-:04:00.0-sas-phy0-lun-0 -> ../../sda
pci-:04:00.0-sas-phy0-lun-0-part1 -> ../../sda1
pci-:04:00.0-sas-phy0-lun-0-part2 -> ../../sda2
pci-:04:00.0-sas-phy0-lun-0-part3 -> ../../sda3
Device StartEndSectors Size Type
/dev/sda1 2048 4095 20481M BIOS boot
/dev/sda2 40961003519 999424 488M Linux filesystem
/dev/sda3 1003520 5860532223 5859528704 2.7T Linux LVM
thanks and kind regards,
-Christian
--
Dr. Christian Herzog support: +41 44 633 26 68
Head, IT Services Group, HPT H 8 voice: +41 44 633 39 50
Department of Physics, ETH Zurich
8093 Zurich, Switzerland http://isg.phys.ethz.ch/
Bug#1028541: lvm2: LVM filters render server unbootable
Package: lvm2
Version: 2.03.16-2
Severity: important
Dear Maintainer,
* What led up to the situation?
on our storage servers, we employ LVM filters to hide data partitions
from the OS (since they're iSCSI exported to the frontend
fileserver). With bookworm, lvm does not activate the root VG when
filters are in place. So far we have been able to establish the
following facts:
- with the default global_filter settings, it does boot
- with global_filter = [ "a|pci-:04.*|", "r|.*|" ] (to only
activate the root VG) bookworm drops into busybox (no root fs
found)
- manually activating the root VG in busybox allows us to boot
(by copy/pasting the IMPORT{program} lines from the udev rule)
- replacing /usr/sbin/lvm and /lib/udev/rules.d/69-lvm.rules on
bookworm with the bullseye versions fixes the problem
- the problem seems to be related (but not identical) to #1018730
We've already spent 2 days trying to narrow down the underlying cause as
much as possible and we'd be happy to provide any additional information
since for us this is a bookworm deal breaker.
thanks,
-Christian
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-6-amd64 (SMP w/40 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages lvm2 depends on:
ii dmeventd 2:1.02.185-2
ii dmsetup2:1.02.185-2
ii libaio10.3.113-3
ii libblkid1 2.38.1-4
ii libc6 2.36-7
ii libdevmapper-event1.02.1 2:1.02.185-2
ii libedit2 3.1-20221030-2
ii libselinux13.4-1+b4
ii libsystemd0252.4-1
ii libudev1 252.4-1
ii lsb-base 11.5
ii sysvinit-utils [lsb-base] 3.06-2
Versions of packages lvm2 recommends:
pn thin-provisioning-tools
lvm2 suggests no packages.
-- Configuration Files:
/etc/lvm/lvm.conf changed:
config {
# Configuration option config/checks.
# If enabled, any LVM configuration mismatch is reported.
# This implies checking that the configuration key is understood by
# LVM and that the value of the key is the proper type. If disabled,
# any configuration mismatch is ignored and the default value is used
# without any warning (a message about the configuration key not being
# found is issued in verbose mode only).
# This configuration option has an automatic default value.
# checks = 1
# Configuration option config/abort_on_errors.
# Abort the LVM process if a configuration mismatch is found.
# This configuration option has an automatic default value.
# abort_on_errors = 0
# Configuration option config/profile_dir.
# Directory where LVM looks for configuration profiles.
# This configuration option has an automatic default value.
# profile_dir = "/etc/lvm/profile"
}
devices {
# Configuration option devices/dir.
# Directory in which to create volume group device nodes.
# Commands also accept this as a prefix on volume group names.
# This configuration option is advanced.
# This configuration option has an automatic default value.
# dir = "/dev"
# Configuration option devices/scan.
# Directories containing device nodes to use with LVM.
# This configuration option is advanced.
# This configuration option has an automatic default value.
# scan = [ "/dev" ]
# Configuration option devices/obtain_device_list_from_udev.
# Obtain the list of available devices from udev.
# This avoids opening or using any inapplicable non-block devices or
# subdirectories found in the udev directory. Any device node or
# symlink not managed by udev in the udev directory is ignored. This
# setting applies only to the udev-managed device directory; other
# directories will be scanned fully. LVM needs to be compiled with
# udev support for this setting to apply.
# This configuration option has an automatic default value.
obtain_device_list_from_udev = 1
# Configuration option devices/external_device_info_source.
# Enable device information from udev.
# If set to "udev", lvm will supplement its own native device
information
# with information from libudev. This can potentially improve the
detection
# of MD component devices and multipath component devices.
# This configuration option has an automatic default value.
external_device_info_source = "udev"
# Configuration option
Bug#697548: higher temp on PCengines APU after wheezy-jessie upgrade
Dear all, after a reboot with kernel 3.16.7-ckt11-1 the CPU temp now seems to be (almost) back to wheezy levels. Can anyone confirm this? best, -Christian -- Dr. Christian Herzog her...@phys.ethz.ch support: +41 44 633 26 68 IT Services Group, HPT H 8voice: +41 44 633 39 50 Department of Physics, ETH Zurich 8093 Zurich, Switzerland http://nic.phys.ethz.ch/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697548: higher temp on PCengines APU after wheezy-jessie upgrade
Dear Maintainer, different hardware, but same effect: after dist-upgrading my PCengines APU [1] home router/server from wheezy to jessie, thereby going from 3.2.x to 3.16.x, the CPU temp in idle mode (both cores at lowest freq at 800 MHz) rose by 9-10 degC. I noticed the same behavior several months ago on some homebrew 3.14 kernel but was hoping that the official jessie kernel would restore some magic from wheezy :) I'd really like to get CPU temps down again, is there any information that would help you track this down? thanks, -Christian [1] http://www.pcengines.ch/apu.htm -- Dr. Christian Herzog her...@phys.ethz.ch support: +41 44 633 26 68 IT Services Group, HPT H 8voice: +41 44 633 39 50 Department of Physics, ETH Zurich 8093 Zurich, Switzerland http://nic.phys.ethz.ch/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#249873: [Pkg-samba-maint] Bug#249873: (samba-common: debian samba ignores private dir directive) is also a problem with virtual hosts in Samba
Hi all, by NOT applying fhs-filespaths.patch and debuilding the samba debs we were able to get it running with multiple separate instances just fine. So please fix the FHS patch or make it an option as virtual domains are more useful/important than FHS adherence IMHO. thanks, -Christian -- Dr. Christian Herzog her...@phys.ethz.ch support: +41 44 633 26 68 IT Services Group, HPT H 8voice: +41 44 633 39 50 Department of Physics, ETH Zurich 8093 Zurich, Switzerland http://nic.phys.ethz.ch/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#488022: New findings
hey Raúl, I can confirm that your config-vortex-lenny-0.9 kernel config produces a bootable Lenny kernel (once the ABI check has been patched to stop complaining about a changed ABI version). However, our eBox-2300SX (http://www.compactpc.com.tw/ebox-2300SX.htm) now hangs at Waiting for root file system. At some point the speed of the machine is just not worth the effort. thanks for your help, -Christian -- Dr. Christian Herzog her...@phys.ethz.ch support: +41 44 633 26 68 IT Services Group, HPT D 17 voice: +41 44 633 39 50 Department of Physics, ETH Zurich CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507452: [Pkg-net-snmp-devel] Bug#507452: snmpd stops responding to remote requests after a random amount of time
Hi Jochen, some more details.. The protagonists: - phd-webxen 2.6.18-6-xen-amd64, etch Xen-DomU sending the snmpwalks - phd-node1 2.6.18-6-xen-amd64, etch Xen-Dom0 with a working snmpd - phd-xenhost 2.6.26-1-xen-amd64, lenny Xen-Dom0 with unresponsive snmpd the scenario: snmpwalk from phd-webxen to phd-node1 and phd-xenhost on phd-node1: tcpdump -i eth0 host phd-webxen|less - listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 12:35:57.272393 IP phd-webxen.ethz.ch.38851 phd-node1.ethz.ch.snmp: GetNextRequest(25) 12:35:57.273105 IP phd-node1.ethz.ch.snmp phd-webxen.ethz.ch.38851: GetResponse(105) system.sysDescr.0=[|snmp] 12:35:57.273927 IP phd-webxen.ethz.ch.38851 phd-node1.ethz.ch.snmp: GetNextRequest(28) system.sysDescr.0 12:35:57.274403 IP phd-node1.ethz.ch.snmp phd-webxen.ethz.ch.38851: GetResponse(38) system.sysObjectID.0=E:8072.3.2.10 12:35:57.274920 IP phd-webxen.ethz.ch.38851 phd-node1.ethz.ch.snmp: GetNextRequest(28) system.sysObjectID.0 12:35:57.275140 IP phd-node1.ethz.ch.snmp phd-webxen.ethz.ch.38851: GetResponse(32) system.sysUpTime.0=121516337 12:35:57.275568 IP phd-webxen.ethz.ch.38851 phd-node1.ethz.ch.snmp: GetNextRequest(28) system.sysUpTime.0 12:35:57.275712 IP phd-node1.ethz.ch.snmp phd-webxen.ethz.ch.38851: GetResponse(88) system.sysContact.0=[|snmp] 12:35:57.276015 IP phd-webxen.ethz.ch.38851 phd-node1.ethz.ch.snmp: GetNextRequest(28) system.sysContact.0 12:35:57.276132 IP phd-node1.ethz.ch.snmp phd-webxen.ethz.ch.38851: GetResponse(37) system.sysName.0=phd-node1 12:35:57.276506 IP phd-webxen.ethz.ch.38851 phd-node1.ethz.ch.snmp: GetNextRequest(28) system.sysName.0 12:35:57.276704 IP phd-node1.ethz.ch.snmp phd-webxen.ethz.ch.38851: GetResponse(74) system.sysLocation.0=[|snmp] 12:35:57.277013 IP phd-webxen.ethz.ch.38851 phd-node1.ethz.ch.snmp: GetNextRequest(28) system.sysLocation.0 12:35:57.277184 IP phd-node1.ethz.ch.snmp phd-webxen.ethz.ch.38851: GetResponse(29) system.8.0=0 12:35:57.277507 IP phd-webxen.ethz.ch.38851 phd-node1.ethz.ch.snmp: GetNextRequest(28) system.8.0 12:35:57.277645 IP phd-node1.ethz.ch.snmp phd-webxen.ethz.ch.38851: GetResponse(36) system.9.1.2.1=31 12:35:57.278165 IP phd-webxen.ethz.ch.38851 phd-node1.ethz.ch.snmp: GetNextRequest(30) system.9.1.2.1 12:35:57.278569 IP phd-node1.ethz.ch.snmp phd-webxen.ethz.ch.38851: GetResponse(36) system.9.1.2.2=S:1 12:35:57.279163 IP phd-webxen.ethz.ch.38851 phd-node1.ethz.ch.snmp: GetNextRequest(30) system.9.1.2.2 [...] - on phd-xenhost: tcpdump -i eth0 host phd-webxen|less - listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 12:37:23.124578 IP phd-webxen.ethz.ch.38851 phd-xenhost.ethz.ch.snmp: GetNextRequest(25) 12:37:24.125875 IP phd-webxen.ethz.ch.38851 phd-xenhost.ethz.ch.snmp: GetNextRequest(25) 12:37:25.129819 IP phd-webxen.ethz.ch.38851 phd-xenhost.ethz.ch.snmp: GetNextRequest(25) 12:37:26.133720 IP phd-webxen.ethz.ch.38851 phd-xenhost.ethz.ch.snmp: GetNextRequest(25) 12:37:27.139761 IP phd-webxen.ethz.ch.38851 phd-xenhost.ethz.ch.snmp: GetNextRequest(25) 12:37:28.141762 IP phd-webxen.ethz.ch.38851 phd-xenhost.ethz.ch.snmp: GetNextRequest(25) - I don't believe in a network problem because each and every other service on phd-xenhost is working just fine, and after a reboot also snmp works for some time. thanks, -Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507452: [Pkg-net-snmp-devel] Bug#507452: snmpd stops responding to remote requests after a random amount of time
Hi Jochen, thanks a lot for your answer. I ran snmpd via strace with the same parameters that /etc/init.d/ uses. A local snmpwalk works as usual, but the remote one was stuck from the beginning. This would support your conjecture that it's kernel related. The strace output of the unanswered remote snmpwalk can be found here: http://www.phys.ethz.ch/~daduke/snmpd_no_response.log I hope you'll be able to read something out of it, because I'm not. One additional piece of information that might be of interest: as already mentioned, this is a Xen dom0. Two weeks ago the lenny Xen kernel was not stable, hence I used etch's 2.6.18. The latest 2.6.26-10 seems to run better and I switched back. The snmp problem is present with both kernels on the lenny system. However, servers running etch and 2.6.18 with the same snmpd config respond to snmpwalks just fine. Please let me know if I can be of any further assistance. thanks, -Christian On Tue, Dec 02, 2008 at 07:00:44PM +0100, Jochen Friedrich wrote: Hi Christian, after a random amount of time (hours to a few days), snmpd stops responding to remote requests. Local requests continue to work. A restart of snmpd does not solve the problem, only a reboot does. Could yo run snmpd -f via strace in such a case? If a restart of snmpd doesn't help it looks like the problem could be caused by some kernel settings the snmpd daemon tries to access (maybe some unexpected proc variable contents or similar). Thanks, Jochen -- Dr. Christian Herzoge-mail: [EMAIL PROTECTED] IT Systems Specialist voice: +41 44 633 3950 Department of Physics office:HPT D 17 Swiss Federal Institute of Technology 8093 Zurich,Switzerland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507452: [Pkg-net-snmp-devel] Bug#507452: snmpd stops responding to remote requests after a random amount of time
Hi Jochen, thanks again. This looks like there is a problem with the network somewhere. The client seems to repeat the same request 5 times (recvmsg) and snmpd answers (sendmsg). However, the client doesn't seem to get the response. Is it possible to run a trace via wireshark on the client and on the server to check where the response packets get lost? I've already tried using tcpdump for that purpose. I see the incoming requests, but nothing going out (on the machine running smnpd). But I'll try again tomorrow. cheers, -Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507452: snmpd stops responding to remote requests after a random amount of time
Package: snmpd Version: 5.4.1~dfsg-11 Severity: important after a random amount of time (hours to a few days), snmpd stops responding to remote requests. Local requests continue to work. A restart of snmpd does not solve the problem, only a reboot does. In the log file, requests are being logged, they're just not being answered. A tcpdump confirms this. This is in a Xen dom0 on AMD64. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages snmpd depends on: ii adduser3.110 add and remove users and groups ii debconf1.5.24Debian configuration management sy ii libc6 2.7-16GNU C Library: Shared libraries ii libsnmp15 5.4.1~dfsg-11 SNMP (Simple Network Management Pr ii libwrap0 7.6.q-16 Wietse Venema's TCP wrappers libra snmpd recommends no packages. snmpd suggests no packages. -- debconf information: snmpd/upgradefrom521: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469462: X access wide open on LTSP clients
Package: ltsp Version: 5.0.40~bzr20080214-1~40.etch.0 Severity: critical X connections to :6 on LTSP clients are possible from any machine on the network. Some notes: - LDM_DIRECTX = False or True does not change anything - on the client, X is running with the '-auth /root/.Xauthority' flag. However, /root is mounted ro by default. Adding it to copy_dirs in /etc/default/ltsp-client-setup allows .Xauthority to be generated, but X connections are still possible. - using iptables rules, we could at least restrict access to the terminal server best, -Christian -- Dr. Christian Herzoge-mail: [EMAIL PROTECTED] IT Systems Specialist voice: +41 44 633 3950 Department of Physics office: HPR E86.1 Swiss Federal Institute of Technology 8093 Zurich,Switzerland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417509: ITP - RFP for pandorafms-agent
retitle 417509 RFP: pandorafms-agent -- Free Monitoring System agent thanks hi I'm giving back this ITP because we found hobbit in the meantime. This solves all our scaling issues with big brother. cheers, -Christian -- Dr. Christian Herzog, HPR E86.1 email: [EMAIL PROTECTED] Departement Physik, ETH Zurichvoice: +41 44 633 3950 CH-8093 Zurichfax: +41 44 633 1239 Switzerland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
