Bug 1108711 - rebuild initramfs after multipath.conf is editted
Summary: rebuild initramfs after multipath.conf is editted
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ovirt-3.6.3
: 3.6.0
Assignee: Nir Soffer
QA Contact: Aharon Canan
URL:
Whiteboard: storage
Depends On: 1076531 1124450
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-12 13:06 UTC by akotov
Modified: 2019-04-28 10:49 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-18 13:21:32 UTC
oVirt Team: Storage
amureini: Triaged+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 898153 None None None Never

Description akotov 2014-06-12 13:06:35 UTC
Description of problem:

Kernel upgrade from 2.6.32-358.el6.x86_64 to 2.6.32-358.37.1.el6.x86_64 fails for RHEL 6.x, if it is already registered in RHEVM 3.x. Same procedure works fine on a freshly installed system, if it was not made part of RHEV deployment.


Version-Release number of selected component (if applicable):


How reproducible:

Always

Steps to Reproduce:
1. have rhel6 host installed with friendly_names "on" in multipath
2. enroll system to rhev-manager
3. try upgrading kernel

Actual results:

last stages of kernel rpm install throws:

 /sbin/new-kernel-pkg --package kernel --install 2.6.32-358.37.1.el6.x86_64
"grubby fatal error: unable to find a suitable template"

Expected results:

kernel updated successfully

Additional info:

We should care and rebuild initramdisk at  least for this scenario, may be always, up to engineering to consider possible backfires of always rebuilding initramdisk

Comment 1 Alon Bar-Lev 2014-06-12 13:14:51 UTC
Hi Nir,

I do not think this is something host-deploy is doing.

Not sure even what "it" is...

Alon

Comment 2 Nir Soffer 2014-06-12 13:37:21 UTC
Allon, how can help with this issue? do you think that multipath configuration is related?

Comment 3 Tal Nisan 2014-06-16 13:06:18 UTC
Nir, where are we on that one?

Comment 4 Nir Soffer 2014-06-16 13:08:46 UTC
I don't see any rellation to storage, don't know why it tagged "storage".

