Retropie Installation on Ubuntu Server x64 18.04.1

johnodon

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

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

Latest release is published:
https://github.com/MizterB/RetroPie-Setup-Ubuntu/tree/LTS-20.04

I'll take a snapshot of my system today and rebuild from scratch using the new scripts.

John

OK...just ran my first test and submitted my first issue. :)

https://github.com/MizterB/RetroPie-Setup-Ubuntu/issues/7

I'm combing through the logfile now to look for issues.

After the script finished running, I was dropped at a black screen. I had to ALT+F1 to get a prompt and startx manually. I'll keep investigating but this could be the kernel issue referenced earlier.

John

MisterB

I responded to your issue on GitHub.

Not sure when you started your install today, but I made some edits earlier, so it's possible we crossed paths and that is causing your issue. However, I can confirm that I have a working setup built from the mini.iso as of the latest commit - 12794d0.

johnodon

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

I responded to your issue on GitHub.

Not sure when you started your install today, but I made some edits earlier, so it's possible we crossed paths and that is causing your issue. However, I can confirm that I have a working setup built from the mini.iso as of the latest commit - 12794d0.

The issue is only for people who fork your repo. The change to the bootstrap.sh is easy enough...just wondering if there is a way to avoid it programmatically.

John

johnodon

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

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

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

Latest release is published:
https://github.com/MizterB/RetroPie-Setup-Ubuntu/tree/LTS-20.04

I'll take a snapshot of my system today and rebuild from scratch using the new scripts.

John

OK...just ran my first test and submitted my first issue. :)

https://github.com/MizterB/RetroPie-Setup-Ubuntu/issues/7

I'm combing through the logfile now to look for issues.

After the script finished running, I was dropped at a black screen. I had to ALT+F1 to get a prompt and startx manually. I'll keep investigating but this could be the kernel issue referenced earlier.

John

FYI...logfile is nice and clean. Also, upgrading kernel to 5.8.10 fixes my issue with X not starting.

MisterB

FYI - I have promoted all of the 20.04 code to the master branch, and have archived 18.04 to its own branch.

johnodon

@etheling @MisterB @movisman @ObiEric

I think I may have found another fix for the issue of the screen going black after the Plymouth theme (Pacman) and eventually dropping to a prompt. This one doesn't require mucking with kernel updates and is VERY simple...

All I did was add 'exec' before the 'startx' command in the .bash_profile file:

if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]]; then
    exec startx -- >/dev/null 2>&1
fi

This works for me on a vanilla install of Ubuntu 20.04 mini + MisterB's installer script. The only ill effect I have seen so far is that it take 15 - 20 seconds for ES to finally load once past the Pacman theme. I'll continue to investigate to see what is causing the delay.

John

johnodon

OK...figured out what is causing the boot process to take longer than expected.

It is the Plymouth theme.

If I remove 'splash' from /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="quiet vt.global_cursor_default=0"

boot time takes about 14 seconds from the last BIOS post message I see.

If I leave 'splash' in...

GRUB_CMDLINE_LINUX_DEFAULT="quiet vt.global_cursor_default=0"

...my boot time goes up to 30 seconds...even though the Pacman theme is gone in like 3 seconds. I think he eats about 10 dots before disappearing.

I can certainly do without the plymouth theme but when I disable it, I am now seeing 2 boot errors that I would need to figure out how to handle.

One is the typical 'clean' message on /dev/sda5 (like below):

dev/sda1: clean, 552599/6111232 files, 7119295/24414464 blocks

The other is a message I am not familiar with:

pnp 00:01 can’t evaluate _crs 12311

Any ideas?

John

MisterB

Take a look at the suggestions here:

https://askubuntu.com/questions/772874/how-to-turn-off-the-filesystem-check-message-which-occures-while-booting

I'm wondering if a line like this might suppress both messages:
GRUB_CMDLINE_LINUX_DEFAULT="quiet loglevel=3 fsck.mode=skip splash vt.global_cursor_default=0"

johnodon

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

Take a look at the suggestions here:

https://askubuntu.com/questions/772874/how-to-turn-off-the-filesystem-check-message-which-occures-while-booting

I'm wondering if a line like this might suppress both messages:
GRUB_CMDLINE_LINUX_DEFAULT="quiet loglevel=3 fsck.mode=skip splash vt.global_cursor_default=0"

Thanks. I'll give that a try in a few mins.

MisterB

Bad copy/paste above...of course, remove the splash in the above line for your use case.

johnodon

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

Bad copy/paste above...of course, remove the splash in the above line for your use case.

I saw that. :)

So, this works well. The only thing I had to do was set loglevel=0. If I set it to 3, I would see something flash quickly (in red)...to fast to read. Setting to 0 I see nothing.

Thanks for pointing me in the right direction!

