Well that would clean the old stuff, indeed, but you shouldn't have to do
all this stuff by yourself, too bad you can't find the logs. Btw, removing
the lvs and grub entries can be done using `imgbase base --remove
<base-name>.0`
On Thu, Aug 30, 2018 at 7:33 PM, Matt Simonsen <matt(a)khoza.com> wrote:
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> 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> 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> 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
>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>> Privacy Statement:
https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
https://www.ovirt.org/communit
>>> y/about/community-guidelines/
>>> List Archives:
https://lists.ovirt.org/archiv
>>> es/list/users(a)ovirt.org/message/G6P7CHKTBD7ESE33MIXEDKV44QXITDJP/
>>>
>>>
>>
>>
>
>