[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#558686: Partition manager fails to update kernel partition table



reassign 558686 partman-base
severity 558686 important
thanks

On Sunday 29 November 2009, Torsten Landschoff wrote:
> parted_server: OUT: Error informing the kernel about modifications to
> partition /dev/sda2 -- Device or resource busy.  This means Linux won't
> know about any changes you made to /dev/sda2 until you reboot -- so you
> shouldn't mount it or use it in any way before rebooting.

We've had a few other similar reports. So far no pattern has emerged.

What can be seen from your logs is that you're creating an LVM on RAID 
setup using manual partitioning. The error occurs during the *first* time 
partman tries to commit changes to disk.

I've just spent about 4 hours trying to reproduce the error in Virtualbox. 
AFAICT I've succeeded in reconstructing exactly what you did in partman 
before the error occurred: the resulting partman log (attached) is 
identical, except for:
- you have /dev/sdX, I have /dev/hdX
- partition sizes
- in my case there is no error!

Here's what I did to reproduce your actions.

<snip>
Starting position:
Disk a: msdos disklabel
- primairy ext4 partition 1
- logical swap partition 5
- free space at end of disk
Disk b: no disklabel

Start partman
Choose: Guided LVM, but Go Back immediately
Choose: Manual
Select disk a and create new disklabel
Select disk b and create new disklabel
Create xGB primairy partition on disk a (different size than existing 
partition 1)
- use as RAID
- delete partition
Create xGB primairy partition on disk a
- change mountpoint and select /boot
- change type to ext2
- mark bootable
- done
Select just created partition
- use as RAID
- done
Create xGB primairy partition on disk b
- change mountpoint, but Go Back immediately
- use as RAID
- done
Create yGB primairy partition on disk a (leave some free space)
- use as RAID
- done
Create yGB primairy partition on disk b
- use as RAID
- done
Choose: Configure RAID
- Accept to commit changes
=> for me: success; for you: error message
</snip>

I *can* reproduce the error by manually activating swap on /dev/hda5 from a 
debug shell just before starting partman, except that it complains about
/dev/hda1 instead of /dev/sda2.
If I then switch to a debug shell and do 'fdisk -l /dev/hda', I see that - 
despite the error message - the partition table *has* been changed, and if 
I check 'free' I see that swap is disabled. So AFAICT your action to write 
the partition table again from fdisk was probably redundant.

Questions:
- did you do anything special or manually in the early part of the
  installation (before the start of partitioning)?
- did you do anything special or manually during partitioning before
  the error occurred?
- does my reconstruction above match what you did, or was there anything
  different?
Please think carefully: this is a subtle issue, details are essential.

As already requested, please send the syslog of the installation! You can 
find it under /var/log/installer on the installed system.

Some wild theories:
1) this is a libparted bug; somehow it manages to confuse itself about the
   state of the disk (busy or not busy)
2) this is a kernel bug; somehow it gives incorrect info to libparted
   (possibly related to command queueing?)
3) for some reason swap *was* active in your test (but WHY?); partman
   disables swap just before committing changes, but this is not 100%
   completed before changes really do get committed
4) something other than swap really is keeping the disk busy
For now my guess is either 1) or 3).

Cheers,
FJP

Attachment: partman_vb.log.gz
Description: GNU Zip compressed data


Reply to: