Lucid: Update udev / libudev0 to 151-12.3 breaks mdadm
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
udev (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: udev
Issue:
Upgrading udev and libudev0 from 151-12 0 to 151-13.3 breaks mdadm where it cannot read mdadm.conf, and will not assemble, start, or mount a previously configured and working RAID array.
I did not try updating each package seperately as I "assumed" that udev and its supporting libraries needed to be at the same version to avoid strange artifacts.
Requested system information follows. See bottom of report for additional information.
=======
Version information:
You are using Ubuntu 10.04 LTS - the Lucid Lynx - released in April 2010 and supported until April 2013.
Info on udev:
udev:
Installed: 151-12.3
Candidate: 151-12.3
Version table:
*** 151-12.3 0
500 http://
100 /var/lib/
151-12 0
500 http://
Info on libudev0:
libudev0:
Installed: 151-12.3
Candidate: 151-12.3
Version table:
*** 151-12.3 0
500 http://
100 /var/lib/
151-12 0
500 http://
"cat" listing of the current mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR root
# definitions of existing MD arrays
ARRAY /dev/md0 level=raid5 num-devices=4
UUID=0557a93b-
# (JH) Edited on 02/21/2011 to update the "ARRAY" statement to the current raid-5 configuration.
# This file was auto-generated on Tue, 28 Sep 2010 01:33:52 -0400
# by mkconf $Id$libudev0:
Installed: 151-12.3
Candidate: 151-12.3
Version table:
*** 151-12.3 0
500 http://
100 /var/lib/
151-12 0
500 http://
Attached: A text file containing all the package revisions for all packages on my machine prior to update.
=======
Earlier I had performed an update via update manager - which updated a considerable number of files - and after rebooting I discovered that my - non boot- RAID array would not start or mount.
Attempting to start the array - or even list its characteristics - returns the following error from mdadm:
root@Storage3:
mdadm: ARRAY line /dev/md0 has no identity information.
mdadm: Unknown keyword UUID=0557a93b-
ARRAY /dev/md0 level=raid5 num-devices=4 UUID=9efcf6bf:
I reverted to a pre-update system image I had taken and tried selective updates.
If I update udev and libudev0 - those being the ONLY updates applied - mdadm breaks as before.
Attempts to update the mdadm.conf file do not work.
I am going to revert to the non-updated configuration, pin udev and its library, and then continue the update process.
Please - a rapid fix, or backing out the update, would be gratefully appreciated.
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: udev 151-12.3
ProcVersionSign
Uname: Linux 2.6.32-24-generic x86_64
Architecture: amd64
Date: Mon Apr 4 16:57:46 2011
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
Lsusb:
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: System manufacturer System Product Name
ProcCmdLine: BOOT_IMAGE=
ProcEnviron:
PATH=(custom, no user)
LANG=en_US.utf8
SHELL=/bin/bash
SourcePackage: udev
dmi.bios.date: 03/03/2007
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0701
dmi.board.
dmi.board.name: A8R32-MVP Deluxe
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 1.xx
dmi.chassis.
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.
dmi.modalias: dmi:bvnAmerican
dmi.product.name: System Product Name
dmi.product.
dmi.sys.vendor: System manufacturer
Note that mdadm, and the RAID 5 array it manages, were working wonderfully up until the time of the referenced upgrade.