Error informing the kernel about modificatons

Bug #1220165 reported by Lars Noodén on 2013-09-03
This bug affects 12 people
Affects Status Importance Assigned to Milestone
parted (Ubuntu)
Colin Watson

Bug Description

When installing the desktop powerpc image, the installer comes up with an error message:

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

I made no changes. The installer comes up with this error all on its own right before the "Where are you?" screen.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: ubiquity 2.15.16
ProcVersionSignature: Ubuntu 3.11.0-1.2-powerpc-smp 3.11.0-rc7
Uname: Linux 3.11.0-1-powerpc-smp ppc
ApportVersion: 2.12.1-0ubuntu3
Architecture: powerpc
CasperVersion: 1.336
Date: Tue Sep 3 09:51:27 2013
InstallCmdLine: ro ramdisk_size=1048576 file=/cdrom/preseed/lubuntu.seed boot=casper quiet splash -- video=radeonfb:1280x854-32@60
LiveMediaBuild: Lubuntu 13.10 "Saucy Salamander" - Alpha powerpc (20130902.1)
MarkForUpload: True
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

Lars Noodén (larsnooden) wrote :
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:

tags: added: iso-testing
Brian Murray (brian-murray) wrote :

This looks suspicious:

Sep 3 09:48:38 lubuntu kernel: [ 306.906160] XFS (sda1): bad magic number
Sep 3 09:48:38 lubuntu kernel: [ 306.906176] de9c5000: 50 4d 00 00 00 00 00 07 00 00 00 01 00 00 00 3f PM.............?
Sep 3 09:48:38 lubuntu kernel: [ 306.906185] de9c5010: 41 70 70 6c 65 00 00 00 00 00 00 00 00 00 00 00 Apple...........
Sep 3 09:48:38 lubuntu kernel: [ 306.906191] de9c5020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Sep 3 09:48:38 lubuntu kernel: [ 306.906197] de9c5030: 41 70 70 6c 65 5f 70 61 72 74 69 74 69 6f 6e 5f Apple_partition_
Sep 3 09:48:38 lubuntu kernel: [ 306.906206] XFS (sda1): Internal error xfs_sb_read_verify at line 780 of file /build/buildd/linux-ppc-3.11.0/fs/xfs/xfs_mount.c. Caller 0xf3ecbcdc
Sep 3 09:48:38 lubuntu kernel: [ 306.906206]
Sep 3 09:48:38 lubuntu kernel: [ 306.906219] CPU: 0 PID: 5 Comm: kworker/0:0H Tainted: GF C 3.11.0-1-powerpc-smp #2-Ubuntu
Sep 3 09:48:38 lubuntu kernel: [ 306.906408] Workqueue: xfslogd xfs_buf_iodone_work [xfs]
Sep 3 09:48:38 lubuntu kernel: [ 306.906416] Call Trace:
Sep 3 09:48:38 lubuntu kernel: [ 306.906435] [ef87fdc0] [c00098f8] show_stack+0xf8/0x1b0 (unreliable)
Sep 3 09:48:38 lubuntu kernel: [ 306.906449] [ef87fe10] [c06dfa0c] dump_stack+0x78/0xa0
Sep 3 09:48:38 lubuntu kernel: [ 306.906511] [ef87fe20] [f3ece970] xfs_corruption_error+0x78/0x98 [xfs]
Sep 3 09:48:38 lubuntu kernel: [ 306.906599] [ef87fe50] [f3f2e378] xfs_sb_read_verify+0x10c/0x12c [xfs]
Sep 3 09:48:38 lubuntu kernel: [ 306.906654] [ef87fe80] [f3ecbcdc] xfs_buf_iodone_work+0xb4/0xd8 [xfs]
Sep 3 09:48:38 lubuntu kernel: [ 306.906671] [ef87fe90] [c005c2e0] process_one_work+0x158/0x3c8
Sep 3 09:48:38 lubuntu kernel: [ 306.906679] [ef87fec0] [c005cc5c] worker_thread+0x134/0x3fc
Sep 3 09:48:38 lubuntu kernel: [ 306.906691] [ef87fef0] [c0064160] kthread+0xb4/0xb8
Sep 3 09:48:38 lubuntu kernel: [ 306.906700] [ef87ff40] [c0017140] ret_from_kernel_thread+0x5c/0x64
Sep 3 09:48:38 lubuntu kernel: [ 306.906707] XFS (sda1): Corruption detected. Unmount and run xfs_repair
Sep 3 09:48:38 lubuntu kernel: [ 306.906733] XFS (sda1): SB validate failed with error 22.

