Error informing the kernel about modificatons

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

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1220165

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.

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

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.

--Bob.

(using XUbuntu Saucy Beta1 from a USB stick)

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

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.

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

I believe bug #1229719 may also be a duplicate.

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

http://iso.qa.ubuntu.com/qatracker/milestones/303/builds/54263/testcases/1302/results

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

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

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.

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?

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.

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

Aren't the tests for iso.qa.ubuntu.com kept on file somehow so that can be looked up?

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.

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.

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.

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

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

Hi, could you have a read through https://wiki.ubuntu.com/DebuggingUbiquity and see if you make the bug reproducable.

Regards,

Phill.

@ 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.

@ 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 :)

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.

I fell on my face performing this:

https://wiki.ubuntu.com/DebuggingUbiquity#Deeper_debugging_of_partman

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 :^)

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.

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.

This happened even with the Alternate install image.

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.

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

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

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.

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.

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.

attached /proc/mounts

attached /proc/swaps

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.

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.

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.

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.

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.

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.

@ 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.

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.
Regards,
Phill.

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, 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 :)
Regards,
Phill.

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

@ colin, 1st time I've seen it.. I'm an alternate / server person... But this is a major issue http://imagebin.org/273686 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::

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

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

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

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

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..

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