John

MisterB

How about loglevel 2 (CRITICAL)? Curious if there is a minimum threshold that hides everything for 'normal' use, but can still show a truly critical system error if it occurs.

johnodon

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

How about loglevel 2 (CRITICAL)? Curious if there is a minimum threshold that hides everything for 'normal' use, but can still show a truly critical system error if it occurs.

I'm reimaging right now. Give me 30 mins and I'll report back.

johnodon

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

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

How about loglevel 2 (CRITICAL)? Curious if there is a minimum threshold that hides everything for 'normal' use, but can still show a truly critical system error if it occurs.

I'm reimaging right now. Give me 30 mins and I'll report back.

OK...so it looks like loglevel 2 is hiding those messages. However, on the first reboot after running the script, I am seeing a single red 'FAILED' message. It happens so fast I can't read the rest and it doesn't happen on subsequent reboots. I tried looking in dmesg but didn't see anything I didn't already mention.

Where is the best place to look for that error after the first reboot? I'd like to see what it is about and if it is script related.

John

johnodon

Quick update...

I am seeing the same longer boot time behavior on my Lenovo T430 as I did on my other system. If I remove splash from the the grub line, boot time is shortened by about 20 seconds.

John

johnodon

@MisterB I think it may be close to time to start a new thread that is dedicated to your install scripts and just reference this one for posterity.

What do you think?

John

etheling

@MisterB Just wanted to chime in to say that I modified my pre/post scripts for Intel NUC to run from under optional_scripts/ and it worked out beautifully - in one swift run the pre-install part drops in new kernel, wpa_supplicant, and connects NUC to wifi and then proceeds with the rest of the install.

Couple of observations:

I had edited my pre-install script under optional_scripts/pre_install, so I had preinstall.sh~ there as I executed main install script. Which then ran the preinstall script, and broken preinstall.sh~. Maybe filter out files with ~ at the end, or only run files with .sh extension?
Would it make sense to run inxi -F at the end of the script just before reboot (and maybe some other utilities) to 'document' into install log hw etc. configuration?
I think unrelated to your script, but I had to recompile xpad afterwards to fix button mappings at the controller. E.g. select, start and others were not reporting at correct values when looking /dev/input/js* with jstest. I'll look into this maybe next weekend to see if it reproduces.
Unrelated to your script, but lr-puae doesn't install currently. It compiles ok, but there is no README file under /home/pi/RetroPie-Setup/tmp/build/lr-puae/ which breaks the install ('touch /home/pi/RetroPie-Setup/tmp/build/lr-puae/README' works around it - see here).

As for my post install scripts, I split my post install scripts to two parts, one that is specific to NUC and another that (I think, didn't test yet) will also work on Pi that sets up themes, overlays, emulator specific retroarch congifs, core overrides, sets up retroachievements.org account, etc.

Thanks again for all the work on the script. Very much appreciated!

johnodon

WIP... :)

I'm currently working out the code to separate pre-install and post-install package options.

(Radio buttons...only one selection allowed)

(Checklist...multiple selections allowed)

etheling

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

... but I had to recompile xpad afterwards to fix button mappings at the controller. E.g. select, start and others were not reporting at correct values when looking /dev/input/js* with jstest. I'll look into this maybe next weekend to see if it reproduces.

This reliably reproduced in different ways when my install order was: 1) pre-instal kernel , wpa_supplicant, start net, 2) main script, 3) post installs. I don't know what exactly is/was causing the problems but what seems to make things work smooth is to install custom kernel last (or after xpad has been installed, I suspect). So having modified my install order to 1) pre-instal wpa_supplicant & start net, 2) main script, 3) post installs (including install new kernel) installs/confiugres everything in a single smooth run. :)

etheling

@MisterB One thing I realized is that in function set_resolution_grub the script sets GRUB_GFXMODE=1920x1080x32,auto. It appears to me though that this (even when augmented with GRUB_GFXPAYLOAD_LINUX=keep) does not make kernel actually keep resolution that grub changes to (as per GRUB_GFXMODE), and at least with my NUC, kernel always switches back to 4k as it boots up.

I tried vga=ask, and vga=... kernel parameters as suggested by some not so recent docs, but alas, I think these are for some legacy use cases.

What worked for me though was video= kernel parameter. It's documentation leaves something to be desired, but ArchLinux had some useful documentation. Long story short: in my case with 8th Gen NUC, the kernel boot option for 5.8.x series kernel is just video=1920x1080which puts fb/console to that resolution during boot/before X is tarted (and especially after I exit X).

I think it might be useful to include video= to the script, but then again, I am not sure how well this works across different display graphics chipsets/hw and how portable that syntax is. Just wanted to mention this so it get's 'documented' here in case someone else wonders about this.