Changed in ubiquity (Ubuntu):
importance: Undecided → Medium
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Bob Jonkman (bjonkman) wrote :

I did make changes to a partition.

The error dialog box will not close, neither "Ignore" nor "Cancel" nor the "X" button work. Ubiquity is now unresponsive in a background window. The installation cannot continue.


(using XUbuntu Saucy Beta1 from a USB stick)

Erick Brunzell (lbsolost) wrote :

I'm marking bug #1229560 as a duplicate, but there may be info there that's useful.

Elfy (elfy) wrote :

Seen the same thing fro beta2 install.

Slightly different partitions.

Ignore option however did allow install to proceed.

This install was for a 'use entire disk' type install.

Elfy (elfy) wrote :

Previous comment was an entire disk overwriting a 32bit install from 23rd Septembers b2 testing

Just got exactly the same bug again, entire disk again, overwriting a 64bit with a new 32bit install

Erick Brunzell (lbsolost) wrote :

I believe bug #1229719 may also be a duplicate.

Lars Noodén (larsnooden) wrote :

I also got this with the AMD64 architecture using the amd64+mac disc image:

Changed in ubiquity (Ubuntu):
importance: Medium → High
summary: - Error informing the kernel
+ Error reading xfs partitions

I've encountered this repeatedly testing only Ubuntu based distros so I don't think it's limited to XFS.

Brian Murray (brian-murray) wrote :

The log files indicate an error while trying to read an XFS partition already existing on one of the disks on the system.

Elfy (elfy) wrote :

Probably needs to be either a generic bug or specific ones per filesystem.

I mistakenly me too'd this one and commented here - I was definitely using ext4.

Lars Noodén (larsnooden) wrote :

I had no xfs partition on that machine (that I know of). When it happens again I will grab try to remember to grab the logs. It does not happen every time though. Which file is needed? syslog?

Erick Brunzell (lbsolost) wrote :

In order to prove that this is not just an XFS problem I filed a new bug #1231710 and here's what I started with:

lance@lance-desktop:~$ sudo parted -l
[sudo] password for lance:
Model: ATA WDC WD800BB-63JK (scsi)
Disk /dev/sda: 80.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 1049kB 57.6GB 57.6GB primary ext4 boot
 2 57.6GB 80.0GB 22.4GB extended
 6 57.6GB 77.9GB 20.3GB logical ext4
 5 77.9GB 80.0GB 2136MB logical linux-swap(v1)

lance@lance-desktop:~$ sudo blkid
/dev/sda1: UUID="9f906d04-f024-4834-be4d-c833a8149667" TYPE="ext4"
/dev/sda5: UUID="da2d5705-2cb2-4f58-ad81-32b7bd6def81" TYPE="swap"
/dev/sda6: UUID="d9a3994a-233b-43bf-b251-cc21a894260b" TYPE="ext4"

Now, to be perfectly clear, that was a dual-boot of two Lubuntu i386 20130925 images. I tested both before proceeding and they both booted and performed as expected, but I know from personal experience that this also effects Ubuntu GNOME 20130926 images - both i386 and amd64.

Please let me know what other info I can provide.

summary: - Error reading xfs partitions
+ Error informing the kernel about modificatons
Lars Noodén (larsnooden) wrote :
affects: ubiquity (Ubuntu) → linux (Ubuntu)
tags: added: kernel-key
Joseph Salisbury (jsalisbury) wrote :

