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..
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
Responses
With respect to shutting down the multpather service:
Shutting down multipathd would normally cause your dm-N dev-nodes to go away. Given that you're apparently accessing the root filesystem(s) via dm-N dev-node(s), it w/should really negatively impact your ability to stay running if the dm-N dev-nodes were to go away. Thus, it would likely be a Bad Thing™ if the system were to allow you to shut-down multipathd. That the system is preventing you from shutting down multipathd would thus be seen to be a Good Thing™ - and therefore not a critical issue that should negatively impact you.
The major downside of this configuration method is what you've already discovered: your default initial ramdisk may lack the hooks necessary to properly boot off of dm-N dev-nodes. The multipathd service normally starts after the initial ramdisk loads. You need to rebuild your initial ramdisk to include the the requisite multipath drivers so that the required dm-N dev-nodes are available when transitioning from the (non-multipathed) /boot filesystem to the root filesystems.
That said, properly-configured, when you apply patches, the associated automatic-running of mkinitrd should load the multipathd drivers into any newly-created initial ramdisk images. You should be able to do this by ensuring that the requisite module entries are placed into the INITRD_MODULES parameter in the /etc/sysconfig/kernel file.
> anyways if the system KILL multipathd process what could happen someday
> while trying to boot again?, could I get a kernel panic and the system unable
> to boot again? so at the end I shouldnt worry about this message?
It's akin to messages about not being able to unmount certain partitions because they're still busy when the `umount` operation hits. It's annoying to see but not fatal. Yanking critical device-paths out from under the kernel would result in the shutdown part of the reboot processing ending in a non-graceful way. This wouldn't necessarily prevent the system from successfully rebooting, but you'd not want to make a habit of terminating your shutdown in an ungraceful way.
> We have only one / partition and /var. So /boot is multphated as well. Can
> this affect even more the system health?, should /boot in a non multiphated
> device?
Err... "/boot" isn't generally done as anything other than a bare device (no LVM, no dm-multipath, etc.) - especially during stage 1 of the bootstrap process. It's possible you'd be remounting it as multipathed, but it would make little sense to do so.
> and If after updating the system with yum update, it download a newer
> kernel version, I guess I should run mkinitrd with the new kernel version
>image and it should boot. right?
When you do the yum update, if you've set up your system properly (see my prior response on how), the update process will properly remaked the initial ramdisk to include the appropriate multipath hooks. This should obviate the need to manually run mkinitrd.
Pulling the mkinitrd arguments from prior runs of that action is a bit more involved than this forum is optimized for relating. Basically, it comes down to uncompressing and dearchiving the initial ramdisk's components. There's a fairly decent number of Google results for the topic.
That said, tearing apart the previous initrd to figure out how to rebuild it is probably overkill. By default, initrd should rebuild the same way each time initrd is run. You'd have to explicitly tell initrd to build things differently in order to cause it to deviate from its prior behavior. Forcing it to include dm-multipath hooks is done as stated in my prior post.
All,
Multipathing /boot on a system that uses "SAN" boot is common practise.
multipathd not stopping during shutdown before all filesystems are unmounted on a "SAN" is standard behaviour.
In short: Michael Mendoza do not worry.
Kind regards,
Jan Gerrit
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
