Please do not post a support request without first reading and following the advice in

  • Thanks for the heads-up on the video drivers - I just re-enabled those. Not sure about the blank screen issue, though. I did have something similar a few weeks ago, and after splitting out the and adding a shebang to the top of that file, everything started working reliably. If you could continue to troubleshoot your install and let me know what you find, I'm happy to make to changes. Maybe backgrounding clutter, or introducing a brief sleep before start ES would help?

  • @MisterB

    Hi there,

    I followed the steps posted by @johnodon a while back now, and added a few findings of my own to this thread - glad to see you have incorporated all of this into a script!

    I'm going to change machines because I have another machine available now which will run Dolphin at full speed, so i'm going to reinstall and move my RetroPie instance over to that. This time round, to save time i'm going to try your script and see how it goes.

    Just wanted to say thanks for going to the trouble of making it - if it works as planned it will save me a load of time during the initial installation phase for the reinstall. If I come across anything strange or that needs adding, I will let you know if you are still in a position to make changes to the script. I'll be installing on Ubuntu Server 18.04.3.

    Hopefully others will make use of your script.

    Thanks again!

  • Thank you for the feedback - much appreciated! This script was still working for me a couple of months ago - would love to hear if you are also successful with it. Happy to add tweaks as required.

  • @MisterB

    No worries!

    I had a quick play with it last night but ran into some issues - not with your script though I don't think.

    My replacement machine has a GeForce 1030 in it, so after running the script I decided to put the proprietary drivers on there, but ran into a blank screen after rebooting. I could swap to a different TTY and login to the console, but it no longer would come up with ES.

    Anyway, I reinstalled and put the driver on first, so later i'll try the script again and see what happens.

    I noticed that it does a basic install - which i'm sure is fine for most, but for me on x86 I only install the emulators I need or the ones which work best on x86. I saw in a previous commit that you reverted to a basic install rather than the core packages, any idea what the issue was?

    For now, i'll just take the RetroPie install step out of the script and install it at the end.

    One comment about the vulkan drivers on your script - I see in the code that vulkan installs AFTER RetroPie is installed. I think these are best installed before, and I also think you may need to have libvulkan-dev installed too in addition to mesa-vulkan-drivers. The reason is, when RetroArch is installed, I think it detects vulkan support if available and compiles accordingly, so you want the drivers on there first. I believe libvulkan-dev needs to be present too, as per this thread I created a couple of years back:

    Not 100% sure if this stuff is still valid, but on my previous machine this is how I had to do things in order to be able to select Vulkan in RetroArch.

    When i've had time to run the script again (and hopefully not run into display issues this time) i'll let you know if I have any additional feedback!


  • @MisterB

    Actually, partially scrap the above (i think!) - I just checked here:

    And it looks like for x11, libvulkan-dev is listed as a dependency, so I guess this will get installed as part of RetroArch anyway.

    So that probably doesn't need to go onto the script.

    It also looks like vulkan is enabled is you are running x11, so perhaps it doesn't matter if the driver is installed before or not.

    I'll check it out when I next run the script and ensure vulkan works properly as-is with no changes.


  • @MisterB

    Okay! So I have some feedback for you on Ubuntu Server 18.04.4, I found a few minor issues with the script (clean install) but worked out fixes for all (i think). I am very much a beginner with some of this stuff but it was good to learn and challenge myself somewhat! There was also an issue with Nvidia cards when they have the proprietary driver installed (not nouveau), and I pretty much spent all my free time this week diagnosing an issue with X not launching as a result (black screen), which I FINALLY nailed down to being caused by recommended packages not being installed (--no-install-recommends) on the retropie depends function. I think it might be xorg causing the problem there, maybe it needs additional packages to work for Nvidia, but need to check that out further. Taking --no-install-recommends out though fixes the problem either way. If you are using Intel, it works either way, which is possibly why it wasn't picked up.

    Anyway, instead of going into detail on each issue, I did try to document my changes so I could give you a little changelog. What I have done, is make a fork of your repository onto my github page and update it with my changes. If you want to take a look that'd be great, let me know what you think. I also added a few functions, which are optional (commented out by default).

    I'll post my changelog and github link below. Hope you don't mind me having a go at fixing the few issues I came across and adding a few new things. I started to enjoy messing around with your script and trying to work out how to fix things, it's clearly laid out and a good starting point for someone who is learning. Was going to try and just fix a couple of the errors initially...and then got slightly carried away. You might have a better way of fixing some of the things I mentioned below but everything does seem to work and I didn't make any drastic changes.

    If you want further details on any of the issues I did come across, I did quite a bit of testing so should be able to elaborate further on each point.

    I did loosely test this with the mini.iso too - it seems to work, but I did have issues with the splash screen not showing up (just blank), this might be an Nvidia thing though or maybe some other packages need to be installed to make it show. Didn't really test in detail, most of my testing was performed on Ubuntu Server 18.04.

    Link to my cloned github repository:

    This should have the updated script and i’ve updated the readme as well.

    Here is the changelog - might have missed a couple of things but should be reasonably complete:

    Existing Functions:

    function disable_sudo_password

    • tweak logic so it creates a file in the /etc/sudoers.d directory to disable sudo password, rather than editing sudoers directly (more dangerous and can be overwritten by updates)

    function install_retropie_dependencies

    • remove -no-install-recommends as having this causes a blank screen on boot for nvidia cards when using a proprietary driver

    function install_retropie

    • reinstated the core module install method (retroarch, emulationstation, retropiemenu, runcommand, plus samba) - let me know if you knew what the issue was with using this method over the basic install...during all my testing it seemed to work fine going for core modules only?

    function add_retroarch_shaders

    • add line of code to remove the 'pi' centered shaders directory installed by RetroPie-Setup
      recreate the shaders directory afresh
    • add chown command at the end of the function to make sure everything under /opt/retropie/configs is owned by $USER
      function hide_boot_messages
    • improve logic on sed command so instead of relying on GRUB_CMDLINE_LINUX_DEFAULT having the value "quiet" or "" to make the changes needed, now it will replace whatever exists in the quotes with the intended attributes.

    function enable_plymouth_theme

    • remove -no-install-recommends just in case it causes issues - could possibly be restored as it seems to be ok with no-install-recommends set to true. However after my issue with no-install-recommends being enabled on the retropie depends function, I thought it would be safer to remove it.

    function hide_openbox_windows

    • remove $(cat $USER_HOME/.bash_profile) just before EOF, as this causes the 'startx' code to appear twice in .bash_profile (once at the top, and once below the gnome-terminal commands)
      reorder this function so it takes place before enable_autostart_xwindows - this ensures that the gnome-terminal code is run before startx is called
    • changed chown command so it changes ownership to $USER from .config recursively instead of .config/openbox - this resolves an issue where .config/dconf (which gets created when gnome-terminal is first launched) is incorrectly owned by root - this then causes DCONF console errors for the gnome-terminal customisation when .bash_profile is called, resulting in no customisation happening because it cannot write to the file correctly (presumably because it is owned by root). Changing the chown command totally resolves this problem, resulting in fully customised black and green terminal with no bars etc.

    function enable_autostart_xwindows

    • change ~/ on several lines to $USER_HOME/ to match other functions

    function autostart_openbox_apps

    • changed chown command to /opt/retropie/configs recursively instead of just changing ownership on, otherwise some of the directories get owned by root again. opt/retropie/configs and all files/folders beneath should be owned by $USER

    function install_vulkan

    • remove -no-install-recommends just in case it causes issues - could possibly be restored, but haven't tested for issues by leaving no-install-recommends set to true with vulkan. After my issue with recommended packages on the retropie depends function I thought it would be safer to take this out.

    New Functions:
    added optional functions (not enabled by default) for:

    • installing the latest nvidia driver
    • install 'inxi' package and enable updates - can be used for checking hardware and system information
    • disabling screen blanking
    • force HDMI-0 to 1080p after startup (should be configured accordingly to suit output and resolution)
    • changing the GRUB graphics mode to 1920x1080x32 for nicer splash (if supported)
    • removing “error: XDG_RUNTIME_DIR not set in the environment” CLI error when exiting Retroarch from the RetroPie Setup screen within ES
    • final apt update/upgrade and cleanup unneeded packages (autoremove)
    • offer to reboot once last function is completed
    • fix permissions function which catches any potential snags where folders or files under $USER_HOME may get owned by root. note - this might need some improvement/sorting out, it basically chowns the home directory recursively so it is owned by $USER. Which should be ok as I think anything under home shouldn't be owned by anything else. It seems to work...currently it isn't needed after my above changes but I figured it was good to leave it as a fail-safe


    • added logging at top of file so console output is stored as retropie_setup_ubuntu.log when complete
    • add short confirmation after each function is run
    • reordered functions to match the order they execute in
    • reordered the execution of functions to resolve a couple of minor issues
    • add titles to all functions to tidy up a bit, add additional descriptions/info

  • @movisman @MisterB so I ran your script and all but one detail seems to work like a charm.
    When power on it boots up openbox into the login screen, where I need to enter the password before it starts. Once done it auto starts emulationstation.
    How do I make opebox autologin?

  • @hulsie1983 solved it myself. apparently, I had to turn on autologin in the openbox GUI in the settings menu. In Emulstation in the retropie settings menu turned on the boot option and now all is working.

  • @hulsie1983


    You shouldn't have had the login box appear when using either script, however, I was personally using 18.04 as a base. Are you using 20.04? If so, I do remember at the time I did briefly test it with 20.04 (beta) and I did get a login box etc, and I think I had a few other teething issues - so just stuck with 18.04.


  • @movisman thank you :) your install script worked perfectly

  • @movisman are we able to exit emulation station to an Openbox desktop?

    one time emulation station did not load and I was left with this desktop -


    The only reason I ask is that I'm having trouble getting pcsx2 past the first time setup wizard

  • @gareth_iowc

    Hi there,

    This hasn't happened to me on 18.04.4, however of course if you quit ES you will get a black desktop with the menu if you right click. To configure Dolphin standalone I use the terminal and run the GUI to get everything working, but I must admit I haven't ever tried pcsx2 as the machine this runs on isn't powerful enough.

    I noticed @MisterB pulled all my previous enhancements into a new branch called LTS-20.04. So it's quite possible he is working on a new script for 20.04 users which includes some of the additions I put onto my 18.04.4 fork.


  • As @movisman mentioned, I now have an updated script for 20.04 that is available for testing, and it also includes many of his improvements. It's in a new branch found here:

    A list of changes is in the README, and it seems to be working OK in a 20.04 server virtual machine that I am developing against. If others would like to test it out and provide feedback I would appreciate it! Testing of this new version against physical installs of both 20.04 and 18.04 would be helpful. Thanks!

  • By the way, I also had the login screen issue in 20.04. It is fixed in my new branch, which boots the system into the multi-user (command line) runlevel, rather than the graphical one. Booting into multi-user makes it easier to finely-tune the way X Windows & OpenBox start up.

  • Applied this setup to my custom aarch64 build (NVIDIA Jetson Nano) and it works like a charm. The Nano doesn't have the same access to EGL from CLI as most other SBCs, so I was after a lightweight X solution, and this was the perfect solution.

    Many thanks!

  • @MisterB Would you mind sharing what you did to preseed a mini or server install? I have edited your preseed file to my needs but am having issues getting the installer (USB) to use it.

    Scratch that...figured it out. :)



  • @MisterB said in Retropie Installation on Ubuntu Server x64 18.04.1:

    [...] If others would like to test it out and provide feedback I would appreciate it! Testing of this new version against physical installs of both 20.04 and 18.04 would be helpful. Thanks!

    @MisterB I am attempting to get RetroPie running on an older Intel computer (Core 2 Duo E8400, 4GB RAM, 500GB drive, ATI Radeon 7850) but I have an interesting issue after installing from the setup script. I start with a clean install of Ubuntu 20.04 LTS and then use the build script. The build/configuration process takes about 70 minutes from start to finish and after it is done, I reboot the machine, see the Pacman animated screen for a bit, and then get left in a black screen and nothing else (no arrow, no cursor, nada).

    I know that removing all of that is by design but I am stuck on how to debug this. I can successfully SSH into the machine but wanted a bit of advice before I go mucking around in bash profiles, any grub files, etc.

    Also, after some fumbling around on the Ubuntu box, itself, I hit CTRL+ALT+F1 on the Linux box and then (blindly) started up X via startx. I could get a terminal window from there, if that helps describe where I am at.

    Not sure what I should be looking at, though. This does sound like a bit like some of the problems reported here so wanted to definitely chime in with my results and seek your advice. This is a purely physical build and I am fresh installing the OS. I am running the wget, chmod, and script execution exactly as detailed on

    Not sure what to try. Thoughts? Happy to share the log file from the build, if that is helpful. Would -really- appreciate anyone's thoughts on what to try next.

    And thanks to all involved for putting together the script. This really has made the build and installation process painless. It feels like I am 98% of the way there but just a bug here or there is preventing the last bit of it to work.

    Any help would be appreciated!

  • @MisterB said in Retropie Installation on Ubuntu Server x64 18.04.1:

    As @movisman mentioned, I now have an updated script for 20.04 that is available for testing, and it also includes many of his improvements. It's in a new branch found here:

    A list of changes is in the README, and it seems to be working OK in a 20.04 server virtual machine that I am developing against. If others would like to test it out and provide feedback I would appreciate it! Testing of this new version against physical installs of both 20.04 and 18.04 would be helpful. Thanks!

    I believe that this line needs to be updated in your

    chmod +x ./

    Should be....

    sudo chmod +x ./

    If I don't run it as sudo I get an error.


  • @ObiEric I ran into similar looking problem with Intel NUC. On boot it goes from plymouth boot screen to black screen (without mouse) and then in about 30 seconds drops back to shell. And, if I then manually enter 'startx', ES starts normally.

    Did you look into your
    /home/pi/.local/share/xorg/Xorg.0.log (<-- my xorg log in pastebin for failed start)?

    I have no idea what the root cause is but I'll hazard it has something to do with i915 / drm kernel modules being in bad state / not yet properly loaded (see somewhat similar issues here and here and e.g. here). Alas, none of the workarounds and their Ubuntu equivalents appeared to work.

    So I gave up and just upgraded to 5.8.4 Mainline Kernel. works (at least with NUC).

    EDIT: also works with 5.7.18 kernel. 5.8.x had some issues (at least with NUC) which 5.7.18 doesn't appear to have, so I am going with that.

    EDIT #2: if applying this workaround, please check for latest stable kernel releases (I am using 5.7.19 EOL as of 2020-09 for 8th gen NUC) and consider using Ubuntu mainline kernel matching one of the latest stables instead of versions indicated above.

  • @etheling - Good thought. I have not looked at that but I'll check it out (likely this weekend). Thanks for the advice!

Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.