Does anyone affected by this bug know which daily iso this started happen in?

Lars Noodén (larsnooden) wrote :

Aren't the tests for kept on file somehow so that can be looked up?

Tim Gardner (timg-tpi) on 2013-10-08
affects: linux (Ubuntu) → linux-ppc (Ubuntu)
Changed in linux (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Andy Whitcroft (apw) wrote :

It should be noted that we are whining about /dev/sda3:

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

Andy Whitcroft (apw) wrote :

It should be noted that sda3 is the only partition we seem to successfully mount during probing, and that its neibour sda4 which shares a boundary with it is also potentially active as swap:

Sep 3 09:48:46 lubuntu kernel: [ 314.598101] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)
Sep 3 09:48:46 lubuntu 40lsb: result: /dev/sda3:Ubuntu Saucy Salamander (development branch) (13.10):Ubuntu:linux
Sep 3 09:45:18 lubuntu kernel: [ 94.421151] Adding 2439064k swap on /dev/sda4. Priority:-1 extents:1 across:2439064k FS
Sep 3 09:48:46 lubuntu os-prober: debug: /dev/sda4: is active swap

We should get into this situation and try and activate the emergency holographic shell and see which partitions are actually active and why. As if they are active then the kernel would correctly prevent their modification.

Brad Figg (brad-figg) wrote :

I was seeing this issue on a macbook air. I just tried the daily image from today and it installed just fine without this error.

Lars Noodén (larsnooden) wrote :

Being an intermittent bug, it just popped up again:

Linux lubuntu 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Lars Noodén (larsnooden) wrote :

Again this is with the Lubuntu Desktop amd64+mac image from 2013-10-10

Phill Whiteside (phillw) wrote :

Hi, could you have a read through and see if you make the bug reproducable.



Erick Brunzell (lbsolost) wrote :

@ Phil, while I'm sure there are other ways of reproducing this look at comment #15. I can reliably reproduce this in a *buntu dual boot time and time again. I'm suspicious of ubiquity-partman but that's just a guess.

Phill Whiteside (phillw) wrote :

@ Erick, please do so using the instructions from #24. The 'conversation' between a bug being reported by lots of people and the questions so far asked are lamentable. There is a bug, the devs need more information. Our head of QA suggested the link in #24; which from I can read should have been done at about #4 :)

Erick Brunzell (lbsolost) wrote :

I'll see what I can do, but this bugs UbiquityPartman log shows:

/lib/partman/commit.d/30parted: paragraph: Error informing the kernel about modifications to partition /dev/sda3 -- Device or resource busy. This means Linux won't know about any changes you made to /dev/sda3 until you reboot -- so you shouldn't mount it or use it in any way before rebooting.
/lib/partman/commit.d/30parted: error_handler: reading options
/lib/partman/commit.d/30parted: option: Ignore
/lib/partman/commit.d/30parted: option: Cancel

And my two duplicates show the same thing except the device designation is /dev/sda1.

tags: added: ubi-partman
Erick Brunzell (lbsolost) wrote :

I fell on my face performing this:

I think I didn't quite know how to restart rsyslog :^(

I'm tired now but maybe I'll try just using "ubiquity -d" tomorrow.

Look, I'm no dev by any means, but I believe this bug is tagged wrong! It's much more likely a ubiquity bug than a kernel bug, and it is "critical"! Colin Watson would know how to properly assign this :^)

Lars Noodén (larsnooden) wrote :

The error pops up from time to time on at least two architectures. Here is partman from PPC. #24 above also recommended getting the log "installer" but there is no such log that I can find. syslog will follow in the next comment.

Lars Noodén (larsnooden) wrote :
Steve Langasek (vorlon) wrote :

This error message means that one of the partitions on the disk is in use, so the kernel is refusing to update its internal partition map because this would clobber the in-use filesystems. This is not a kernel bug, it looks like an installer bug.

Please reproduce this error, and attach the contents of /proc/mounts and /proc/swaps.

