I'm not sure I have logs from any instances that failed.
However having upgraded about 10 nodes, the trick for success seems to be:
- Manually cleaning grub.conf with any past node kernels (ie: when on
4.2.3, I remove 4.2.2)
- Manually removing any past kernel directories from /boot
- Removing any old LVs (the .0 and .0+1)
- yum update & reboot
I'm not sure how our systems got to require this, we've done 5-6
upgrades starting with 4.1, and never had to do this before.
If I continue to have problems from 4.2.5 to 4.2.6, I will send as clear
of a bug report with logs as possible.
Thank you for your help,
Matt
On 08/27/2018 12:37 AM, Yuval Turgeman wrote:
Hi Matt,
I just went over the log you sent, couldn't find anything else other
than the semanage failure which you say seems to be ok. Do you have
any other logs (perhaps from other machines) that we can look at it ?
Thanks,
Yuval.
On Tue, Aug 21, 2018 at 10:11 PM, Matt Simonsen <matt(a)khoza.com
<mailto:matt@khoza.com>> wrote:
I ran this on a host that has the same exact failing upgrade. It
returned with no output.
I'm expecting if I manually remove the /boot kernel, the grub
lines from any other installs, and the other LV layers that the
upgrade will work but with myself and others experiencing this I'm
happy to assist in finding the cause.
Is there anything else I can do to assist?
Thanks,
Matt
On 08/21/2018 12:38 AM, Yuval Turgeman wrote:
> Hi again Matt,
>
> I was wondering what `semanage permissive -a setfiles_t` looks
> like on the host that failed to upgrade because I don't see the
> exact error in the log.
>
> Thanks,
> Yuval.
>
>
>
> On Tue, Aug 21, 2018 at 12:04 AM, Matt Simonsen <matt(a)khoza.com
> <mailto:matt@khoza.com>> wrote:
>
> Hello,
>
> I replied to a different email in this thread, noting I
> believe I may have a workaround to this issue.
>
> I did run this on a server that has not yet been upgraded,
> which previously has failed at being updated, and the command
> returned "0" with no output.
>
> [ ~]# semanage permissive -a setfiles_t
> [ ~]# echo $?
> 0
>
> Please let me know if there is anything else I can do to assist,
>
> Matt
>
>
>
>
>
> On 08/20/2018 08:19 AM, Yuval Turgeman wrote:
>> Hi Matt,
>>
>> Can you attach the output from the following line
>>
>> # semanage permissive -a setfiles_t
>>
>> Thanks,
>> Yuval.
>>
>>
>> On Fri, Aug 17, 2018 at 2:26 AM, Matt Simonsen
>> <matt(a)khoza.com <mailto:matt@khoza.com>> wrote:
>>
>> Hello all,
>>
>> I've emailed about similar trouble with an oVirt Node
>> upgrade using the ISO install. I've attached the
>> /tmp/imgbased.log file in hopes it will help give a clue
>> as to why the trouble.
>>
>> Since these use NFS storage I can rebuild, but would
>> like to know, ideally, what caused the upgrade to break.
>>
>> Truthfully following the install, I don't think I have
>> done *that* much to these systems, so I'm not sure what
>> would have caused the problem.
>>
>> I have done several successful upgrades in the past and
>> most of my standalone systems have been working great.
>>
>> I've been really happy with oVirt, so kudos to the team.
>>
>> Thanks for any help,
>>
>> Matt
>>
>>
>>
>> _______________________________________________
>> Users mailing list -- users(a)ovirt.org
>> <mailto:users@ovirt.org>
>> To unsubscribe send an email to users-leave(a)ovirt.org
>> <mailto:users-leave@ovirt.org>
>> Privacy Statement:
>>
https://www.ovirt.org/site/privacy-policy/
>> <
https://www.ovirt.org/site/privacy-policy/>
>> oVirt Code of Conduct:
>>
https://www.ovirt.org/community/about/community-guidelines/
>> <
https://www.ovirt.org/community/about/community-guidelines/>
>> List Archives:
>>
https://lists.ovirt.org/archives/list/users@ovirt.org/message/G6P7CHKTBD7...
>>
<
https://lists.ovirt.org/archives/list/users@ovirt.org/message/G6P7CHKTBD7...
>>
>>
>
>