Retropie Installation on Ubuntu Server x64 18.04.1

[Clyde]

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

@Clyde you sure sent me down the rabbit hole here! :)

It seems so, my pleasure. What a hell of an elaborate report! 🧐

So finding working kernel may be the path of least resistance here. Or spending ~1s longer booting when using gzip compression.

Decisions, decisions … 😉

As it turns out, quiet is actually a shorthand for loglevel=4 (KERN_WARNING).

Even after more than 13 years of using Linux as my main OS on many machines, I didn't know that, thanks!

Raspberry OS switches to loglevel=3 after boot (e.g. lower than quiet).

Or quieter than quiet. 😎

So it looks like most documentation online is plain wrong or at least misleading

As it is, sadly, for many documentations ans how-tos on the net, which are either outdated and/or circulate wild combinations from other sources. After all, technical information tends to not aging well and has to be maintained, which requires ongoing time, effort, and dedication.

Based on this, a couple of recommendations:

Which may be better placed in a new thread, preferably in https://retropie.org.uk/forum/category/10/ideas-and-development, or even as issues for the corresponding files on Github?

Fun times.

Indeed. Thanks for all the effort, as OCD-driven it may have been. 🤓

[etheling]

@Clyde Thanks! Although it looks like I jumped the gun a bit (see Edit #2 / strikethroughs in previous post). E.g. I just realized that I still got console message(s) during boot after removing quiet and adding loglevel=0:

Begin: Loading essential drivers ... done
...

Which comes from here:

pi@retropie ~ $ grep -ri 'essential drivers' /usr
/usr/share/initramfs-tools/init:[ "$quiet" != "y" ] && log_begin_msg "Loading essential drivers"

So the 'correct' way appears to be after all to use quiet followed by loglevel= for a desired loglevel to override loglevel=4 set by quiet. I should have just read the Archlinux documentation for silent boot right a way! ;-)

Which may be better placed in a new thread, preferably in https://retropie.org.uk/forum/category/10/ideas-and-development, or even as issues for the corresponding files on Github?

I'll start a new thread later. I think this is not as clear cut as I initially thought it was, so I think some discussion might be useful before creating an issue/PR.

[MisterB]

Lots of great discussion here, so I figured I'd check in. Just wanted to acknowledge that I am working on script updates now, and hope to have something published in the next few days. In addition to incorporating some of the great ideas above into the 'core' install script, I also plan to allow for pre and post-install script folders, which will allow for further customization. My vision is to include a library of optional add-on script files in the repository, which can then be copied/moved/linked into these pre/post folders and be automatically executed by the master script. Still playing with some implementation options.

[johnodon]

On a side note...

I'll go on record as saying that I have MUCH better results using the mini ISO than I do using server. So much less crap getting in the way!

[MisterB]

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

Some of the feedback from above has been put in the "master" script, while others have been setup in the Optional Script Library. Lots of additional information is in the README.

I may include the unattended upgrade and WiFi scripts into the master script at a later time, but want to test those out further before committing.

In the meantime, hopefully some of you will test out these changes and let me know how it goes for you. Thanks!

[johnodon]

@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

[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