affects: linux (Ubuntu) → ubiquity (Ubuntu)
Changed in ubiquity (Ubuntu):
status: Confirmed → Incomplete
Steve Langasek (vorlon) on 2013-10-12
no longer affects: linux-ppc (Ubuntu)
Lars Noodén (larsnooden) wrote :

This happened even with the Alternate install image.

Lars Noodén (larsnooden) wrote :
Changed in ubiquity (Ubuntu):
status: Incomplete → Confirmed
Steve Langasek (vorlon) wrote :

Ok, no partitions from /dev/sda are mounted, and syslog doesn't show anything else referencing it (such as via LVM). So this may actually be a bug in the kernel, since /dev/sda3 is shown in syslog as having been mounted once, and perhaps there's a reference that fails to be released. But I also don't know why the installer is trying to change the partition table anyway, so this probably needs investigation from both ends.

Erick Brunzell (lbsolost) wrote :

I think "partman" is puking all over itself, possibly trying to reuse or resize existing partitions instead of creating new partitions ;^)

Lars Noodén (larsnooden) wrote :

I also got this error outside of the installation process. On a finished system, I ran gparted and got the same error

Erick Brunzell (lbsolost) wrote :

I filed a new duplicate bug #1239515 run by launching ubiquity from the terminal with the command "ubiquity -d" and I included UUID info from prior to trying the installation as well as after the failure while ubiquity was still frozen.

Erick Brunzell (lbsolost) wrote :

I'm not marking that new bug as a duplicate. I've added a lot of info there, that's all I can do, I'll have to leave the rest to the actual devs. But it's absolutely fair to say that this is a critical bug without a doubt.

Colin Watson (cjwatson) wrote :

Reassigning down to partman-base, though that may not be exactly the right target; there are logs in this bug from d-i, not just ubiquity, so it's a common installer problem.

affects: ubiquity (Ubuntu) → partman-base (Ubuntu)
Changed in partman-base (Ubuntu):
importance: High → Critical
Elfy (elfy) wrote :

attached /proc/mounts

Elfy (elfy) wrote :

attached /proc/swaps

Colin Watson (cjwatson) wrote :

One question worth exploring here is why the kernel filesystem drivers appear to be getting involved during os-prober; we should be using grub-mount which wouldn't touch any of that code. It's quite possible for this to be relevant due to various races.

Colin Watson (cjwatson) wrote :

Aha. I managed to reproduce this in qemu after a triple install: Ubuntu amd64, Ubuntu amd64 side-by-side, Ubuntu amd64 erase disk. grub-mount may be a red herring since I'm not sure I see that here. Investigating.

Colin Watson (cjwatson) wrote :

Looks like a race between parted and a udev rule. We've fixed this type of thing before and parted already has code to attempt to work around them; probably just needs a bit more.

affects: partman-base (Ubuntu) → parted (Ubuntu)
Changed in parted (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)
status: Confirmed → Triaged
Phillip Susi (psusi) wrote :

This is very strange. The partition has to not exist, or be successfully removed in order to try to add it, and then if adding it fails, you get this error. That means someone else is also trying to add the partition at the same time, and there shouldn't be any udev rules *adding* partitions.

Colin Watson (cjwatson) wrote :

I think the immediately-prior removes may be producing change events. It's a little hard to tell because trying to instrument it to any extent (e.g. udevadm monitor) causes the race to go away.

What I'm currently trying is a patch that retries adds in much the same way that we retry removes; if that works then I think that's evidence in support of my theory.

Colin Watson (cjwatson) wrote :

I was wrong; Phillip identified this correctly as being due to a bug in avoid-disturbing-partitions.patch in the case where some of the partitions in the new layout start at the same position as partitions of the same number in the old layout but extend over parts of the disk previously occupied by partitions of higher numbers. He's working on a patch to reorder the remove/add code to avoid this.

Changed in parted (Ubuntu):
status: Triaged → In Progress
Erick Brunzell (lbsolost) wrote :

