Bug#453786: Accepted dnprogs 2.39.2 (source i386 all)
Raphael Hertzog wrote: On Fri, 07 Dec 2007, Patrick Caulfield wrote: dnprogs (2.39.2) unstable; urgency=low . * Fix package building with new dpkg-shlibdeps Closes: #453786 A changelog must explain the change, ie how you fixed the problem. In the future try to not forget this. :) I moved dh_makeshlibs so it ran before dh_shlibdeps in debian/rules - simple and stupid as that! Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425012: Package lvm10 not in stable
Klaus Ethgen wrote: Package: lvm10 Version: 1:1.0.8-12 Severity: critical The lvm10 package is not in stable any more so all systems with kernel 2.4 and lvm will be broken! Debian's 2.4 kernels include the device mapper patches. That will enable lvm2 to work. Although I thought that 2.4 was not supported in etch, we had all this out when lvm10 was removed. -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399665: libdnet{,-dev} should not assume the user wants to *use* DECnet
That's fair. I'll make the library packages a Recommends and the progs package a depends...there really is no point in installing the progs if you're not going to use them and I really want to ease DECnet installation as much as possible - it's complicated enough as it is! Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394819: Please remove package lvm10 from unstable
Package: ftp.debian.org Severity: normal lvm10 doesn't build on unstable anymore and is superceded upstream by lvm2 see bug report 394212. LVM2 is compatible with lvm1 metadata and supported upstream. -- System Information: Debian Release: 3.1 Architecture: sparc (sparc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=C, LC_CTYPE=en_GB.ISO-8859-1 (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394212: FTBFS
lvm10 doesn't work with 2.6 kernels and is unsupported upstream. I recommend we remove this package for etch. lvm2 works with 2.4 kernels, and is compatible with lvm10 metadata formats. and (importantly) is well supported upstream -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386070: vgcfgbackup: invalid option -- f
Jesse Molina wrote: Package: lvm10 Version: 1:1.0.8-12 Severity: normal Hi When passing options -f or --file to vgcfgbackup, I get an error; vgcfgbackup: invalid option -- f The man page says that this is a valid option. Not sure if the man page is out of date, or there is something wrong with this tool. I can't see in the man page where there is a -f option to vgcfgbackup. vgcfgrestore has one, or it's possible you also have the lvm2 tools installed. In the latter case check which man page you are reading. -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358500: Not a bug
dnprogs isn't affected by this bug as it doesn't call any routines inside uulib that use this function. The only call we make into the library is UUEncodeToStream(); where the output 'file' is always either a pipe or a socket to a mail delivery program. patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278180: lvm2: md_component_detection should default to 1 instead of 0
I am reliably informed by Alasdair that the md_component_detection is considerably better than it was. In fact it now uses the same detection algorithm that MD itself uses. So I think this should be set back on by default now. -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330166: lvm2: O_DIRECT not disabled on HPPA
Package: lvm2 Version: 2.01.14-1 Severity: important Tags: patch HPPA kernels don't support O_DIRECT, as LVM2 uses O_DIRECT to read/write metadata this option has to be disabled in ./configure. It looks to me like a simple typo in debian rules: -ifneq (,$(findstring $(DEB_HOST_ARCH), arm hpp mips mipsel)) +ifneq (,$(findstring $(DEB_HOST_ARCH), arm hppa mips mipsel)) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: hppa (parisc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8.1 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages lvm2 depends on: ii debconf 1.4.58 Debian configuration management sy ii libc62.3.5-6.0.1 GNU C Library: Shared libraries an ii libdevmapper1.01 2:1.01.04-2 The Linux Kernel Device Mapper use ii libselinux1 1.26-1 SELinux shared libraries ii lvm-common 1.5.17 The Logical Volume Manager for Lin lvm2 recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325775: /lib/lvm-10/pvmove: does not stop on SIGINT
Holger Dietze wrote: Package: lvm10 Version: 1:1.0.8-8 Severity: normal File: /lib/lvm-10/pvmove I have a long-running pvmove which I decided to abort (and resume later). According to manpage: pvmove may be safely interrupted by SIGINT while moving next free allocated logical volumes. But the pvmove process does not react to SIGINT (the next LE has been written): paul:~# kill -INT 3004 paul:~# ps s 3004 UID PID PENDING BLOCKED IGNORED CAUGHT STAT TTYTIME COMMAND 0 3004 4007 fffbfeff 0002 D+ vc/1 5:09 pvmove -v -n build /dev/ide I'll report this upstream but don't expect anything to happen to it. LVM1 is now unmaintained in favour of LVM2. -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310678: AW: Bug#310678 acknowledged by developer (Bug#310479: fixed in lvm-common 1.5.19)
Michael Setzer wrote: Patrick, I'm not pretty sure if I got you right. After upgrading lvm-common to 1.5.19 the error is still there and my system is still unbootable (same error message as described already). It certainly fixed the problem for the original reporter. Once I'd see the initrd the bug was very clear (initrds don't contain vgscan, but they do contain vgchange). Can you send me your initrd and I'll see how it differs from the ones I wes sent yesterday. -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310678: AW: Bug#310678 acknowledged by developer (Bug#310479: fixed in lvm-common 1.5.19)
Michael Setzer wrote: Patrick, I'm not pretty sure if I got you right. After upgrading lvm-common to 1.5.19 the error is still there and my system is still unbootable (same error message as described already). What I've done now to upgrade to 1.5.19 is: - booted with the Debian-Installer RC3 CD (linux26 vga=791) - switched to a console with CTRL+ALT+F2 when partition screen appeared - modprobe dm-mod - vgscan - vgchange -a y VG - mkdir /mnt - mount /dev/mapper/VG-root /mnt - chroot /mnt - mount /proc - mount /dev/hda5 /boot - apt-get update - apt-get install lvm-common Also, did you rebuild your initrd after upgrading ? -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310479: Severe breakage of root-on-lvm2 with lvm-common 1.5.18
Thanks. Can you try the updated package on http://people.debian.org/~patrick/ please? -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310479: Severe breakage of root-on-lvm2 with lvm-common 1.5.18
Christian Weeks wrote: Yup. That worked a treat. Thanks! Great, I'll upload that one then. -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310479: Severe breakage of root-on-lvm2 with lvm-common 1.5.18
Christian Weeks wrote: Package: lvm-common Version: 1.5.18 Severity: critical Justification: breaks the whole system I ran an upgrade this morning and picked up this package, among others, including a new kernel image. This generated a new initrd which rendered my Root on LVM system unbootable into the new kernel. Fortunately, I had a recovery kernel on hand that still worked. After some frantic recovery work, I have determined that rolling back lvm-common to 1.5.17 enables the generation of an unbroken initrd that can be booted. The error reported during the boot process is No program vgchange exists for your LVM version. Root is unmountable and the kernel panics shortly afterward. Frankly, this is a bit of a surprise- I didn't think this particular package would be the problem cause. Sorry to create an RC bug, but this almost hosed my system completely and my guess is it will break anyone who uses lvm on root after a kernel upgrade. So your initrd doesn't contain vgchange! hmmm. How ws the initrd generated and can you send me it please ? -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310479: Severe breakage of root-on-lvm2 with lvm-common 1.5.18
Christian Weeks wrote: Hmm, I've regenerated a working one now... When I was examining it, it did have vgchange contained within it, and also another vgchange under /lib/lvm-200/ (or something similar)... I figured that one of the scripts was somehow choking when it tried to execute the vgchange executable in the initrd environment. the new lvm-common looks for vgchange in the preferred /lib/lvm-XXX directory (200 for lvm2, 10 for lvm10) to determine which LVM usertools are installed, then looks in that directory for the command you wanted (in this case also vgchange, judging by the message!). Previously it just looked for the requested command which caused problems when LVM1 and LVM2 were both installed and you wanted a command that only existed for one version (e2fsadm was the actual culprit at the time). So, provided there is a vgscan in /lib/lvm-200, things /should/ work fine. ahem. After I finish work this evening (about 10 hours from now) I'll build and test that it's broken a broken one, for your perusal.. Is that OK? That's fine by me. I'll look at it tomorrow morning my (UK) time. -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303423: LVM has annoying 110% restriction on snapshot LV size
On Thu, Apr 07, 2005 at 02:49:39PM +0100, Ian Jackson wrote: Patrick Caulfield writes (Re: Bug#303423: LVM has annoying 110% restriction on snapshot LV size): There's no point in creating a snapshot any bigger! The COW mechanism copies blocks from the original device into the snapshot as they get changed, but once it's copied all the blocks once there is nothing else to use the space. the 100% restriction is just there to stop you wasting disk space. the 10% extra is to cover metadata. Indeed, that's the explanation I expected. But (a) it's undocumented and So little of LVM is documented anyway that's hardly surprising (b) 10% is an arbitrary fudge factor and Probably so. but it's probably near enough. I haven't talked to Heinz about this but I doubt he just plucked the number out of the air so I suppose it's based on some rough idea of the metadata size. (c) making it a fatal error makes it hard to write scripts reliably. The limit should be documented and either silently enforced or turned into a warning. Furthermore, the error message should be improved. There is no development happening on LVM1 now. It has all been dropped in favour of LVM2 I'm afraid. -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303423: LVM has annoying 110% restriction on snapshot LV size
On Wed, Apr 06, 2005 at 04:52:24PM +0100, Ian Jackson wrote:
Package: lvm10
Version: 1.0.4-5woody2 (source)
I have a backup system that makes snapshots of the filesystems when
backing them up. In order to minimise the risk of snapshots
overflowing, I arranged for the snapshot to use all of the free space
in the volume group (since it wasn't being sued for anything else).
However, I was foiled by this test:
if ( size lv-lv_size * 1.1) {
fprintf ( stderr, %s -- ERROR: size of snapshot is too large\n,
cmd);
return LVM_EINVALID_CMD_LINE;
This is documented nowhere that I could find. The restriction should
be removed, silently enforced, or perhaps documented. The error
message is very unhelpful too.
There's no point in creating a snapshot any bigger! The COW mechanism copies
blocks from the original device into the snapshot as they get changed, but once
it's copied all the blocks once there is nothing else to use the space. the 100%
restriction is just there to stop you wasting disk space. the 10% extra is to
cover metadata.
--
patrick
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300469: btw losetup
On Sun, Mar 20, 2005 at 12:37:09AM +0100, Christian Jaeger wrote: PS. I've noticed that the loop devices are not released. mount -o loop $from $to # this allocates a loop device, as can be seen in ps auxww # (under kernel 2.4.x, as [loop0] or similar kernel threads) # or in /proc/mounts (source of the mount point). umount $to # now it's unmounted, but the loop device is still active. # this means that the space allocated by $from is not released and # that after 8 mount cycles all loop devices are used up. I don't know whether umount $from combined with a normal /etc/mtab file will deallocate the loop device. That /does/ work normally - I use it often. If so, then my previous patch is bad. If anything I would call that a bug in umount rather than your patch. -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300469: btw losetup
On Sun, Mar 20, 2005 at 06:55:27PM +0100, Christian Jaeger wrote: Actually, I've just read the manpage for umount and have realised there is a -d option exactly for the purpose of releasing the loop device. So, additionally to applying my patch, the umount statements in lvmcreate_initrd should be changed to include the -d option. Then everything should be clean in all cases. Good catch -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293693: lvm2: lvcreate causes device-mapper ioctl cmd 9 failed: Invalid argument
On Fri, Feb 04, 2005 at 09:06:34PM -0500, Andrew Schulman wrote: I'm trying to set up LVM for the first time.??I have the?dm-mod kernel module loaded.??No?udev?or?devfs?here. The?following commands all succeed: pvcreate /dev/hda1 vgcreate vg /dev/hda1 vgchange -ay vg Now I want to create a logical volume, but the command seems to fail: # lvcreate -L15G -narchive vg ??device-mapper?ioctl?cmd?9?failed:?Invalid?argument ??Couldn't?load?device?'vg-archive'. ??Failed?to?activate?new?LV. That sounds a lot like a mismatch between libdevmapper and the kernel. Which kernel are you using? lvm version should tell you the required bits. -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292984: lvm2: lvremove causes inconsistent VG metadata
On Wed, Feb 02, 2005 at 12:23:08AM +0100, Frans Pop wrote: Hello Patrick, On Monday 31 January 2005 16:40, you wrote: Secondly try using vgcfgrestore to restore the metadata onto the disks, you only need to do this if 1) above fails I've got my system back! :-D Your suggestions and the fact that lvdisplay gave proper output led me to try vgcfgbackup -f. I reviewed the resulting file for VG sys, and it looked good. So I did a vgcfgrestore from that file, and bingo, the VG was OK again. I've now finished the reorganization and the system is back up. Thanks very much for your help. (And I learned a lot about LVM in the process.) I'll leave it to you what to do with this bug report. IMO both errors I reported are still there, but as it is after all relatively easy to recover from the resulting inconsistency (once you know how), you may want to downgrade to important. Good news! I'll close this bug when 2.01 is uploaded. Thanks for letting me know. -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293174: pvmove: manpage out of sync
On Wed, Feb 02, 2005 at 02:01:24PM +0100, Goswin von Brederlow wrote: Patrick Caulfield [EMAIL PROTECTED] writes: Ok, so only man pvmove left. Yep, -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#281925: I am using LVM2 with LVM1 on-disk under 2.6
On Wed, Feb 02, 2005 at 03:06:18PM +0100, Helge Kreutzmann wrote: If e2fsadm does not support LVM2, and 2.6 only supports LVM2, would it not be possible for e2fsadm to check for 2.6 and refuse to run? Giving me the help screen of a different command (lvmextend) is not quite helpfull right now. Yes, that's exactly what should happen... -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293174: pvmove: manpage out of sync
:-) CVSROOT:/cvs/lvm2 Module name:LVM2 Changes by: [EMAIL PROTECTED] 2005-02-02 14:31:49 Modified files: . : WHATS_NEW tools : commands.h Log message: Remove unused -f from pvmove Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/LVM2/WHATS_NEW.diff?cvsroot=lvm2r1 =1.177r2=1.178 http://sources.redhat.com/cgi-bin/cvsweb.cgi/LVM2/tools/commands.h.diff?cvsroot= lvm2r1=1.63r2=1.64 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293149: Please install libsysfs in /lib
Package: libsysfs1 Version: 1.2.0-1 Severity: normal Please can you move libsysfs into /lib ? The multipath tools rely on this library for device identification and they really need to be started before /usr is mounted if it is on a different partition. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: sparc (sparc64) Kernel: Linux 2.6.10 Locale: LANG=C, LC_CTYPE=en_GB.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages libsysfs1 depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293174: pvmove: manpage out of sync
On Tue, Feb 01, 2005 at 05:06:42PM +0100, Goswin Brederlow wrote: Package: lvm-common Version: 1.5.17 Severity: minor File: pvmove Hi, the manpage of pvmove doesn't list all options, namely -f, of pvmove and does not describe al options it mentions, namely -v. On that note: The vgsplit manpage says VGMERGE(8). That one was fixed in 2.00.30 of lvm2 -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292984: lvm2: lvremove causes inconsistent VG metadata
Two things to try: firstly, enable md_component_autodetection in /etc/lvm/lvm.conf - it look slike the system has found BOTH the MD and it's components, that explains the duplicate PV entries. If this doesn't work then add filters to lvm.conf to exclude the SCSI disks (or just include the MDs). Secondly try using vgcfgrestore to restore the metadata onto the disks, you on;y need to do this if 1) above fails -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292070: Unable to create VG on md device with newer lvm2
On Mon, Jan 24, 2005 at 11:38:53PM +, Alasdair G Kergon wrote: Check you don't have md_component_detection disabled in /etc/lvm/lvm.conf. Otherwise try adding filters. yes, md_component_detection is disabled by default in Debian because the original implementation was buggy and caused more troubles than it solved. -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#245282: Documented elsewhere
On Wed, Jan 12, 2005 at 01:57:05PM +0100, Wesley W. Terpstra wrote: This is documented in the cryptsetup package. I don't think dmsetup needs to document these features since they are not very useful without the hash functions, etc. I would close this bug if I was maintainer. :-) Agreed. dmsetup can be used to do a lot of things, but it really is just a front-end to the device-mapper targets themselves, of which crypt is but one. Documentation for targets should be part of the targets, not the manipulation too. It's like filing a bug against bash for not documenting emacs ;-) -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289888: Default max vg size of 256GB a bit on the small size nowadays...
On Tue, Jan 11, 2005 at 11:28:27AM -0500, Christian Hudon wrote: Package: lvm2 Version: 2.00.24-1 I guess 256GB was a nice large number the for default max vg size when lvm1 was started, but now that you can buy a single hard drive that is twice this size, it seems to me to be a bit on the small side for a default max vg size value. Especially given that there's no way to enlarge this value other than creating a new vg and migrating all your data from the old one to the new one. It's be nice to either increate the 65k max extents per lv limit, or at least bump the default extent size from 4MB to something bigger (that gives max vg sizes in the terabytes). You probably want to coordinate this with upstream... in lvm2 there is no limit to the size of a LV other than that imposed by the Linux block layer. -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289888: Default max vg size of 256GB a bit on the small size nowadays...
It might be that you are using LVM1 format metadata - which still has this restriction. vgconvert will upgrade that metadata to LVM2 and remove the limit. (BTW the default of 4MB PE size is years old on LVM1 (25/10/2002), and has never been a limitation in LVM2) -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289888: Default max vg size of 256GB a bit on the small size nowadays...
On Tue, Jan 11, 2005 at 12:05:08PM -0500, Christian Hudon wrote: Hmm. If that's really the case, then the manpage for vgcreate is in need of some serious updating. Some extracts: -s, --physicalextentsize PhysicalExtentSize[kKmMgGtT] Sets the physical extent size on physical volumes of this volume group. A size suffix (k for kilobytes up to t for terabytes) is optional, megabytes is the default if no suffix is present. Values can be from 8 KB to 16 GB in powers of 2. The default of 4 MB causes maximum LV sizes of ~256GB because as many as ~64k extents are supported per LV. In case larger maximum LV sizes are needed (later), you need to set the PE size to a larger value as well. Later changes of the PE size in an existing VG are not supported. ... and... To limit kernel memory usage, there is a limit of 65536 physical extents (PE) per logical volume, so the PE size determines the maximum logical volume size. The default PE size of 4MB limits a single logi- cal volume to 256GB (see the -s option to raise that limit). There is also (as of Linux 2.4) a kernel limitation of 2TB per block device. Good grief, so it does, sigh. /me pokes upstream -- patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
