> What do you mean by that? Usually (I am not a native English speaker), > "red herring" means, for me, "something that made me look at the error > not in the place where it actually occurred". In this case: Yep! The installer would die out after failing at the SSO step. In the log for this failure it fails with the linked error "You must specify either url or hostname" like you see in that bug report. Nowhere was I was able to deduce it was a failing SSH remote command. I just had happened to decide to look at the other log and saw it The funny thing is, it was right in front of my face the whole time (stty) but it never dawned on me until I decided to try running a command myself like you see with uptime below > The error message does mention 'stty', and I guess this is > more-or-less the best the engine could have done, other than trying to > analyze your .bashrc. {...} > A common idiom for such cases is to check PS1 - bash should set it > only for interactive shells. E.g.: > > if [ "$PS1" ]; then > stty erase ^? > fi > > But you might better fix your terminal emulator instead. {...} > :-( > (Used to be more common 20-30 years ago, when people actually had many > more different physical terminals, terminal emulators, and unix-like > OSes. Sadly our industry failed to fix this, requiring such > workarounds, so far. See also, likely way-out-of-date: > http://www.tldp.org/HOWTO/BackspaceDelete/ ) Yup, going forward I will be putting it like that by checking for PS1. This was just such an edge case that it had completely slipped my mind that it would be the problem I dont know why or when this started occuring - I want to say around RHEL 7.5 or so, but vim reverted back to this behavior I havent seen in almost 15 years I run Fedora on all my machines but collegues on Win10 also started to see it The only fix is the stty thing > Checking the current 4.3 code, I see that we fail if there is anything > at all on stderr. > Trying to check git log finding out why we do that, I fail to find a > concrete reason - although, if you ask me, it might make sense. > Changing that is easy, but then might make real errors you should > actually notice, go unnoticed. > In 4.4 we do not have this code anymore, and use ansible instead for > host-deploy. Since 4.4 GA is expected soon (a few weeks?), and 4.3 > will be EOLed soon after that, I do not see much point in investing in > this anyway. I agree. I can see the benefit in it being a little more decisive, however, the trade off means the developer has to try to account for every case and this, of course, was a complete edge case so likely would have been missed if parsing individual stderr output However, you can run SSH not try and load .bashrc environment - so I was thinking something more along the lines of that [root@node01 ~]# ssh root@localhost uptime root@localhost's password: stty: standard input: Inappropriate ioctl for device 07:50:39 up 1 day, 8:05, 2 users, load average: 0.08, 0.07, 0.06 [root@node01 ~]# ssh -t root@localhost uptime root@localhost's password: 07:51:47 up 1 day, 8:07, 3 users, load average: 0.06, 0.07, 0.06 Connection to localhost closed. > Well, I wouldn't say "110%", but the fact that we try to do things > automatically, on remote machines, using tools that were mainly > intended for manual/interactive use, does mean that we are limited. I guess 110 is a bit of a biased over-exaggeration :-) The only reason I say that is because I love ovirt a lot but every experience I have had with getting it installed as always ended with a different failure each time where there isnt an obvious reason as to why there was a problem and it deters me from installations and only having to do it if I have to The reason I have found, specifically now with this with such a minor change in to bashrc, is that in enterprise environment we have a standard base configuration that we work off - this involves changing SSH parameters, bashrc environment changes, security changes w/ sysctl and others Every time I have had a problem it is apparent now it is because of any of those changes. My suggestion was more or less to have it called out somewhere obvious that oVirt installer/ansible generally want a completely fresh install and that making any changes to the system prior could have negative impact. Example here: a simple convenience change to .bashrc that we have done all the time led to a 2 day time sink Going forward, my standard operating for install is going to be install immediately after bare ISO install from minimal ISO and bypass any bootstrapping changes we do to our systems. Then, once up, I will apply our changes as I have never had issues with ovirt after its up - its the install that is always a very rigid time consuming problem for me