• Recent
  • Tags
  • Popular
  • Home
  • Docs
  • Register
  • Login
RetroPie forum home
  • Recent
  • Tags
  • Popular
  • Home
  • Docs
  • Register
  • Login

Retropie Installation on Ubuntu Server x64 18.04.1

Scheduled Pinned Locked Moved Projects and Themes
18.04debianubunutux64x86
223 Posts 34 Posters 64.9k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J
    johnodon @MisterB
    last edited by johnodon 17 Sept 2020, 12:23

    @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.

    1 Reply Last reply Reply Quote 0
    • J
      johnodon @etheling
      last edited by 17 Sept 2020, 17:33

      @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 . :)

      E 1 Reply Last reply 18 Sept 2020, 15:26 Reply Quote 1
      • J
        johnodon
        last edited by johnodon 18 Sept 2020, 11:26

        @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).
        C M 2 Replies Last reply 18 Sept 2020, 11:36 Reply Quote 0
        • C
          Clyde @johnodon
          last edited by 18 Sept 2020, 11:36

          @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.

          J 2 Replies Last reply 18 Sept 2020, 11:38 Reply Quote 0
          • J
            johnodon @Clyde
            last edited by 18 Sept 2020, 11:38

            @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.

            C 1 Reply Last reply 18 Sept 2020, 11:49 Reply Quote 0
            • C
              Clyde @johnodon
              last edited by 18 Sept 2020, 11:49

              @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.

              1 Reply Last reply Reply Quote 0
              • J
                johnodon
                last edited by 18 Sept 2020, 12:46

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

                1 Reply Last reply Reply Quote 1
                • E
                  etheling @johnodon
                  last edited by etheling 18 Sept 2020, 15:26

                  @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.

                  C 1 Reply Last reply 18 Sept 2020, 16:28 Reply Quote 0
                  • C
                    Clyde @etheling
                    last edited by Clyde 18 Sept 2020, 16:28

                    @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.

                    E 1 Reply Last reply 18 Sept 2020, 17:55 Reply Quote 0
                    • M
                      mitu Global Moderator @johnodon
                      last edited by 18 Sept 2020, 16:46

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

                      ...
                      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
                      ```
                      

                      The should be fixed in the RetroPie module.

                      J 1 Reply Last reply 18 Sept 2020, 17:34 Reply Quote 1
                      • J
                        johnodon @mitu
                        last edited by johnodon 18 Sept 2020, 17:34

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

                        The should be fixed in the RetroPie module.

                        EDIT: Are you saying it is fixed or it will be fixed? I don't see any commits or PRs that are recent enough.

                        Thanks @mitu . I'll give it another go.

                        John

                        M 1 Reply Last reply 18 Sept 2020, 17:38 Reply Quote 0
                        • M
                          mitu Global Moderator @johnodon
                          last edited by 18 Sept 2020, 17:38

                          @johnodon Uh, I said should, as in we should probably fix this. Thus far, nothing changed.

                          J 1 Reply Last reply 18 Sept 2020, 17:39 Reply Quote 0
                          • J
                            johnodon @mitu
                            last edited by johnodon 18 Sept 2020, 17:39

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

                            @johnodon Uh, I said should, as in we should probably fix this. Thus far, nothing changed.

                            LOL...I just updated my post above and saw your reply just pop up. :)

                            I read your initial reply as "this should be fixed" as in already fixed.

                            1 Reply Last reply Reply Quote 0
                            • J
                              johnodon
                              last edited by 18 Sept 2020, 17:53

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

                              @johnodon Uh, I said should, as in we should probably fix this. Thus far, nothing changed.

                              Issue submitted on GH.

                              J 1 Reply Last reply 19 Sept 2020, 10:38 Reply Quote 0
                              • E
                                etheling @Clyde
                                last edited by etheling 18 Sept 2020, 17:55

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

                                Visual problem with RetroPie is that it 'breaks' the clean Plymouth themed boot up into ES as the error message pops up.

                                C 1 Reply Last reply 18 Sept 2020, 21:42 Reply Quote 0
                                • J
                                  johnodon @Clyde
                                  last edited by 18 Sept 2020, 21:30

                                  @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.

                                  Just reporting back that this worked perfectly.

                                  1 Reply Last reply Reply Quote 1
                                  • C
                                    Clyde @etheling
                                    last edited by 18 Sept 2020, 21:42

                                    @etheling Maybe some of the tips for hiding the boot texts can help? (Ubuntu doesn't have a /boot/cmdline.txt, but most of those options are either kernel parameters for GRUB, or should be applicable in some other config files.)

                                    E 1 Reply Last reply 20 Sept 2020, 05:27 Reply Quote 0
                                    • J
                                      johnodon @johnodon
                                      last edited by 19 Sept 2020, 10:38

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

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

                                      @johnodon Uh, I said should, as in we should probably fix this. Thus far, nothing changed.

                                      Issue submitted on GH.

                                      Looks like @mitu submitted a PR and it was merged. I'll test this today.

                                      https://github.com/RetroPie/RetroPie-Setup/pull/3229

                                      John

                                      C 1 Reply Last reply 19 Sept 2020, 12:12 Reply Quote 0
                                      • C
                                        Clyde @johnodon
                                        last edited by 19 Sept 2020, 12:12

                                        @johnodon @mitu Ahh, that's the synergy which I love about open source communies. Thank both of you!

                                        1 Reply Last reply Reply Quote 0
                                        • E
                                          etheling @Clyde
                                          last edited by etheling 20 Sept 2020, 05:27

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

                                          It appears that when using latest stable mainline kernel 5.8.10 (as of 2020/09) it no longer gives out initramfs unpacking failed: Decoding failed error. So finding working kernel may be the path of least resistance here. Or spending ~1s longer booting when using gzip compression.

                                          That said, based on info in that Ubuntu bug report it looks like 'initramfs unpacking...' error is sent as KERN_CRIT (loglevel=2), so I thought I'll be done with it by simply
                                          dropping kernel loglevel to KERN_EMERG (loglevel=0). And sure enough, it's hidden, but after boot I thought I'll check that the error is still in kernel logs and that it got hidden and that loglevel got properly set:

                                          $ pi@retropie ~ $ dmesg | grep -i 'initramfs unpacking'
                                          [ 0.834312] Initramfs unpacking failed: Decoding failed
                                          pi@retropie ~ $ uname -a
                                          Linux retropie 5.7.19-050719-generic #202008270830 SMP Thu Aug 27 08:35:40 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
                                          pi@retropie ~ $ cat /proc/cmdline
                                          BOOT_IMAGE=/boot/vmlinuz-5.7.19-050719-generic root=UUID=639b8c73-24be-4c14-858b-4e4c017dcc8e ro loglevel=0 splash vt.global_cursor_default=0 vt.handoff=7
                                          $ cat /proc/sys/kernel/printk
                                          4 4 1 7

                                          All as expected, except that kernel is now back to KERN_WARNING (loglevel=4).

                                          It turns out that modern Linux distributions set kernel log level during boot to distro specific defaults. In Ubuntu this is controlled by /etc/sysctl.d/10-console-messages.conf where kernel.printk = 4 4 1 7is set (on Raspberry OS / Raspbian these are /etc/sysctl.d/98-rpi.conf, kernel.printk = 3 4 1 3). In 'old' days, with pre-systemd Linuxes, which is when I looked at this direction last time, when you set loglevel boot parameter, that's what you had when the OS was up. So this was a bit confusing at first.

                                          This also lead me to look into boot parameters. As it turns out, quiet is actually a shorthand for loglevel=4 (KERN_WARNING). Both Ubuntu (source code) and Raspberry Pi documentation state this. Thus quiet and loglevel= should never be used at the same time to boot the kernel since one or the other will override the other. Also note that while Ubuntu defaults to 'quiet' (loglevel=4) log level after boot, Raspberry OS switches to loglevel=3 after boot (e.g. lower than quiet).

                                          edit #2: alas, quiet appears to be more than just a shorthand; e.g. if used, it's made available as an environment variable to /usr/share/initramfs-tools/init and other scripts which will limit their output when 'quiet' is specified. So the 'correct' way to limit output during boot is that both quiet and log_level have to be used, in exactly that order (e.g. quiet first so it get's set, and then loglevel= to override the loglevel=4 set by quiet).

                                          So it looks like most documentation online is plain wrong or at least misleading regarding silently booting Linux and recommends mixed use of 'quiet' and 'loglevel' without consideration that their order matters, or does not account for the fact that quiet really means loglevel=4. Or mention that Linuxes will during boot switch to distro specific loglevels, which for example in case of Raspbian OS is more silent than 'quiet' boot parameter.

                                          Based on this, a couple of recommendations:

                                          • Update RetroPie documentation to mention that with quiet and loglevel, order matters. Was: to not recommend using quiet (loglevel=4), and only recommend to use loglevel=3 (which is also where RaspberryOS will switch after boot). And maybe link to RaspberryPi docs about 'quiet' as a reminder to avoid future confusion about the matter.
                                          • Update Ubuntu setup script to use both 'quiet' and 'loglevel=0' in that order instead of 'quiet' @MisterB to actually be silent edit #3: after some consideration; maybe just apply quiet - e.g. no changes needed (as it is silent enough alread, unless using a buggy kernel for which workarounds exist)
                                          • Consider if for truly silent system, also /etc/sysctl.d/{10-console-messages|98-rpi}.conf' should be changed to set lower loglevels?
                                          • Consider if loglevel=0 (or some other loglevel < 4) is a way to go all around? After all this is console loglevel, and everything will still get written to kernel logs if needed for debugging (regardless of the fact that messages to console would get suppressed).

                                          Personally for my RetroPie installation I am going with loglevel=0 for both boot and post-boot (I set /etc/sysctl.d/{10-console-messages|98-rpi}.conf to kernel.printk = 0 4 0 7). That said, I don't think I've fully thought out what negative impacts this might have so I have some hesitation to yet recommend this as a go-to tactic to silence the system. Or if the kernel.printk should be set to e.g. '0 4 8 7' instead - especially I am not confident about 3rd parameter (minimum_console_loglevel) and what it really does, or even if loglevel=0 is really valid, and I'm not ready to read the kernel source yet. Food for thought though.

                                          Fun times.

                                          edit: added link to /proc/sys/kernel/printk documentation.

                                          edit: see edit#2 above and strikeouts (e.g. quiet appears to do more than just set the log level after all).

                                          C 1 Reply Last reply 20 Sept 2020, 09:53 Reply Quote 1
                                          121 out of 223
                                          • First post
                                            121/223
                                            Last post

                                          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.

                                            This community forum collects and processes your personal information.
                                            consent.not_received