Comment 5 Alon Bar-Lev 2014-06-16 13:13:17 UTC
(In reply to Nir Soffer from comment #4)
> I don't see any rellation to storage, don't know why it tagged "storage".

this is a great response!

from comment#0:
"""
have rhel6 host installed with friendly_names "on" in multipath
"""

please help to determine what happens and why.

Comment 6 Nir Soffer 2014-06-16 13:56:24 UTC
Can you specify the vdsm version reproducing this issue?

Comment 10 Nir Soffer 2014-07-31 13:13:11 UTC
Ben, according to the info in the customer ticket, modifying multipath configuration requires rebuilding of initramfs.

So would you suggest that vdsm will rebuild initramfs each time it changes multipath configuration?

Comment 11 Ben Marzinski 2014-08-06 21:17:50 UTC
(In reply to Nir Soffer from comment #10)
> Ben, according to the info in the customer ticket, modifying multipath
> configuration requires rebuilding of initramfs.
> 
> So would you suggest that vdsm will rebuild initramfs each time it changes
> multipath configuration?

Yes.

There are some changes that don't require you to rebuild the initramfs, but it never hurts to do it, and it's a lot easier than trying to figure out if the specific change requires an initramfs rebuild.

Comment 12 Nir Soffer 2014-11-03 11:48:22 UTC
Related to bug 1124450.

Comment 13 Nir Soffer 2014-11-03 12:01:44 UTC
We cannot rebuild initramfs from vdsm startup. We must wait until multipath configuration is moved to vdsm-tool.

Comment 14 Alon Bar-Lev 2014-11-03 12:04:42 UTC
(In reply to Nir Soffer from comment #13)
> We cannot rebuild initramfs from vdsm startup. We must wait until multipath
> configuration is moved to vdsm-tool.

hmmm.... not sure I understand, are you implying that deploy requires reboot?

Comment 15 Nir Soffer 2014-11-03 12:09:49 UTC
(In reply to Alon Bar-Lev from comment #14)
> (In reply to Nir Soffer from comment #13)
> > We cannot rebuild initramfs from vdsm startup. We must wait until multipath
> > configuration is moved to vdsm-tool.
> 
> hmmm.... not sure I understand, are you implying that deploy requires reboot?

No, but when we change multipath.conf, we must recreate initramfs (see comment 11), and it does not make sense that we do this behind the administrator back during vdsm startup.

bug 1076531 will hopefully be resolved soon by http://gerrit.ovirt.org/30909

Comment 16 Alon Bar-Lev 2014-11-03 12:12:55 UTC
(In reply to Nir Soffer from comment #15)
> (In reply to Alon Bar-Lev from comment #14)
> > (In reply to Nir Soffer from comment #13)
> > > We cannot rebuild initramfs from vdsm startup. We must wait until multipath
> > > configuration is moved to vdsm-tool.
> > 
> > hmmm.... not sure I understand, are you implying that deploy requires reboot?
> 
> No, but when we change multipath.conf, we must recreate initramfs (see
> comment 11), and it does not make sense that we do this behind the
> administrator back during vdsm startup.

It is insane to depend on pre-rootfs operations, initramfs should only be used to be able to execute pid 1 from rootfs.

Comment 17 Nir Soffer 2014-11-03 12:25:42 UTC
(In reply to Alon Bar-Lev from comment #16)
Your rootfs may be on a multipath device which you boot from. To successfully boot from the device, you need multipath.conf.

It may be insane but thats what users do (see bug 1124450).

Comment 18 Nir Soffer 2014-11-03 12:27:11 UTC
This is actually depends on bug 1124450, since the current multipath.conf we create will not let you boot on rhel 6.

Comment 19 Allon Mureinik 2014-11-17 16:35:26 UTC
This bug depends on BZ 1076531, which won't be resolved before 3.6.0.

Comment 20 Allon Mureinik 2015-01-26 08:42:11 UTC
(In reply to Allon Mureinik from comment #19)
> This bug depends on BZ 1076531, which won't be resolved before 3.6.0.
This is MODIFIED, meaning we can start working on THIS bug upstream.

Comment 21 Tal Nisan 2015-02-03 13:39:38 UTC
Oved, this seems like more of an infra/integration issue since we have to rebuild initramfs after modifying multipath.conf and thus not related directly to storage
Can someone from infra take it or you think it's more of an integration issue?

Comment 22 Yaniv Bronhaim 2015-02-05 08:18:55 UTC
same here.. rebuilding initramfs, im not aware of what it means regarding changing multipath configurations.. sorry. (you can tell me more after you figure that out and I might be able to add it myself) Currently Yeela managed the movement of multipath configuration part to the centralized place under vdsm-tool. but setting multipath configuration is storage related and I prefer that you'll take over it instead of us making mistakes without knowing the consequences. If something need to be modified in lib/vdsm/tool/configurators/multipath.py I think you should do it.. don't you? please explore what it means to rebuild the initramfs, how and why it should be done, and we'll consider how we do it.. I never bumped in such issue (danken, maybe you did?)

Comment 23 Saggi Mizrahi 2015-02-16 13:57:39 UTC
This bug only effects people that manually added multipath to their initramfs and not for all people (unless multipath is now in initramfs by default).
I don't know if there is a way to detect that multipath was added to initramfs and in any case, rebuilding it seems a bit problematic to me.

It's another issues that crops up because we allow people to do what they want with their system while in the same time configuring the system ourselves.

Supporting *any* initramfs is going to be really problematic so I don't suggest we start going down that road. If there is a way to detect that an initramfs should be rebuilt we could have vdsm-tool warn about it.

In any case, the real fix is that storage stop depending on `user_friendly_names no`.

Comment 24 Dan Kenigsberg 2015-02-18 13:21:32 UTC
People need to tweak their initramfs's multipath.conf in order to boot from a multipath-served disk.

However, these people change their multipath.conf manually. I don't see a benefit in automatically copying ovirt's multipath.conf into initramfs - it would override their changes. Whomever edits his multipath.conf and intend to use his host for ovirt, would need to comply with ovirt's requirement.


Note You need to log in before you can comment on or make changes to this bug.