Operating System - Linux
1753774 Members
6767 Online
108799 Solutions
New Discussion

Re: root is on a multipathed device multipathd can not be stopped

 
techux
Occasional Advisor

root is on a multipathed device multipathd can not be stopped

Hi guys.

I am installing RH 5.8 booting from a HP SAS storage with multipath.. the server is a HP proliant..

there is a / partition, swap and /var all in the storage..

the issue is when I restart the server while the system stop all service one says ERROR... and the error is this:

root is on a multipathed device multipathd can not be stopped

I can restart the server and it will boot.. but I am not sure if this is a critical issue that could affect me in the future.. the server will be in production and the only reason for restart or shutdown will be a for a very critical failure...

I am trying to find information about this but I allways end in any page showing the script which stop this service.. not sure if it is a bug or should I replace the original script with the one I found..

the other thing is if I update the system with yum update it wont boot with the new kernel.. I think I should rebuild the kernel image with mkinitrd.

If I run the command multipath -v0 or 1 2 it doesnt show anything..

any idea?

thanks in advance

1 REPLY 1
Matti_Kurkela
Honored Contributor

Re: root is on a multipathed device multipathd can not be stopped

Not critical at all. The message is produced by a check in the /etc/init.d/multipathd script, which prevents stopping multipathd with e.g. "service multipathd stop" when the root filesystem is on a multipathed device.

While multipathd can safely be restarted while multipathed devices are in use, leaving it stopped for an extended period of time is not a good idea.

 

The writer of the /etc/init.d/multipathd script apparently has not included a special check to silence the message when the system is halting or rebooting.

 

When the root filesystem is on a multipathed device, having the multipathd running as far in to the halt/reboot procedure as possible (ideally all the way to the point where the kernel halts/reboots the system) is actually a good thing.

 
> the other thing is if I update the system with yum update it wont boot with the new kernel..

> I think I should rebuild the kernel image with mkinitrd.

 

The installation procedure for the new kernel package already includes a mkinitrd step, so doing it manually won't do anything unless you fix the root cause first.

 

You say "it won't boot". What exactly happens? Where does the boot process stop? Does it hang? Does it fall to single-user mode? Has it successfully mounted the root filesystem at that point? Has the kernel detected the multipathed SAS storage? If you needed a special driver RPM to make the multipathed SAS storage accessible with the old kernel, you might need to update that RPM too. If the updated RPM does not contain a pre-built driver for the new errata kernel, you might have to rebuild the module before rebuilding the initrd for the new kernel and booting with it. This can be a bit tricky: check the installation instructions of the driver RPM.

 

Before rebuilding the initrd, you should make sure the /etc/modprobe.conf includes the appropriate SAS adapter driver module:

  • The first scsi_hostadapter alias should be simply "alias scsi_hostadapter <module name>" and the <module name> should be the name of the driver module needed to access your root filesystem.
  • The subsequent scsi_hostadapter aliases (if required) should be of the form "alias scsi_hostadapter<N> <module name>" where <N> is a number (starting with 1), and <module name> is the name of the required storage adapter driver module.

If the above tips won't help you, please identify the exact server model and the model of any multipathed add-on SAS controller card(s) used on your system.

 

> If I run the command multipath -v0 or 1 2 it doesnt show anything..

 

If "multipath -v2" does not display anything, it simply means the command thinks there is nothing for it to do: either there are no multipathed devices detected (= perhaps missing a SAS driver update?) or udev has already run it automatically. Run "multipath -ll" to see the current state of the multipath subsystem.

MK