stderr:W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.

Bug #1574691 reported by Anastasia Palkina
64
This bug affects 13 people
Affects Status Importance Assigned to Milestone
Fuel for OpenStack
Won't Fix
Medium
Georgy Kibardin

Bug Description

ISO #245 9.0

Steps to reproduce:
1. Install ISO
2. Open /var/log/fuel-bootstrap-image-build.log
3. There is error:
stderr:W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
rm -f ./lib/firmware/cxgb4/t4fw.bin
rm -f ./lib/firmware/cxgb4/t5fw.bin

Expected result: there is no error in this log

Revision history for this message
Anastasia Palkina (apalkina) wrote :
Changed in fuel:
assignee: nobody → Fuel Python Team (fuel-python)
status: New → Confirmed
tags: added: area-python team-bugfix
Revision history for this message
Alexander Gordeev (a-gordeev) wrote :

> stderr:W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.

this one is just harmless warning. W means warning.

usually /etc/mdadm/mdadm.conf contains some kind of cached information about existing MD arrays.

for bootstrap image from which the node will boot up, it's quite impossible to predict which arrays are be presented.

so, /etc/mdadm/mdadm.conf was purposely left without no arrays inside. As fuel uses only one bootstrap image for all nodes.

I doubt if this bug is valid. It doesn't broke something. Just a harmless warning, which is totally expected.

Dmitry Pyzhov (dpyzhov)
Changed in fuel:
assignee: Fuel Python (Deprecated) (fuel-python) → Fuel Sustaining (fuel-sustaining-team)
Changed in fuel:
assignee: Fuel Sustaining (fuel-sustaining-team) → Georgy Kibardin (gkibardin)
Changed in fuel:
status: Confirmed → In Progress
Revision history for this message
Georgy Kibardin (gkibardin) wrote :

It is really a harmless warning, it would took disproportional effort to suppress it.

Changed in fuel:
status: In Progress → Won't Fix
Revision history for this message
ttbek (ttbek) wrote :

Either the warning warns about a real issue that could require user action or it's not useful. To not fix it is just being lazy and this should really remain open rather than "Won't Fix." It's even showing up when running apt-get on a fresh install of Ubuntu server so in order for you to be a little lazy you're going to waste the time of tons of people searching for potential problems with their system? A harmless warning wouldn't be wasting anyone's time. Maybe you consider it a separate issue that it shows up when running apt-get upgrade... but it's coming from the same source, no? Unlike the other fellow above, this warning was not totally expected for me, having never seen it in years of administering Linux systems, maybe because I haven't been using Raid or anything, but still, it is definitely not something I expect to see when doing a typical apt-get upgrade.

Revision history for this message
Georgy Kibardin (gkibardin) wrote :

How do you suggest to fix the issue? As Alexander mentioned, it is impossible to know in advance what hardware boots the bootstrap image. I believe the right place to fix the issue is mdadm code.

Revision history for this message
Mikko Rantalainen (mira) wrote :

Perhaps /etc/mdadm/mdadm.conf should contain

AUTO +all

as the last line by default? If I have understood correctly, that is the default behavior without this line.

Revision history for this message
Paul Pace (myfirstnameispaul) wrote :

I added AUTO +all to /etc/mdadm/mdadm.conf and still saw the warning.

Revision history for this message
Demon (demonrx) wrote :

The warning is coming up because there's no RAIDS setup on the hardware. I spoke with tech support for a vps hosting (www.zion.com). The solution is simply remove the mdadm package:

sudo apt purge mdadm

Revision history for this message
Paul Pace (myfirstnameispaul) wrote :

Removing mdadm does not fix the problem.

Please see discussion on my question at Ask Ubuntu:

http://askubuntu.com/q/834903/150172

Uninstalling mdadm requires uninstalling ubuntu-server, which is not a viable solution.

The solution working for me is to add the following line to /etc/mdadm.conf:

ARRAY <ignore> devices=/dev/sda

Revision history for this message
Artemis (alexander-plaza-net) wrote :

If we use the solution Paul mentions above

"The solution working for me is to add the following line to /etc/mdadm.conf:

ARRAY <ignore> devices=/dev/sda
"

Would that cause any issues in the long term?

Additionally just marking it as a benign problem can cause a problem long term. Because if everyone gets used to the idea to ignore it, then when it actually means something, it will be overlooked.

If it would create a lot of problems why not change the warning "If you currently have an Raid Array, you can ignore, otherwise..." ?

Revision history for this message
ravi mano (manokravi) wrote :

This bug affected me severely : It failed to boot up a base image as part of my course assignment.

Steps to reproduce:
-------------------
trying to boot up an old kernel linux 4.4.1
on an Ubuntu guest OS inside VmWare player
built on 4.15 linux kernel version
updated bootloader.

My environment:
---------------

NO RAID !

VMware® Workstation 16 Pro

anonymized_user@ubuntu:~$ uname -as
Linux ubuntu 4.15.0-142-generic #146~16.04.1-Ubuntu SMP Tue Apr 13 09:27:15 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
anonymized_user@ubuntu:~$

anonymized_user@ubuntu:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.7 LTS

Release: 16.04
Codename: xenial
anonymized_user@ubuntu:~$

Hardware Details:

1. Intel X86_64 processor
2. NO RAID absolutely on guest machine or host Windows 11 home version
( its my personal laptop ).
3. default configuration, uncustomized base kernel image

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.