Consistently reproducible "device or resource busy" error on partitioning

Bug #341928 reported by Ronald McCollam on 2009-03-12
2
Affects Status Importance Assigned to Milestone
lvm2 (Debian)
Fix Released
Unknown
lvm2 (Ubuntu)
High
Colin Watson
Jaunty
High
Colin Watson

Bug Description

Upon partitioning during install, I receive the following message:

Error informing the kernel about modifications to partition /dev/cciss/c0d0p1 -- Device or resource busy. This means Linux won't know about any changes you made to /dev/cciss/c0d0p1 until you reboot -- so you shouldn't mount it or use it in any way before rebooting.

I can reliably reproduce this about 75% of the time. I believe it is so reproducible as this machine is being reimaged with a different partitioning scheme each time before I run the installer.

I will attach syslog and partman and can reproduce this as necessary to get additional information. These logs are from an HP Proliant DL320s G1 with the Jaunty server amd64 image from March 10 2009 but it is occurring on multiple different machines and disc images.

Per cjwatson I am creating a new bug rather than attaching this to an existing similar bug.

Related branches

Ronald McCollam (fader) wrote :
Ronald McCollam (fader) wrote :
description: updated
Colin Watson (cjwatson) on 2009-03-12
Changed in ubiquity:
importance: Undecided → High
Ronald McCollam (fader) wrote :

This is still reliably repeatable on at least one machine using the Jaunty Server image from 17 March 2009.

The machine is 'berkelium' in the enablement testing environment, an HP Proliant DL360 G5.

Attached are syslog and partman from the installer. I'm pretty consistently able to reproduce this -- I just got it twice in a row. It can be reproduced here, or for reference here's what I'm doing:

1. Start with a system partitioned to use LVM.
2. Perform an install attempting to repartition the LVM space as a single normal partition.
3. Observe the behavior described above.

I'm not sure if the steps above are specifically related to reproducing this bug, but merely describing what we're doing when we see it.

Ronald McCollam (fader) wrote :
Ronald McCollam (fader) wrote :

Reproduced again; new logfiles

Ronald McCollam (fader) wrote :
Ronald McCollam (fader) wrote :

Output of dmsetup ls:

~ # dmsetup ls
PPA-berkelium--diskcow (252, 3)
PPA-berkelium--swap (252, 0)
PPA-berkelium--swapcow (252, 1)
PPA-berkelium--disk (252, 2)
~ #

Ronald McCollam (fader) wrote :

Most recent logs

Ronald McCollam (fader) wrote :
Ronald McCollam (fader) wrote :

syslog after adding 'set -x' to /lib/partman/lib/lvm-remove.sh

Ronald McCollam (fader) wrote :

partman after adding 'set -x' to /lib/partman/lib/lvm-remove.sh

Colin Watson (cjwatson) wrote :

17:51 <cjwatson> fader: thanks. One hopefully last question: what does 'pvs --noheadings --nosuffix -o pv_name' say?
17:51 <cjwatson> it's failing because it thinks there is no PV on /dev/cciss/c0d0
17:52 <fader> ~ # pvs --noheadings --nosuffix -o pv_name
17:52 <fader> /dev/block/104:6

I think it would be easiest to get LVM to output more useful device names here. If this turns out not to be possible then I'll reassign the bug to partman-lvm.

Changed in debian-installer (Ubuntu):
assignee: nobody → cjwatson
status: New → Triaged

On Wed, 2009-03-18 at 18:08 +0000, Colin Watson wrote:

> 17:51 <cjwatson> fader: thanks. One hopefully last question: what does 'pvs --noheadings --nosuffix -o pv_name' say?
> 17:51 <cjwatson> it's failing because it thinks there is no PV on /dev/cciss/c0d0
> 17:52 <fader> ~ # pvs --noheadings --nosuffix -o pv_name
> 17:52 <fader> /dev/block/104:6
>
Err, *blink*

NOTHING should be resolving to those /dev/block names.

Can you attach the /etc/blkid.tab file?

Scott
--
Scott James Remnant
<email address hidden>

Ronald McCollam (fader) wrote :

There doesn't seem to be an /etc/blkid.tab file, and find / -name "blkid.tab" returns nothing.

Colin Watson (cjwatson) wrote :

I wouldn't expect there to be a blkid.tab in the installer anyway. /etc/lvm/cache/.cache lists the /dev/block/ names, but removing it doesn't change the output.

The problem here is actually that lvm2 itself does a full scan of /dev, and has logic to decide which device names it prefers when they have the same major and minor numbers. This doesn't cause a problem for /dev/sda1 and the like because one of its rules is that it prefers device names containing fewer slashes; but /dev/cciss/c0d0p1 and /dev/block/104:1 are just as good in its book.

Ideally we'd be able to fix this in lvm.conf, but the only way to do that at the moment, devices/preferred_names, would involve trying to list all the possible names we might want to prefer to /dev/block/, which I don't think will fly. (devices/filter doesn't work because that would cause LVM to decide that /dev/block/ is the right name and then ignore such devices entirely.)

I'll just patch _compare_paths in lib/device/dev-cache.c directly.

Colin Watson (cjwatson) on 2009-04-08
Changed in lvm2 (Ubuntu Jaunty):
status: Triaged → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lvm2 - 2.02.39-0ubuntu9

---------------
lvm2 (2.02.39-0ubuntu9) jaunty; urgency=low

  * debian/patches/avoid-dev-block.patch: Prefer any other device name over
    names in /dev/block/ (LP: #341928).

 -- Colin Watson <email address hidden> Wed, 08 Apr 2009 14:19:32 +0100

Changed in lvm2 (Ubuntu Jaunty):
status: In Progress → Fix Released
Changed in lvm2 (Debian):
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.