Thread Info
  • Locked Locked
  • Replies 21 replies
  • Subscribers 11 subscribers
  • Views 46085 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Successful UTM install with HDMI, fix for stall at 66% on Hardware Detection

TheMeridian

Bottom line up front:  I was able to get around the installer hanging at 66% on the "Hardware Detection" screen by doing the following:

  1. Press [Alt]+[F2] to bring up the console window.
  2. At the command prompt type cd /usr/lib and press [Enter].
  3. At the next prompt type bootstrap --install and press [Enter].  Apparently, this starts a second instance of the installer that does not get stuck on the "Hardware Detection" screen.

I'll try to keep this concise.  I've been trying to get UTM installed on a mini PC/appliance (Qotom Q310G4, links here and here) for about two weeks.  The only video output is an HDMI port (not even a VGA header on the motherboard - I checked).  I spent an inordinate amount of time dumpster diving for information here and with Google on the hardware detection problem.  Although the specific hardware causing the hang was never really identified (HDMI, HPET, etc.) it seemed that using a VGA output fixed it.  That wasn't an option for me.  I also changed a ton of BIOS settings to no avail.

I tried installing UTM on the SSD in a host PC, re-installed it in the mini PC, and then reconfigured the NICs using cc, but I could never get the reconfigured NIC settings to be persistent through a reboot (not even after using cc with system_factory_reset).

My final attempt before moving on to OPNsense was to try a DisplayLink compatible USB-to-VGA adapter (I discovered DisplayLink drivers are part of some Linux kernels).  Somehow in reasearching that I stumbled over this thread where Erik (toengi) used something simlar to the steps above to get past the hardware detection stall.  I tried it on a lark, and it worked!

Other notes:  I never could get the Q310G4 to boot the installer off a USB thumb drive (tried Rufus, etc.), so I had to use a USB CD/DVD drive with the installer on a DVD.  Also, make sure you're using the .ISO with the ssi prefix instead of the asg prefix for install (DAMHIKT).



This thread was automatically locked due to age.
Parents 
  • Hello,
thanks for the info
I followed your procedure but I have a error "bus error (core dump)" someone would have an idea, please?
  • in reply to Sandrine glehello

    I am in the same boat, i have a brand new SG230 that came with 9.500 preinstalled. I have to stay on 9.4 though because WAF from 9.5 wont work with https on windows server 2003 and we still have ONE.

    Anyways so i tried to re-image the SG230 with ssi-9.414-2.1 and even ssi-9.358-3.1, both times the setup "hangs" on 66% Hardware Detection.

    If i unplug the HDMI Port, Setup reports that no Appliance Hardware is detected.

    If i try running the bootstrap --install command again i get the same "bus error (core dump)" and cant proceed.

     

    Have you managed to solve this somehow ? This cant be faulty hardware, seems more like an HDMI issue to me.

  • in reply to Meth0d

    You definitely want to get a case open with Support.

    What is your current hardware appliance running 9.4? Is it on 9.413?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • in reply to BAlfson

    We have Support Case open, as it turns out SG230 Rev2 only supports 9.500 upward. Our Partner tries to find a solution as we cannot go to 9.5 right now.

    Our "old" UTM220 Cluster is on 9.415-1.

  • in reply to Meth0d

    I would urge you to upgrade that new unit to 9.506 and to restore your 9.415 backup to it - it may do everything you need.  If not, look for a PM from me.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • in reply to BAlfson

    Well if i could use 9.5+ i would not have the problem of re-imaging the rev2 sg230 with 9.4 :)

    But as we learned the hard way, sophos in all its wisdom removed support for old (insecure) cyphers for the WAF in the 9.5 branch. This essentially breaks all HTTPS/SSL WAF applications running on older IIS. For us this was OWA running on our (sill win2k3) Exchange server.

    We had our UTM 220 cluster upgraded to 9.502 (i think) and after a day analysing what the heck was going on and why our OWA / ActiveSync suddenly stopped working came to the conclusion that Sophos just removed thos cyphers with no way for the customer to work around this fact. The proxy not giving any information about it, just closing the connection.

    I have found no indication that sophos is or will ever bring back support for these cyphers, leaving old IIS WAF SSL applications at "just not working with 9.5". So we cannot move to 9.5 until we have moved the Exchange setup to a newer OS (wich wont happen untill mid-next year).

    We and our partner are trying to get our hands on a SG230 rev1 test Appliance from the distributor to be able to run 9.4 for the time beeing.

  • in reply to Meth0d

    It should be possible to add those ciphers at the command line, and then remove them.  I don't know if first-level support knows how to do that, so I would immediately ask for escalation if you do try to go that direction.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • in reply to BAlfson

    Well our partner had a ticket open at sophos support, though i dont know what level that is.

    The answer (sorry in german) was:

    "da Windows Server 2003 mittlerweile Out of Life ist wird dieser von uns nicht mehr supported.

    Gerade im Zuge der Updates auf 9.5xx wurden die unsicheren Ciphers deaktiviert/entfernt.

    Diese werden im Zuge weiterer Updates auch nicht mehr eingespielt, dies würde von unseren DEVs auch geblockt werden, da wir hierdurch ein Security Downgrade nicht nur riskieren, sondern wissentlich in Kauf nehmen würden und für Sie eine Version handeln müssten bei welcher dieser Change Update sicher ist."

    So basically they would not help us re-enable those chipers. 

  • in reply to Meth0d

    Many years ago, I worked in German for IBM Deutschland in Berlin for a year, so I understand - German support did not want to help or they didn't know how.  In fact, I didn't see any difference in the accepted ciphers.

    Looking at 9.413 in a VM and 9.506 in our lab, I see only one line that needs to change in /var/chroot-reverseproxy/usr/apache/conf/reverseproxy.conf

    Replace SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2 with SSLProtocol all -SSLv2 -SSLv3

    You might try just adding +SSLv1 to the line instead of replacing it with the line from 9.413.  If you try either approach and it works, please report back.  

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • in reply to BAlfson

    I think our partner tried that approach, modifying the reverseproxy.conf. But i'm not sure what the exact changes where.

    I will try to test that next week, i dont have exchange servers lying around in our test-setup so i hope ill find some off-hours.

    Thank you for your efford Bob.

Reply
  • in reply to BAlfson

    I think our partner tried that approach, modifying the reverseproxy.conf. But i'm not sure what the exact changes where.

    I will try to test that next week, i dont have exchange servers lying around in our test-setup so i hope ill find some off-hours.

    Thank you for your efford Bob.

Children
No Data
Unfiltered HTML