Bug#502618: partman: /dev/mapper/vg0-home is apparently in use by the system
On Saturday 18 October 2008, Jeroen Dekkers wrote: I currently have the same problem. The reason the logical volume is in use seems to be that when you finish partitioning and partman goes to the stage of creating the filesystems, the system has suddenly created partitions on top of the volumes. That means there is a /dev/mapper/vg0-homep1, which uses /dev/mapper/vg0-home and makes it impossible to create a filesystem there. The cause looks to be a recent change by Colin Watson in partman-base (128). If I rebuild parted_server without that change, I can no longer reproduce the error. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Bug#502618: partman: /dev/mapper/vg0-home is apparently in use by the system
On Tue, Oct 21, 2008 at 06:16:46PM +0200, Frans Pop wrote: On Saturday 18 October 2008, Jeroen Dekkers wrote: I currently have the same problem. The reason the logical volume is in use seems to be that when you finish partitioning and partman goes to the stage of creating the filesystems, the system has suddenly created partitions on top of the volumes. That means there is a /dev/mapper/vg0-homep1, which uses /dev/mapper/vg0-home and makes it impossible to create a filesystem there. The cause looks to be a recent change by Colin Watson in partman-base (128). If I rebuild parted_server without that change, I can no longer reproduce the error. That may be the proximate cause, but at most it's just exposing breakage elsewhere. The actual incorrect code is in libparted itself, not parted_server. It should not be generating p1-type device names for LVM logical volumes. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502618: partman: /dev/mapper/vg0-home is apparently in use by the system
Hi, On Tue, Oct 21, 2008 at 06:16:46PM +0200, Frans Pop wrote: The cause looks to be a recent change by Colin Watson in partman-base (128). If I rebuild parted_server without that change, I can no longer reproduce the error. Interesting. We at least had a few successful installations where version 128 was used according to the mirror's access logs, especially on those machines where it failed only on later (re)installations. So I expected the bug to be not in there. But the time when the change happened really suggests that this causes the problems. I just made a manual installation and unpacked (but not configured) partman-base_127_amd64.udeb in the right moment and it worked again without problems. So I can confirm that the changes between 127 and 128 of partman-base at least introduced this regression. P.S.: #502913 (debian-installer: mkfs.ext3 fails with raid10+dmcrypt+lvm) seems to be the same bug. Kind regards, Axel Beckert -- Axel Beckert [EMAIL PROTECTED] support: +41 44 633 2668 IT Support Group, HPT D17 (new address!) voice: +41 44 633 4189 Departement Physik, ETH Zurichfax: +41 44 633 1239 CH-8093 Zurich, Switzerland http://nic.phys.ethz.ch/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502618: partman: /dev/mapper/vg0-home is apparently in use by the system
On Tuesday 21 October 2008, Colin Watson wrote: That may be the proximate cause, but at most it's just exposing breakage elsewhere. The actual incorrect code is in libparted itself, not parted_server. It should not be generating p1-type device names for LVM logical volumes. Problem is that we're this -- close to a release. If someone wants to investigate the real cause: please do, but it'll have to be fast. In absence of a volunteer to do that I would suggest fixing the regression by a revert. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502618: partman: /dev/mapper/vg0-home is apparently in use by the system
On Tue, Oct 21, 2008 at 09:02:57PM +0200, Frans Pop wrote:
On Tuesday 21 October 2008, Colin Watson wrote:
That may be the proximate cause, but at most it's just exposing
breakage elsewhere. The actual incorrect code is in libparted itself,
not parted_server. It should not be generating p1-type device names
for LVM logical volumes.
Problem is that we're this -- close to a release. If someone wants to
investigate the real cause: please do, but it'll have to be fast.
In absence of a volunteer to do that I would suggest fixing the regression
by a revert.
Maybe something like this?
--
Colin Watson [EMAIL PROTECTED]
#! /bin/sh /usr/share/dpatch/dpatch-run
## unpartitioned-disks.dpatch by Colin Watson [EMAIL PROTECTED]
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Don't try to call BLKPG ioctls or tell device-mapper to create
## DP: partitions on disks that can't be partitioned.
@DPATCH@
diff -urNad parted-1.8.8.git.2008.03.24~/libparted/arch/linux.c
parted-1.8.8.git.2008.03.24/libparted/arch/linux.c
--- parted-1.8.8.git.2008.03.24~/libparted/arch/linux.c 2008-07-10
02:05:20.0 +0100
+++ parted-1.8.8.git.2008.03.24/libparted/arch/linux.c 2008-07-10
13:51:09.0 +0100
@@ -2102,6 +2102,18 @@
}
static int
+_has_partitions (const PedDisk* disk)
+{
+PED_ASSERT(disk != NULL, return 0);
+
+/* Some devices can't be partitioned. */
+if (!strcmp (disk-type-name, loop))
+return 0;
+
+return 1;
+}
+
+static int
_blkpg_part_command (PedDevice* dev, struct blkpg_partition* part, int op)
{
LinuxSpecific* arch_specific = LINUX_SPECIFIC (dev);
@@ -2126,6 +2138,9 @@
PED_ASSERT(disk-dev-sector_size % PED_SECTOR_SIZE_DEFAULT == 0,
return 0);
+if (!_has_partitions (disk))
+return 0;
+
if (ped_disk_type_check_feature (disk-type,
PED_DISK_TYPE_PARTITION_NAME))
vol_name = ped_partition_get_name (part);
@@ -2174,6 +2189,9 @@
{
struct blkpg_partition linux_part;
+if (!_has_partitions (disk))
+return 0;
+
memset (linux_part, 0, sizeof (linux_part));
linux_part.pno = n;
return _blkpg_part_command (disk-dev, linux_part,
@@ -2351,6 +2369,9 @@
char* dev_name = NULL;
char* params = NULL;
+if (!_has_partitions(disk))
+return 0;
+
dev_name = _device_get_part_path (disk-dev, part-num);
if (!dev_name)
return 0;
Bug#502618: partman: /dev/mapper/vg0-home is apparently in use by the system
On Tuesday 21 October 2008, Colin Watson wrote: Maybe something like this? Thanks for the patch. I'll give it a try tomorrow. If that is correct, we can probably remove a few tests for loop devices in partman: - partman-base/choose_partition/partition_tree/do_option: 55 - partman-base/parted_server.c: 941 (maybe) The following should probably remain: - partman-lvm/update.d/lvm_sync_flag: 31 - partman-partitioning/active_partition/delete/choices: 14 - partman-partitioning/active_partition/resize/choices: 14 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502618: partman: /dev/mapper/vg0-home is apparently in use by the system
I can confirm that Colin's patch of Tue, 21 Oct 2008 22:57:45 +0100 fixes the problem for me on a test install on amd64. I tested by building parted and then putting the udeb into localudebs and putting it into the initrd. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502618: partman: /dev/mapper/vg0-home is apparently in use by the system
As further confirmation, I've just tested an install on an armel box with Colin's patch, and it worked nicely there, too. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502618: partman: /dev/mapper/vg0-home is apparently in use by the system
I have the same problem, including the partitions on top of the logical volumes: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502432 I asked to mark my bug as duplicate or something. greez Mario -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502618: partman: /dev/mapper/vg0-home is apparently in use by the system
On Sun, Oct 19, 2008 at 12:20:34AM +0200, Marc Haber wrote: On Sat, Oct 18, 2008 at 06:01:12PM +0200, Jeroen Dekkers wrote: I currently have the same problem. The reason the logical volume is in use seems to be that when you finish partitioning and partman goes to the stage of creating the filesystems, the system has suddenly created partitions on top of the volumes. That means there is a /dev/mapper/vg0-homep1, which uses /dev/mapper/vg0-home and makes it impossible to create a filesystem there. Yes, that's exactly the situation on my system. I tried installing twice today, and in the first attempt it even showed the homep1 LV in the partition list in the Installer. In the second attempt, it didn't, but the homep1 LV was there when I looked in /dev/mapper. So far, it looks like the partitions are generated when one says Write changes to disk, but they don't show up when one uses fdisk to look into the LVs. Strange. A workaround is to partition with the Debian installer, abort and reboot into a live CD (I used grml, which I highly recommend for all rescue operations), format the file systems from there, restart the installer and partitioner, tell it the intended mount points, but forbid it to format the partitions, tell it _NOT_ to use the swap partition and ignore the resulting error message. After that, the installation is able to continue. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502618: partman: /dev/mapper/vg0-home is apparently in use by the system
Package: installation-reports Severity: important Trying to install lenny on a physical machine which has already one Windows partition, using today's daily image. Intended disk layout: │ LVM VG vg0, LV home - 40.0 GB Linux device-mapper (linear) │ │ #140.0 GB f ext3/home│ │ LVM VG vg0, LV root - 499.1 MB Linux device-mapper (linear) │ │ #1 499.1 MB f ext3/│ │ LVM VG vg0, LV swap1 - 2.0 GB Linux device-mapper (linear) │ │ #1 2.0 GB F swapswap │ │ LVM VG vg0, LV usr - 6.0 GB Linux device-mapper (linear)│ │ #1 6.0 GB f ext3/usr │ │ LVM VG vg0, LV var - 6.0 GB Linux device-mapper (linear)│ │ #1 6.0 GB f ext3/var │ │ SCSI1 (0,0,0) (sda) - 500.1 GB ATA ST3500630AS │ │ #1 primary 104.9 GB B ntfs │ │ #2 primary 197.4 MB F ext3/boot│ │ #3 primary 395.1 GB K lvm │ When saying Finish partitioning and write changes to disk, the installer says The ext3 file system creation in partition #1 of LVM VG vg0, LV home failed, and syslog says Oct 18 11:45:27 partman: /dev/mapper/vg0-home is apparently in use by the system; will not make a filesystem here!. # cat /proc/mounts rootfs / rootfs rw 0 0 none /proc proc rw 0 0 none /sys sysfs rw 0 0 tmpfs /dev tmpfs rw,mode=755 0 0 none /dev/pts devpts rw,mode=600 0 0 /dev/hdb /cdrom iso9660 ro 0 0 # partman and system log are attached. I'll keep the system in this state until tonight and am available on #debian-boot on OFTC. Greetings Marc partitioner.log.bz2 Description: BZip2 compressed data syslog.bz2 Description: BZip2 compressed data
Bug#502618: partman: /dev/mapper/vg0-home is apparently in use by the system
severity 502618 serious thanks On Saturday 18 October 2008, Marc Haber wrote: When saying Finish partitioning and write changes to disk, the installer says The ext3 file system creation in partition #1 of LVM VG vg0, LV home failed, and syslog says Oct 18 11:45:27 partman: /dev/mapper/vg0-home is apparently in use by the system; will not make a filesystem here!. Additional info from #d-boot: [17:30:13] Jeroen Zugschlus: I currently have the same problem as you reported in bug #502618, has the installer also created partitions on your lvm volumes on your system, so that /dev/mapper/vg0-homep1 exists? [17:30:46] Jeroen Zugschlus: that seems to be the reason why it's in use Jeroen is [EMAIL PROTECTED] (Jeroen Dekkers) on channels: #debian-boot #osm-nl #osm #gnu.nl #vrijschrift #linux.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502618: partman: /dev/mapper/vg0-home is apparently in use by the system
I currently have the same problem. The reason the logical volume is in use seems to be that when you finish partitioning and partman goes to the stage of creating the filesystems, the system has suddenly created partitions on top of the volumes. That means there is a /dev/mapper/vg0-homep1, which uses /dev/mapper/vg0-home and makes it impossible to create a filesystem there. Regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502618: partman: /dev/mapper/vg0-home is apparently in use by the system
On Sat, Oct 18, 2008 at 06:01:12PM +0200, Jeroen Dekkers wrote: I currently have the same problem. The reason the logical volume is in use seems to be that when you finish partitioning and partman goes to the stage of creating the filesystems, the system has suddenly created partitions on top of the volumes. That means there is a /dev/mapper/vg0-homep1, which uses /dev/mapper/vg0-home and makes it impossible to create a filesystem there. Yes, that's exactly the situation on my system. I tried installing twice today, and in the first attempt it even showed the homep1 LV in the partition list in the Installer. In the second attempt, it didn't, but the homep1 LV was there when I looked in /dev/mapper. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
