Bogus dependency on mdadm

Bug #98929 reported by Tore Anderson
6
Affects Status Importance Assigned to Milestone
lvm-common (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: lvm-common

root@echo:~# LANG=C aptitude install lvm2
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done
The following NEW packages will be automatically installed:
  lvm-common mdadm

LVM has no dependency on mdadm, as it can easily be used directly on other, non-md, devices. I do it all the time, no problems at all. This dependency should be demoted to a suggests or recommends, especially because mdadm, when installed on a machine not using md devices, by default makes noise during boot and when initrd images are made, and also starts a useless monitoring daemon.

Tore

Related branches

Revision history for this message
Jan Schnackenberg (yehaa) wrote :

So this is the reason for mdadm being installed?

I kept wondering why I have to have a raid-manager when I don't have or plan on having a raid in my system. :/

What is the reason for this dependency? Why does every user, with or without raid-systems, get this? These

W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
W: mdadm: no arrays defined in configuration file.
W: mdadm: falling back to emergency procedure in initramfs.

messages are getting kind of annoying. Especially on systemupgrades.

Changed in lvm-common:
status: Unconfirmed → In Progress
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Correct in an upload today, you're right that this dependency isn't needed since it was only for an initramfs ordering issue which has long-since been removed.

Changed in lvm-common:
status: In Progress → Fix Released
Revision history for this message
Huygens (huygens-25) wrote :

As since yesterday's update I cannot boot my system properly (seemed to be a mdadm issue). I have removed mdadm package (I'm also using directly lvm on non-md devices).
However, this seems to have wipeout my /boot! The grub directory is not there anymore :-(
I'm trying to recover my system before I reboot... But I would suggest to people not to remove the mdadm package.

PS: I also took the opportunity of removing mdadm to remove previous linux kernel (2.6.20-12), perhaps this operation is the faulty one... But I have done removable of previous kernel release before that without a glitch. So I suspect mdadm being responsible for this, and I just want to warn any one trying to do so. Back-up your /boot ;-)

Revision history for this message
Huygens (huygens-25) wrote :

I have to update my previous statement. My /boot was not wiped-out, it was not mounted !?! That was explaining why it was empty.
However, I am not explaining myself why since yesterday updates in mdadm and lvm-common, I have so many troubles to boot.
Just to make things clear: I have /boot (ext3) directly on a dedicated partition. Then on another partition I have created a LVM physical volume which contains one volume group which is made of two logical volume one for / and one for /home.

After, yesterday's update, when booting the system it displays after a while the text mode screen and does nothing more (last messages are usually about mdadm of lvm). If I press Ctrl+Alt+Del, some things get killed and the boot process continues. I have my X login screen. However, /home and /boot are not mounted. Only / is mounted.

I'm logging in using the text mode console, mount the /home and /boot. Then, switch back to the graphical login and I'm then able to use my system as usual!
I do not know what is wrong for the moment... trying to find out...

Revision history for this message
Huygens (huygens-25) wrote :

I saw an update of evms today. I have upgrade and reboot my computer to check if it could solve the problem. It did solve it.
Now my system is working again.

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

Other bug subscribers

Remote bug watches

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