MiSTer FPGA Forum

Today I ran the script which updated Linux and thus the /media/fat/linux filesystem.
I got this error:
mv: cannot move '/media/fat/linux.update/files/linux/mt32-rom-data' to '/media/fat/linux/mt32-rom-data': File exists
mv: cannot move '/media/fat/linux.update/files/linux/soundfonts' to '/media/fat/linux/soundfonts': File exists
Looking at these 2 directories in /media/fat/linux they only contain a README file saying it where the data has to be installed.
I cannot look into /media/fat/linux.update to see what had to be copied as this directory is deleted after the update.

I think what it's trying to do there is create the directories, and it does so by extracting an image and then moving the files over. Since those dirs already exist, it complains, but AFAIK everything is still working fine.

I believe those are for running Fluidsynth and MUNT on the system itself, as opposed to on an MT32-Pi board. The Mister's CPU isn't fast enough to run them well anyway, unless you use the new overclocking option, so you can pretty much ignore any of that unless you need it and you're willing to tinker.

I know all about that but the question is:

1. If the contents of the directories in /media/fat/linux.update/files/linux are identical to the contents of the directories in /media/fat/linux there is no need for the mv commands.
2. If the contents of the directories in /media/fat/linux.update/files/linux are different from the contents of the directories in /media/fat/linux the mv commands are wrong and mv -f or something like that should have been used.

I personally do not care that much as I do not use MIDI at this time. In the past I made some tests:
First with Fluidsynth and MUNT on MISTer: not too terrific with MUNT being the worst.
Second using IP and running the emulators on a PC. Good but not very convenient.
The new kernel now supports overclocking, from what I read it is better for MIDI emulation on MISTer but still not perfect.
I have been thinking about the pi but at this time you cannot get one without breaking the bank if it is even possible to get one.

I made the post mainly for users using MIDI on MISTer: they will have to reload their data.

I don't think they would. The error is about failing to overwrite/replace the directories, so the originals, plus their contents, should still be there.

I don't think the error message actually matters. It appears to be purely cosmetic.

You may be right, I was thinking about the linux file system which is updated when the OS is updated: I have to reinstall my USB HDD spin script in /etc/init.d and update /etc/dhcpcd.conf for using a fixed IP.
The directories involved for MT32 are not part of this filesystem so they should stay as they were before the update. And not overriding them may be a good idea. It just gives these 2 errors which are of not consequence.
My mistake was thinking the directories were part of the linux filesystem. A long time ago I remember the soundfonts directory being part of the linux filesystem and this is what confused me. This new location may have been introduced at the same time as the /etc/init.d/S99 script to avoid users having to update users files in the linux filesystem.
I should use this S99user script for my custom script but I did not bother, mainly because I am not sure on how to use it due to this:
case "$1" in
start|stop|restart)
[ -f $USER_SCRIPT ] && $USER_SCRIPT "$1";;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
My script has no start/stop/restart, it is just started after boot and runs forever.

The Linux update is working fine, and the error messages you describe are not an issue.

The code producing these messages is part of Downloader, not Update All. And actually, it's very old code since it wasn't written for Downloader even. Its code moved from the old updater, so you've been seeing these error messages for the last 2-3 years at least: https://github.com/MiSTer-devel/Updater ... 002f213c9b

Why are these error messages not removed? Because the Linux update is a very sensitive process that @Locutus73 refined after uncountable hours of testing. For every change you'd have to introduce there today, you'd have to invest a large amount of time in testing the updating process again thoroughly. Or in other words, is a very big time investment in fixing something that is not broken.

Thanks for the explanation. I was just curious about the error. Usually after a OS update I do not check the log as long as MISTer reboots. Today I just saw the messages passing by and my curiosity took over.
I understand that you do not touch the code, I remember a time when very few users had to redo their SD card after a Linux update for some mysterious reason but this problem has long gone away.
If it ain't broke, don't fix it

I think those directories actually are on the Linux loopback filesystem. But once those dirs exist, trying to replace them fails. This means that if you've put MT32 ROMs in there, they aren't erased. This is more by accident than on purpose, but hey, we get the right outcome.

Because they're explicitly included in the update, almost every file in /etc/ is erased, so every one of these updates is a real pain in the butt, at least for me. I always have to do a bunch of monkeying around to fix things that get broken. (sshd_config, ntp.conf, and re-automounting my SMB3 share all come to mind.) There are solutions to this, but package management systems like dpkg are pretty heavyweight to carry around, so having to fix everything again once in awhile is probably just how things will have to work.

Most users don't do what I'm doing, so expecting the script to support my use case is pretty silly.

Honestly, I'd look at implementing versioning for user config files in the update script, but it's so obfuscated that it's more trouble than it's worth.

I understand your pain. I am lucky as the only 2 things to restore are just copying one script to /etc/init.d and my customized dhcpcd.conf to /etc.