@MrStruders If by fresh install you mean using a new image, then no, since the new image will write everything from scratch. Can you run another update, also updating the OS and packages when prompted, of the RetroPie-Setup script ?

After downgrading the kernel to 1.20190401-1, I tried to run RetroPie-Setup which upgraded the kernel to 1.20190517-1. Now the overscan settings still apply to both console and ES. I don't know if this is because of the downgrade-upgrade procedure, or because of the changes I made to /boot/config.txt. Anyway I paste here the relevant settings I have in the file: disable_overscan=1 overscan_left=20 overscan_right=20 overscan_top=11 overscan_bottom=11 overscan_scale=1

Great news, will do ASAP!

@mitu said in Hash sum mismatch error: don't have SSH enabled, then I just enabled SSH, and updated the thread info with read-me-first topic. I have installed the 4.4 image from the RetroPie site, and I have internet connection, I made a ping to www.google.com and work. I now with PuTTy connected to the RetroPie. What should do I do? Where is the path to get the log files? E: Failure to obtain http://espejito.fder.edu.uy/raspbian/raspbian/pool/main/u/unzip/unzip_6.0-21+deb9u1_armhf.deb Hash sum mismatch Hashes of expected file: - SHA256:d69087f3500527bd24f0ee8870a41ac9e45eb34f6b73081a7775fd7ef8825208 - SHA1:9156bdc618af94d53ac6a864ef8d93c0f9af0fa7 [weak] - MD5Sum:76f6caff8c43590c18bf7b4d622adc2f [weak] - Filesize:149042 [weak] Hashes of received file: - SHA256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 - SHA1:da39a3ee5e6b4b0d3255bfef95601890afd80709 [weak] - MD5Sum:d41d8cd98f00b204e9800998ecf8427e [weak] - Filesize:0 [weak] Last modification reported: Sat, 27 Apr 2019 16:08:06 +0000 Looking into it, the web http://espejito.fder.edu.uy/raspbian/raspbian/pool/main/u/unzip/unzip_6.0-21+deb9u1_armhf.deb isn't working, I copied that URL in my Google Chrome browser and a error file was downloaded. But https://espejito.fder.edu.uy/raspbian/raspbian/pool/main/u/unzip/unzip_6.0-21+deb9u1_armhf.deb Work's just fine, so look's like sudo apt-get upgrade command isn't working because that http isn't https. EDIT: I have changed the /etc/apt/source.list and added deb http://mirrordirector.raspbian.org/raspbian/ stretch main contrib non-free rpi firmware deb http://archive.raspberrypi.org/debian/ stretch main ui it seems it working now, the upgrade is doing downloading files without error. But, is ok to use those repositories? My guess? Is a problem for South American people (I'm from Argentina), that the source list is unupdated or wrong setted, because when I got the url it use http and not https, looks like that's the main reason. I tried to install the retropie-manager (after the update & upgrade) and I got this error Could not install packages(s): python-dev virtualenv. EDIT 2: I have it working, to workaround I just change /etc/apt/source.list.p/retropie.list (or something like that) and added (can't edit because the Akinet detect that is a spam, but add deb before the url) https://espejito.fder.edu.uy/raspbian/raspbian stretch main After saving the file, I use sudo apt-get clean and sudo apt-get update and everything is working just fine (or it seem's like that). The error is that the URL is unupdated, but isn't the best option. Idk if I have to send an email to the RetroPie developers to update the repo url for Argentina.

@AssPunchMan said in PS3 Shanwan Controller lossed on every update: Its possible fix this? update without loss the PS3Controller pairs. The upgrade that broke the PS3 controllers - the Linux kernel - also broke other Bluetooth controllers and it's not under the project's control. It's a badly timed bug, but that's not something that happens regularly. If you wish to not be bitten by such situations, then only upgrade the packages you need (for bugfixes or new features) and skip the OS and driver upgrades.

@oleguer If you run an update of the OS and packages through the RetroPie-Setup script, it will install a correct Linux Kernel, which doesn't have the bug in this topic. Use the update from RetroPie-Setup, it will fetch the latest version of the script and then choose yes when it asks if you want to update the "OS and packages".

@mitu Okay, I know that now. It seems like it would tell you something different than ask for user if the repository was missing or deleted.

@granderjoree We don't support 3rd party images - https://retropie.org.uk/forum/topic/3/read-this-first.

Well i'm dumb. Had the controller on directinput instead of xinput. Update had nothing to do with anything. Sorry about that.

user@host$ diskutil list /dev/disk0 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *500.3 GB disk0 1: EFI EFI 209.7 MB disk0s1 https://freeaccountsonline.com/ 2: Apple_CoreStorage Mac HD 499.4 GB disk0s2 3: Apple_Boot Recovery HD 650.0 MB disk0s3 /dev/disk1 (internal, virtual): #: TYPE NAME SIZE IDENTIFIER 0: Apple_HFS Mac HD +499.0 GB disk1 Logical Volume on disk0s2 3BAC0F9E-19F8-4AAB-8752-6514B573B497 Unencrypted /dev/disk2 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: FDisk_partition_scheme *15.9 GB disk2 1: Windows_FAT_16 boot 59.8 MB disk2s1 2: Linux 15.9 GB disk2s2 user@host$

@CapNinja I suggest it can be the timer that leads to such behaviour. After 3s of waiting if the PID is active then a kill term 9 is send to process. That leads to a process abort. You can try to extend the time by changing the sleep command or by changing the number counter. I get some obscure errors if a process was terminated with siglevel 9. No I don't think it has something to do with the script. Sounds like problem with data access from KODI. Suddenly is a kind of magic, too. You wrote you use a pendrive, which can lead to problem 2 - writing cache for KODI. KODI responds sometimes slow on pendrives esp. with ntfs format Unrelated to script. All in all I think you might get some problems with the powering and the pendrive. To be sure I would extent the sleep timer from 0.1 to 0.25 be aware that a not closing process needs now 30x0.25s time ~ 8s to be forced closed now. Maybe you can give feedback to this later ;) @Efriim retropie-setup dialogs can't be closed. As long as the call was initiated by runcommand shell script then every script or binary can be closed. If the runcommand call is missing then there is no pathway for the close switch.

The PR was merged, so it's safe to go back to the master branch if you were testing. Don't forget to updateruncommandafter returning to the master branch (which is done automatically when you use the Update RetroPie-Setup script option of the script itself). Thanks to @mitu and everybody else who helped with troubleshooting & testing.

Following up - I did a reinstall of the Xpad driver (removed and then installed) and it fixed my triggers, too.

This topic has a lot of good info about migrating to 4.4 on a new image.

@hermit That's not how it works. If the ROM in question worked with an older version of the snes9x Libretro core, but the same ROM has an error now, we should report this to the upstream project - so it gets fixed in the future. You already have a topic opened on the Snes9x board - you can report this regression there, mentioning the ROM name (and checksum) and the versions implied - the one working and the non-working one.

@Lumbeechief081 So, if you don't do it already, now that you've learned how quickly you can lose all the work you did is the perfect time to start making backups. 😉

@mitu Thank you! I can't believe I didn't stumble upon those in my search.

@sl89 the repo moved a few years ago so maybe you installed before that.

@rbaker sorry for the very later reply! I didn't even noticed your post until now. Just apologized to Cyde earlier today for being late haha. That makes a lot sense RBaker and thanks for the link to your thread and time. Just i tested the controller on my other Pi and it worked good. Some reason when i uninstalled the PPSSPP and Reicast emulators my problem was solved.