@ Colin, this is off-topic so apologies in advance, but if this requires a rebuild of 'ubiquity' could you possibly have someone look at the unrelated bug #1194898 ? It's not critical like this bug but I'm sure we'll get a lot of complaints over that. Thanks for all you do to make Ubuntu great.

Fixing this bug does not require a rebuild of ubiquity. I'll see if we
can have a look at 1194898, thanks for the heads-up - but it's getting
pretty difficult to find time for non-critical fixes at this point.

Phill Whiteside (phillw) wrote :

Pretty much confirming the suspicion of it not being Ubiquity to blame, using alternate install (server install system). On a completely removed and recreated LVM, no problem. When I asked for 'side by side, it told me that vda was still mounted. Just following the unmount prompt allows me to proceed fine. Sorry for being late; I've had a couple of days off and wanted to check an actual install, as opposed to relying on my memory.

Colin Watson (cjwatson) wrote :

On Mon, Oct 14, 2013 at 09:10:46PM -0000, Phill Whiteside wrote:
> Pretty much confirming the suspicion of it not being Ubiquity to
> blame, using alternate install (server install system). On a
> completely removed and recreated LVM, no problem. When I asked for
> 'side by side, it told me that vda was still mounted. Just following
> the unmount prompt allows me to proceed fine.

Thanks for following up, but that sounds kind of unrelated to this bug.
If you aren't seeing a message starting with "Error informing the kernel
about modifications", it isn't this.

"Still mounted" messages aren't necessarily bugs. There's a UI there to
cover it because it's a legitimate case; and I can't currently think of
a reason they'd be particularly connected to this bug, although I
suppose it's possible that they're a consequence of continuing past the
error messages somehow.

Colin Watson (cjwatson) on 2013-10-14
Changed in parted (Ubuntu):
status: In Progress → Fix Committed
Phill Whiteside (phillw) wrote :

@ Colin, as this bug is a 'grey' bug for alternate install. I'm just about to kick off the desktop install. As the installer does insist on re-downloading a load of via the internet instead of using what is on the actual ISO; it takes over an hour for me to do a test. My only option is to disconnect from the internet when trying an install as side-by-side and losing my connectivity for being able to chat :)

Phill Whiteside (phillw) wrote :

correction. Having re-read your comment. I've not filed a bug, just made a comment on the test cases it applied to.

Phill Whiteside (phillw) wrote :

@ colin, 1st time I've seen it.. I'm an alternate / server person... But this is a major issue I've updated the bug. I can not really progress with my testing when faced with that. Yet another bug reported back in the 'alpha' cycle that got ignored "2013-06-26"

::I'll bite my tongue::

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package parted - 2.3-16ubuntu1

parted (2.3-16ubuntu1) saucy; urgency=low

  [ Phillip Susi ]
  * debian/patches/avoid-disturbing-partitions.patch: remove all old
    partitions (that are not unchanged) first, then add new ones. This
    avoids an EBUSY trying to add new partitions that overlap with old ones
    that have a higher number (LP: #1220165).

  [ Colin Watson ]
  * Slight tweak to the above to continue to handle entirely unchanged
    partitions properly.
 -- Colin Watson <email address hidden> Mon, 14 Oct 2013 22:03:35 +0100

Changed in parted (Ubuntu):
status: Fix Committed → Fix Released
tags: removed: kernel-key
Andy Whitcroft (apw) wrote :

Confirming that with the 20131015 images this issue is no longer reproducible for me on my test bed.

Lars Noodén (larsnooden) wrote :

I haven't seen it either with the 2013-10-15 Alternate PPC image, though it is a bug that shows intermittently.

Colin Watson (cjwatson) wrote :

The bug we found was deterministic for any given current/desired pair of
partition layouts.

Spetsnaz (paul-praet) wrote :

I still see the issue when trying to install Ubuntu 13.10:

Kernel oopses about XFS while I don't even have an XFS-partition..

Phillip Susi (psusi) wrote :

That error is benign and unrelated to this bug, which was about getting an error informing the kernel of the new partition table.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers