Retropie Installation on Ubuntu Server x64 18.04.1

johnodon

@Clyde said in Retropie Installation on Ubuntu Server x64 18.04.1:

Nice find. 👍 I'm curious, though. Why use Chrome from an external source when there is Chromium only one sudo apt install chromium-browser from the official Ubuntu repositories away? Is there a technical reason or just by habit?

I remember when I was messing with ChromiumOS, widevine wasn't officially supported. I assumed the same was tru for Chromium browser.

External source? Meaning not using 'apt'? The Chrome download is directly from Google.

Clyde

External meaning not from the distribution's own software repositories. On Linux, using the official repo is the preferred way to install software, as it has has several benefits to "the Windows way", i.e. downloading every application from a different website.

Every package from the repo is checked against tampering by its cryptographic signature, and it also will be automatically updated with the rest of the system. Simply put, Linux' repository system is a decades-old super app store for the whole system and its applications.

Since security updates are especially important for web browsers, your prime benefit of using Chromium from the repo would be the auto-updates – if it has the functionality that you need for your project, of course.

Just my two cents triggered by your description, as I see many new Linux users (don't know if you are one) who keep using the installation method they're used to from their former OS. 🧐

edit: two single-word changes for better wording.

johnodon

After all of this, I ended up installing Firefox instead due to screen tearing issues in Chrome. The process is the same except Firefox can be installed via apt and naturally a new launch script needs to be created to start firefox.

FYI...Firefox also displayed the same tearing issues, however there is a fix that worked for me:

https://askubuntu.com/questions/1141291/screen-tearing-ubuntu-18-04

John

Clyde

@johnodon Thanks for the update and for sharing the link. 👍

johnodon

Can someone else run MisterB's script on a test device with server/mini 18.04? I'm not sure what changed but a lot of packages are failing to install (openbox, dialog, xmlstart, etc.). I had to add the universe repo (as per my original instructions above) for things to start working again.

Honestly, I'm not sure how the script ever worked without that repo included but I can't see anything in the history where it was removed. Did a recent update to the 18.04 ISO do something?

Clyde

@johnodon said in Retropie Installation on Ubuntu Server x64 18.04.1:

I'm not sure what changed but a lot of packages are failing to install (openbox, dialog, xmlstart, etc.). I had to add the universe repo (as per my original instructions above) for things to start working again.

All of those packages are in the universe repo since at least Ubuntu 16.04 (see openbox, dialog, and xmlstarlet on https://packages.ubuntu.com/). So, that repo was needed for them as early as April 2016.

I don't know if universe is enabled on Ubuntu (Server) 18.04 by standard. Did you encounter this problem on a new installation or an old one?

johnodon

@Clyde said in Retropie Installation on Ubuntu Server x64 18.04.1:

I don't know if universe is enabled on Ubuntu (Server) 18.04 by standard. Did you encounter this problem on a new installation or an old one?

I'm just fiddling around today as I am almost finished my 4-play cab and know I will have a need to completely reinstall (all new hardware). I swear that I have used his script in the past to install on 18.04 and don't recall having these issues and don't remember enabling Universe prior to running it. The again, I could just be having a senior moment. :)

Universe is enabled by default on 20.04 so no issue there but I am facing some other challenges with that version that I am trying to work through.

John

MisterB

@johnodon Just remember to use the LTS-20.04 branch of my script if you use that version of the OS. If you have issues, please report back. I recent did a test run that appeared to work OK for me.

johnodon

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

@johnodon Just remember to use the LTS-20.04 branch of my script if you use that version of the OS. If you have issues, please report back. I recent did a test run that appeared to work OK for me.

I installed 20.04 on a Lenovo T430 laptop (my sandbox device) and I get a screen like this after the first reboot when the script is finished:

https://imgur.com/a/qdrDJRA

MisterB

Yikes! No idea what is going on there...

etheling

@MisterB Not sure if this is what's causing @johnodon s troubles but I had the install fail few times because unattended upgrades kicked in, got lock for apt and thus made the install script fail in odd ways as apt gets from script started failing.

I added this to the very beginning of the script to disable unattended upgrades:

echo "Disable unattended upgrades for now. Re-enabled at the end of main install script"
systemctl stop unattended-upgrades
systemctl status unattended-upgrades
systemctl disable unattended-upgrades
# dpkg-reconfigure -plow unattended-upgrades 
# dpkg --configure -a 
# cat /etc/apt/apt.conf.d/20auto-upgrades

And then just before reboot:

function enable_unattended_upgrades () {
        echo " "
        echo "+-------------------------------------------------------------------------------"
        echo "| Re-enable unattended upgrades"
        echo "+-------------------------------------------------------------------------------"
        echo " "
        sleep 5
        systemctl start unattended-upgrades
        systemctl status unattended-upgrades
        systemctl enable unattended-upgrades
        ## dpkg-reconfigure -plow unattended-upgrades
        cat /etc/apt/apt.conf.d/20auto-upgrades
        dpkg --configure -a ; # make sure everything is in synch; unnessary..yes?
}

Edit #1: indicative of above problem are lines such as below in 'retropie_setup_ubuntu.log' or on terminal:

Waiiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 220203 (apt-get)... 1

Edit #2: I also ran to another possibly IPv6 name resolution related issue with apt where it randomly failed trying to resolve archive.ubuntu.com resulting as following error (see retropie_setup_ubuntu.log):

....
Get:2 http://ppa.launchpad.net/ubuntu-x-swat/updates/ubuntu focal/main i386 Packages [5,912 B]
Err:3 http://archive.ubuntu.com/ubuntu focal InRelease
  Could not resolve 'archive.ubuntu.com'
Err:4 http://archive.ubuntu.com/ubuntu focal-updates InRelease
....

I'm not sure if I'm addressing the root cause here or not, but forcing apt to stick to IPv4 appears to make this problem go away:

echo "Prevent apt to use IPv6"
## https://unix.stackexchange.com/questions/9940/convince-apt-get-not-to-use-ipv6-method
echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4

johnodon

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

Yikes! No idea what is going on there...

OK...updating the Mainline kernel (I chose 5.8.9) per @etheling 's advice solved the issue: https://retropie.org.uk/forum/post/233967

Basically, X wasn't starting but I still can't explain the craziness on the screen.

johnodon

@etheling said in Retropie Installation on Ubuntu Server x64 18.04.1:

@MisterB Not sure if this is what's causing @johnodon s troubles but I had the install fail few times because unattended upgrades kicked in, got lock for apt and thus made the install script fail in odd ways as apt gets from script started failing.

I added this to the very beginning of the script to disable unattended upgrades:

echo "Disable unattended upgrades for now. Re-enabled at the end of main install script"
systemctl stop unattended-upgrades
systemctl status unattended-upgrades
systemctl disable unattended-upgrades
# dpkg-reconfigure -plow unattended-upgrades 
# dpkg --configure -a 
# cat /etc/apt/apt.conf.d/20auto-upgrades

And then just before reboot:

function enable_unattended_upgrades () {
        echo " "
        echo "+-------------------------------------------------------------------------------"
        echo "| Re-enable unattended upgrades"
        echo "+-------------------------------------------------------------------------------"
        echo " "
        sleep 5
        systemctl start unattended-upgrades
        systemctl status unattended-upgrades
        systemctl enable unattended-upgrades
        ## dpkg-reconfigure -plow unattended-upgrades
        cat /etc/apt/apt.conf.d/20auto-upgrades
        dpkg --configure -a ; # make sure everything is in synch; unnessary..yes?
}

this has fixed my package failure issues! Thanks @etheling . :)

johnodon

@MisterB FYA...

Can someone who has used MisterB's 20.04 script on either mini or server try to install mame (not lr-mame) from the experimental packages. I get the below error and had to reinstall python to get past it.

FYI...I do not have this issue when I use the 'master' branch to install on top of 18.04.

= = = = = = = = = = = = = = = = = = = = =
Building 'mame' : MAME emulator
= = = = = = = = = = = = = = = = = = = = =

Removing additional swap
Adding 5075 MB of additional swap
Setting up swapspace version 1, size = 5 GiB (5321519104 bytes)
no label, UUID=a9d782a2-e629-4f3d-927e-4d78db137903
swapon: /home/pi/RetroPie-Setup/tmp/swap: swapon failed: Invalid argument
GCC 9 detected
makefile:1032: *** Python is not available in path.  Stop.
strip: 'mame64': No such file
Removing additional swap
/home/pi
Could not successfully build mame - MAME emulator (/home/pi/RetroPie-Setup/tmp/build/mame/mame64 not found).

Clyde

@johnodon said in Retropie Installation on Ubuntu Server x64 18.04.1:

makefile:1032: *** Python is not available in path. Stop.

Maybe that's because Ubuntu switched to Python 3 ex factory with 20.04. You could try to change the system's standard alternative for python, see here for instructions.

johnodon

@Clyde said in Retropie Installation on Ubuntu Server x64 18.04.1:

@johnodon said in Retropie Installation on Ubuntu Server x64 18.04.1:

makefile:1032: *** Python is not available in path. Stop.

Maybe that's because Ubuntu switched to Python 3 ex factory with 20.04. You could try to change the system's standard alternative for python, see here for instructions.

Thanks @Clyde.

I guess the question is if this is something that needs to be accounted for in @MisterB's script or in the RP scriptmodule.

Clyde

@johnodon Absolutely. Alas, I don't know anything about scripting or Python. It's just that a friend told me about his problems (with GIMP plugins that still require P2) because of the change in Ubuntu yesterday.

johnodon

I opened an issue on @MisterB's github and he is already engaged. I'm going to perform some more testing.

etheling

@johnodon Great to hear that you got it working. Btw - after installing newer mainline kernel, I am always getting this message/error during boot up:

initramfs unpacking failed: Decoding failed

It appears it's caused by this bug, and I can make the message go away by following proposed temp workaround (tl;dr; change LZ4->GZIP in /etc/initramfs-tools/initramfs.confand run update-initramfs -c).

edit #1: mentioning this as it introduces a visual distraction by 'breaking' the clean Plymouth themed boot up into ES as the error message is shown.

Clyde

@etheling said in Retropie Installation on Ubuntu Server x64 18.04.1:

It appears it's caused by this bug

Reported over a year ago, importance "high", but still unassigned. 😒

edit: However, one of Canonical's staff engineers commented in April:

We currently believe that the decoding error reported in dmesg is actually harmless and has no impact on usability on the system.

Switching from lz4 to gzip compression, simply papers over the warning, without any benefits, and slows down boot.

Kernel should be fixed to correctly parse lz4 compressed initrds, or at least lower the warning, to not be user visible as an error.

So, it may be that that error doesn't cause any actual problems.

Sorry for the research spree, back to topic.