Linux Mint 20 Ulyana - Have You Upgraded?

[Nick H. Supervisor]

Hi guys,

 

This morning I booted up my computer and saw a notification saying that Linux Mint 20 Ulyana is available for installation. When I was using Windows 10, if such a notification appeared I would have been one of the first to start the upgrade process (mainly to stop the nagging, but that's another matter). However, I remember performing an upgrade last year and I ended up noticing some performance issues which caused me to roll back to my previous version. I'm not certain, but I think the update that I did was to a Beta version of Tricia so that might explain a few things.

 

Anyway, I'm tempted to perform the upgrade to Ulyana today but first I would like to know if anyone here has already performed the upgrade, and if they have I'd be interested to know if anyone has noticed any real differences since? I've got my Timeshift all set up as well as a backup of any important data on an external HDD so it wouldn't be the end of the World if I did encounter an issue, but I thought it would be interesting to have a chat about it with people that have already made the switch. 🙂

 

Cheers all!

[DJGM]

I would if I could . . .
 

[Nick H. Supervisor]

For info, I upgraded the other day. I needed to put some customisations back in place on some apps but aside from that it's running wonderfully.

 

The only small issue I have is when I put the computer into suspend mode. I haven't got the exact time frame down yet, but if it is left suspended for too long and I wake it up again it doesn't recognise the keyboard or touchpad. I need to do a hard restart. It's not the end of the world, since Firefox remembers all the tabs that were open, but it's a bit annoying.

 

Aside from that I'm very happy with the upgrade!

[ThaCrip]

I tried Mint v20-Cinnamon. but in the end I had to restore my Clonezilla image of Mint v19.3-Cinnamon due to the following issue...

 

https://forums.linuxmint.com/viewtopic.php?p=1841962#p1841962

 

in short... my hard drives/USB thumb drives (and the like) are not seen by the file manager after a clean install (I even tried the upgrade and basically has the same results) of Mint v20 like is normally expected (I even tried Xfce but basically experienced pretty much the same results) and it does not matter whether I use "BIOS+MBR(msdos)" or "UEFI+GPT", even though 'lsblk' does see the hard drives (technically I could force mounting of the hard drives/USB stick using 'Disks' etc but it's not a proper fix and will make basic things more of a chore to do). Mint v19.3 works perfect upon a clean installation in either installation mode. so it's clearly some issue with Mint v20.

 

so I figure if that issue is not resolved by Mint v20.1, chances are the entire Mint v20.x series won't work on my computer and my only hope is Mint v21 which will probably be out about 2 years from now and if that fails, I might be forced into using Mint's alternative release... LMDE, but I am hoping to avoid that since it's Debian based where as the mainline Mint is Ubuntu based.

 

funny thing is, like I mentioned in that link, if I do a clean install without any additional hard drives attached things work as expected as I can even connected a USB thumb drive and that works. but as soon as I power down the computer, reconnect my SATA cables to the additional hard drives (I got three of them) and power back up the issue returns with the hard drives/USB thumb drive.

 

so hopefully by Mint v20.1 things are more polished.

[ThaCrip]

Not long ago I was testing v20.1 beta and the issue I described above is no longer there. so...

 

just to see if that issue was truly fixed I decided to try clean installing v20 again that I was having issues with and the issue I described in my above post no longer happens. I am not entirely sure what I did but my best guess is it's possible I cleared my BIOS settings (like using jumper on motherboard and removing power from motherboard for some minutes) between the time I had the issue and more recently when the issue appears to have totally disappeared (at least with the UEFI+GPT install which is all I tested not long ago, which is probably best anyways).

 

so apparently there was no bug with Linux Mint, it was some weird glitch on my system. I am just waiting for Mint v20.1 to go final before I clean install Mint v20.1 (but ill have to backup some stuff first from my v19.3 install) which I suspect should be soon as normally it would have been out before Christmas, which is typically the case with vXX.1 versions, but I imagine more bugs turned up then they expected. so I won't be surprised if it's official release is a bit into the new year at this point, but who knows. but I would rather wait for them to get the release right then rush it to meet a deadline and have it be so-so. I could always clean install v20 and then upgrade to v20.1 once it's released but at this point ill just wait for v20.1 and then ill be set for a while since it's supported until 2025 and Mint v21 I think will be out around mid-2022 given their general release pattern. so I figure ill be on v20.x series for at least 1.5-2 years or so. probably closer to 2 years as it's probably a bit safer to wait that six months after the initial major version release as by then it should be more polished.

[cork1958]

I've only upgraded 1 of my Linux machines to Ulyana so far as I'm quite happy with Tricia on the other 3 machines.  No issues at all on that 1 machine but I have noticed that there are a few apps that aren't available on it that I use on Tricia, which is mainly why I haven't upgraded those other 3. I'm not positive, but I think those other apps I have on other machines aren't available due to lack of snap. To many hoops to jump though to get them installed on Ulyana. Debating on trying LMDE or going with straight up Debian because of that.

[ThaCrip]

16 hours ago, cork1958 said:

I'm not positive, but I think those other apps I have on other machines aren't available due to lack of snap. To many hoops to jump though to get them installed on Ulyana.

 

https://fossbytes.com/how-to-enable-snap-and-install-snap-packages-on-linux-mint-20/

 

but I can see how it might be 'too many hoops to jump through' for you though. but everything I use, which is not too much, is more of a standard install (i.e. '.deb' or PPA or through Software Manager) as I don't use snap or any alternatives to my knowledge. plus, if I recall correctly using non-standard methods wastes quite a bit more disk space since all of it's dependencies are contained within the download, which increases download size quite a bit and can waste a decent amount of disk space, especially if you start getting multiple things setup that way.

 

16 hours ago, cork1958 said:

Debating on trying LMDE or going with straight up Debian because of that.

 

LMDE seems decent but from what little I played around with it, I am not sure if it's updates are as simple as the mainline Mint(?), like with kernel updates etc, and that's not supported for 5 years like the mainline Mint versions are. LMDE series might supported for a couple of years or so tops, at least based on fairly recent memory, which is not much as I would figure a minimum of 3 years or so as when your looking at 2 years (or so) or less, one is sort of forced to upgrade a bit too often (but I guess Win10 is sort of like that with it's 18 month(1.5 year) cycles. but upgrades tend to be a bit simpler as with Linux Mint, minor upgrades(i.e. ".0" to ".1" etc) are okay, but with major upgrades (i.e. v19.x to v20.x etc), it's best to clean install is the general word from what I have heard).

 

plus, I might be wrong... but I think doing basic security updates etc on the official Debian seems more complex(?) vs Mint which is easy. that's why I can't see myself dumping the main Mint (Ubuntu based) anytime soon as it's a wonder people don't make stuff a bit more simple on Linux in general where possible as it makes no sense to make basic tasks (like security updates for OS or installing basic programs and making programs function as simple as possible) more complicated than they need to be. because while I get with Linux things in general can be a bit more complex, we don't need it to be TOO complex though either as things should still be simple enough to where you don't have to be some computer genius to do stuff that's normally a fairly simple thing (or something that does not normally require too much time to do). but I think this is partially why Linux won't become mainstream anytime soon is probably... 1)lack of software and 2)it's a bit more complicated to use compared to Windows in general (especially since one will probably have to use the terminal at some point and remembering what commands to type can be tricky etc (which is why I typically log stuff to a text file for future use in case I need to do something and forget it. but I like how you can press the up and down arrows on the keyboard to cycle through previously used terminal commands which can save time). but I think if Linux can do what someone needs, it's a solid alternative to Windows. so for what I do, Linux works well enough for me.

 

but anyways, maybe LMDE will be a option for some people. because right now, if for some random reason I could not use the mainline Mint, I would be seriously considering LMDE if I had to.

 

16 hours ago, cork1958 said:

I've only upgraded 1 of my Linux machines to Ulyana so far as I'm quite happy with Tricia on the other 3 machines.  No issues at all on that 1 machine but I have noticed that there are a few apps that aren't available on it that I use on Tricia, which is mainly why I haven't upgraded those other 3

 

Yeah, at this point there is no real rush as Mint v19.x series, as I imagine you already know, is supported until April 2023. so after about 2 years from now you will have to start looking into upgrade from v19.x series soon at that point. but Mint v21.x series will be out by then since I imagine as you already know it seems like there is pretty much 2 years apart between each major release (i.e. Mint v19 is 2018, Mint v20 is 2020, Mint v21 should be 2022 etc).

 

but that's definitely one thing I like about the mainline Mint is 5 years of support as this does not feel too short like say a couple of years or so does where you will be sort of forced to do bigger upgrades more often. but, like I was saying, once I clean install Mint v20.1 when it's released soon enough, ill probably be on it for at least a couple of years or so and if I don't feel like upgrading in that couple of years or so, I can still put it off for another year or two if I really needed to.

[ThaCrip]

I clean installed Mint v20.1-Cinnamon to my main PC about a day ago (was on Mint v19.3-Cinnamon) and so far things work pretty good but ill have to see how things are after a week or two at least, if not a month or so, to see how stable/good things are as it's too early to say for sure but my initial/early impression is positive ; I still got some stuff to tweak and install but the bulk of things are setup.

 

but a moment ago... whatever happened I noticed the 'HDMI' output was not selectable in the Sound (i.e. right click sound icon > output device > HDMI / display port 2) as it was not there. but I decided to try loading 'Display' from the start menu in Mint v20.1 and as it accessed it screen flickered a bit and at that point I checked for the HDMI output again and it was back up and working like usual. so who knows what happened there but ill have to keep a eye on it (that's never happened when I was on Mint v19.3-Cinnamon which is why I imagine it's some glitch in relation to v20.x series) as my uptime is a bit over 19 hours so far. I am using a 1050 Ti 4GB with the proprietary NVIDIA v460.32.03 driver which is the one recommended (it's the newest one to even though there are two older ones I could try which are v390.141 and v450.102.04) in the 'Driver Manager' in Mint v20.1. I just noticed it as I was going to turn on my TV and play a video file on it instead of my computer monitor and noticed that the HDMI audio output was gone (which is what I got to select so audio is played out the TV speakers instead of my computer speakers) even though the standard computer 'Speaker' option was still there and working (but only plays audio on my PC speakers obviously). ill have to keep a eye on this to see if it returns or not. but short of this issue, I can't see any other obvious issues that are a problem (although I did have a temporary issue in relation to the Trash can but, in short, after entering the 'fstab' entries for my other three hard drives and using 'sudo mount -a' command, Trash was not working properly (but only on the three additional HDD's I used, not the main boot drive SSD which was working as expected with Trash) until I rebooted and all worked as expected then).

 

p.s. I clean installed Mint v20.0-Xfce to a couple of my backup computers roughly a few days ago now. ill just wait until the upgrade to v20.1 is announced and then upgrade to v20.1.

[ThaCrip]

UPDATE to my above post: well, at least as of a couple of days of uptime, which seems to be enough so far, just by switching to the other kernel offered in Mint v20.x series, which is the 5.8 kernel, seems to have cured basically the few issues I was having...

 

-HDMi audio disappearing (with 5.8 kernel, after 2 days and 1 hour of uptime as I type this, it's not disappeared yet. because before all I would have to do is basically be away from the computer for some odd hours and return and the issue showed itself)

 

-Trash can bug (after a bit of time passes it seems 5.4 kernel (default in Mint v20.x) on a couple of my hard drives etc if you press 'delete' on a file for example, it normally goes to Trash can and then you can right click that and select 'empty trash' and that's that, your file is permanently deleted, which is expected behavior. but once the bug kicked in, a couple of my HDD's (main boot drive(SSD) and my 4TB) still worked, while the other two (2TB/5TB) did not in the sense if you try to delete a file by pressing 'delete' key and then it's supposed to go to Trash can so I can empty it, but it does not and the file is still on hard drive in the ".Trash-1000" folder and I have to manually go into that folder and delete the files from there at which point the file is truly deleted and the hard drive space is freed up. I could have used a work-around (shift+delete, or adjust some settings in Nemo file managers preferences so when pressing 'delete' key it no longer immediately goes to Trash can but gives you a prompt to confirm file deletion at which point it's set to permanently delete the file and just skips right over the Trash can which is a work-around for the bug when I was using the 5.4 kernel), but it's nice to see I don't need to so far with the 5.8 kernel as things work as expected now.)

 

and as a bit of a bonus... resuming playback from a pause, GPU accelerated x264 video on SMPlayer/MPV combo no longer lags for about 2-3 seconds before video is playing like normal again. it just works perfectly. NOTE: when running only software mode, it works fine on both 5.4 and 5.8 kernels, but when using the GPU, which naturally I prefer to take the load off CPU, then 5.8 definitely works better on my system. NOTE: it seems I have to be using the HDMI audio output for that to occur on the 5.4 kernel. because I think when I was using the standard 'Speakers' audio output, which goes to my PC instead of the TV, it does not seem to do that with the lag upon resume. but when using the HDMI audio output, which is what I use when I want to watch something on the TV instead of PC monitor, it acts up.

 

but now that those issues appear to have disappeared (especially the HDMI audio disappearing bug, since it was the most annoying), I am definitely liking Mint v20.x over Mint v19.x as things seem to be a touch more snappier and even with file manager open windows when highlighting the open windows and it shows you that little preview before you click it, does not seem to disappear occasionally on some of the open windows like Mint v19.x does.

 

but only thing that's a potential draw back is the 5.8 kernel is only supported til Aug 2021, which means once they release a newer kernel ill have to switch to that at some point and hope there are no regressions. but who knows, maybe as time passes, 5.4 LTS kernel will start working properly once again(?) (since it's probably all around best to use that if possible due to it being supported for the life of the Mint v20.x series, which is til 2025). but I suspect not.

[Mindovermaster Moderator]

2 hours ago, ThaCrip said:

but only thing that's a potential draw back is the 5.8 kernel is only supported til Aug 2021, which means once they release a newer kernel ill have to switch to that at some point and hope there are no regressions. but who knows, maybe as time passes, 5.4 LTS kernel will start working properly once again(?) (since it's probably all around best to use that if possible due to it being supported for the life of the Mint v20.x series, which is til 2025). but I suspect not.

You have to do that with any kernel update, dude...

[ThaCrip]

11 hours ago, Mindovermaster said:

You have to do that with any kernel update, dude...

 

Not in terms of more bigger version increases as it's typically just 5.4.0-xx to 5.4.0-xx and not 5.4 to say 5.5 etc as here is how things work on Mint series so far on a clean installation...

 

-Mint v19.0-19.2 = 4.15 LTS (which is supported for the life of Mint v19.x which is til 2023 (but one can opt for 5.4 which is supported til April 2023 at this point))

 

-Mint v19.3 = 5.0 (but I assume these automatically upgrade to newer kernels as they are released. but at this point seems to have stopped on 5.4 which (Update Manager > View > Linux Kernels) is supported for the rest of the Mint v19.x series until April 2023 (and so is 4.15 LTS))

 

-Mint v20.x (so far) = 5.4 LTS (supported til April 2025 which is when Mint v20.x series support ends in general.)

 

 

but... since I changed to the newer 5.8 on Mint v20.1, which is not LTS on Mint and is the only other one listed in the Update Manager > View > Linux Kernel's section, it specifically says it's supported but only until August 2021 and not April 2025 like the LTS version(s) is. so while ill get kernel updates here and there in between it's always small updates to the 5.8 series, like... 5.8.0-xx (which the rest of the Mint kernels listed above does similarly, so your basically on the same main kernel version for the life of the Mint series unless you switch to those non-LTS ones). I imagine once that expires it will automatically start offering me newer kernels which appear to be supported for 6 months. but this is the first time I used a non-LTS kernel on Mint since I have been using it which was Jan 2019 to date and I basically stuck with the 4.15 LTS kernel when I was on Mint v19 series.

 

I am not sure which is the next short term supported one that will be offered on Mint v20.x. maybe 5.9 or newer(?). but ill find out eventually. but the head developer over at Mint suggests most people stick to the LTS kernel that comes with the Mint installation by default (at least on the standard releases even though the 'edge' release comes with 5.8 but it's only supported, like I was saying, until August 2021) unless one has to use a newer one basically. but in my case 5.8 clearly works better given the bugs disappeared and is still good so far after 2 days and 16hours+ of uptime.

Edited January 14, 2021 by ThaCrip

[ThaCrip]

UPDATE: after Mint v20.2 was released earlier last month and I upgraded to it from 20.1 I decided to go back to the 5.4 LTS kernel to see if the issues were still there and everything is good. so I don't know if it was bugs in the 5.4 kernel that were eventually fixed or if it was something on the Mint teams end. either way, it's nice to be able to just stick with the LTS kernel now.

 

so while overall 20.2 was a upgrade... one thing I see as a 'downgrade' in 20.2 vs 20.1 is they removed 'gnote' and replaced it with 'sticky notes'. but thankfully one can just remove the sticky notes (sudo apt remove sticky) and reinstall gnote (sudo apt install gnote) and their previous gnote data is still there. I am surprised they did that as gnote is superior overall as it's more compact and stays out of your way since it's note data is contained in a single window.

 

p.s. while I still have SMPlayer installed (mainly as a backup option now), I have just been using the default Mint installed 'Celluloid' paired with MPV which is simple and works well.

[ThaCrip]

Recently I switched back to Mint v20.3-Xfce (I opted for a clean install) mainly because on Cinnamon it seemed after roughly a day or so of uptime there would be a small bit of stutter in video playback through Celluloid (I got MPV installed so it's using hardware acceleration as you can see in the options of Celluloid it's got 'hwdec=yes' etc) and restarting Cinnamon (i.e. ALT+F2, press r, then enter) would temporarily cure the stutter but it would be back within the next day or so and I got tired of that.

 

so far Xfce is fine as I currently got 9+ days of uptime and Celluloid still plays video smoothly.

 

hell, even a underpowered laptop I got (AMD E-300 CPU) is much smoother on video playback with Xfce vs Cinnamon as on Cinnamon there is even more obvious stutter during playback (it's outright annoying/unusable (where as at least the stutter on my primary PC described above was not nearly as annoying since it was not as obvious, but still there)) on Celluloid but on Xfce it works as expected.

 

but I had one issue on Xfce that it took me a while to fix but seems to be good now (I have not tested after reboots but I think it will be okay). basically in relation to pulseaudio not keeping the correct HDMI port I set as it sit overnight it would switch back to the non-working port instead of staying on the one I wanted it to. so instead of 'analog / HDMI 2' (analog being my PC speakers and HDMI 2 being the sound to my TV) being selectable with a simple left click on sound icon etc, after it reset it would go back to 'analog / HDMI' which there is no sound output on HDMI. but anyways to get to the fix... I did 'sudo xed /etc/pulse/default.pa', found the "load-module module-switch-on-port-available" line, then make it look like "#load-module module-switch-on-port-available", then save the file, then issue 'pulseaudio -k' from terminal and once pulse audio restarts I set things how I like them and after sitting overnight, it no longer switches back to the non-working HDMI port. I pretty much did not have this issue on Cinnamon although I did notice every once in a while the HDMI stuff would disappear etc. but so far this stuff seems more stable on Xfce, but ill have to see how things play out after months of use.

 

but one issue that still remains the same on Cinnamon or Xfce is with the default 5.4 kernel that if I play a video through Celluloid on the TV like usual, then move mouse pointer back to the PC monitor side and say use the already open browser briefly etc and then go back to the TV side and resume video playback that there is roughly 2-3 seconds of delay/lag before video playback is back to normal. but thankfully simply changing to a newer kernel fixed this issue as 5.8(has been 'end-of-life' for a while now),5.11(support ends Feb 2022) and the current 5.13 (support ends Aug 2022) all work as expected with instant video playback.

 

but one small quirk on Xfce is that when manually engaging the lock-screen (CTRL+ALT+L) it seems to put monitor to sleep 10min later even though I set general screen to go to sleep after 30min. because on Cinnamon when I set screen to go to sleep after 30min, even if I manually engage the lock-screen it still respects the 30min of no use before the screen goes into sleep mode and powers off the screen basically. there might be some other minor quirks with file manager on Xfce that was a bit better on Cinnamon, but nothing I am too concerned with. but all-in-all, I can pretty much deal with these trade-offs given the main issue I switched back to Xfce for, the video stutter issue, appears to be fixed.

 

another issue on Xfce that works fine on Cinnamon, at least on my slow laptop (although I had to stay with Xfce due to Cinnamon having really stuttery video playback), is that when configuring the 'Display' on Xfce so that the primary laptop screen is on the RIGHT side and the TV is on the LEFT side as soon as I apply it, while the basic way one drags stuff out of the screen now works in a more natural way (given the physical setup/location of the laptop so it's more natural), the Mint menu and desktop icons etc immediately change to the TV instead of staying on the laptop screen (and for the record I set the laptop screen to 'primary' to, but does not have any effect). but one can fix this be tweaking some of the options on Xfce to get the Mint menu back on the correct screen etc ('panel > display > general > output: primary' etc). but I won't get into the details for now.

 

one issue that applies on both Cinnamon and Xfce (although reacts slightly better on Xfce in the sense the Menu don't change screens like it does on Cinnamon) for me is the main PC monitor not coming back online after you let it sit for hours/overnight and only way I noticed to get it back again at this point is to press CTRL+ALT+F2 and then CTRL+ALT+F7 which brings the monitor back to life and things function like usual at this point again (like all programs etc are still running like usual) but it will repeat this process the next day, which is annoying and not realistic to deal with this issue. but the fix, without getting into too much details, is to edit "/etc/X11/xorg.conf" and basically replace the line above "metamodes" (I used the 'NVIDIA X Server Settings' to generate the basic xorg.conf) with the following line...

 

Option "ConnectedMonitor" "DFP-2, DFP-1"

 

once I did that, everything (the monitor etc) functions as expected. but to find the proper location of ones monitor (so one knows which DFP etc to insert as in my case DFP-2 is the monitor(DisplayPort connection) and DFP-1 is the TV(HDMI)) you can check the "/var/log/Xorg.0.log" file.

 

one little small visual tweak I prefer, since i feel it's more inline with the general look of Mint, is 'Panel > Appearance > General > Dark Mode = enabled.' ; basically makes the menu 'dark' instead of it's usual light color.

 

another small issue which works by default on CInnamon that does not on Xfce as it does not seem to keep ones clock in sync with the time. but I fixed that on Xfce by basically doing 'sudo apt install systemd-timesyncd'.

 

so all-in-all I would say Xfce is probably the 'safer' all-around choice even though I think each DE has it's little quirks etc. but with that said, as I am sure many around here know, there is a chance a lot of other peoples hardware won't even have these issues I got as Cinnamon might work great.

 

with all of that said... Mint v21.0 will probably be released in June if the usual release cycle holds. I may consider switching then, but then again I might wait until Mint v21.1 is released which will probably be Dec 2022 or Jan 2023 as by then it might be a bit more polished etc and hopefully it will work good with the LTS kernel it ships with so I can just leave it there and not have to mess around with changing kernels like I had to do with Mint v20.x due to that issue I described above.

 

p.s. I switched Xfce from it's default 'Xwfm4 + Composting' to 'Xfwm4 + Compton' in the 'Desktop Settings > Window Manager', which makes Xfce a bit lighter on resources to. plus, if I recall correctly that fixed a issue I had back in the early Mint v19.x series where the computer would eventually freeze coming out of the lock-screen after about 5-10 days of uptime. I have not tested this on Mint v20.x yet to see if it still occurs but if 'Compton' ever acts up ill consider switching back to 'Compositing' and see what happens etc. but I think ill be fine as things are now.

Edited January 25, 2022 by ThaCrip

[ThaCrip]

For those who still burn CD/DVD's and use Linux Mint v20.x series and want to use Imgburn (i.e. https://www.majorgeeks.com/files/details/imgburn.html ; I linked to here instead of official site since that installer does not have the junk the one on the official site does and it's the same program version) do the following to get it working...

 

1)Install Wine (currently installs newest stable version of Wine (i.e. wine-7.0) from Jan 2022)...

 

1)sudo dpkg --add-architecture i386

2)wget -nc https://dl.winehq.org/wine-builds/winehq.key

3)sudo apt-key add winehq.key

4)sudo add-apt-repository 'deb https://dl.winehq.org/wine-builds/ubuntu/ focal main'

5)sudo apt update

6)sudo apt install --install-recommends winehq-stable

7)sudo apt install wine-desktop-files

 

2)Load up "Configure Wine" from Mint menu... on 'Applications' tab click 'Add application' then guide it to the 'imgburn.exe' file (should be located in the 'Program Files (x86) > ImgBurn' folder) and click 'open'. then with the 'ImgBurn.exe' highlighted in the 'Applications' tab, you should see "Windows Version:", switch it from 'Use global settings' to 'Windows XP', then click 'Apply', then ''OK'. then after maybe 5-10 seconds the Wine processes will completely close.

3)Start ImgBurn (if it fails to start see "IMPORTANT NOTE" below!). once ImgBurn starts up it will probably say "Searching for SCSI / ATAPI devices..." and just under that it will have a error saying, "No devices detected!". so at this point ImgBurn is still useless. but to fix this, in ImgBurn go to...Tools > Settings > I/O. then for 'Interface' select 'SPTI - Microsoft' and under that you will see "SPTI Device Enumeration Method" and change that to "Device Interface" then click 'OK'. it should now see your SATA DVD burners and ImgBurn should now work as expected.

IMPORTANT NOTE: if ImgBurn fails to start I seem to have found a reliable way, at least on my Mint v20.3-Xfce system, to get it to start up. basically you can either load up another Wine program first (then start ImgBurn), OR, if you don't have any other Wine(Windows) programs installed, load up ' Configure Wine' from the Mint menu and just let it sit there and then start up ImgBurn and it should load! ; because I noticed when Wine is completely closed/not running at all, and you try to load ImgBurn, it always (or nearly always) fails to start up. but when a wine process is already active (which running another Windows program or leaving 'Configure Wine' running etc) and then start up ImgBurn it seems to always work.

NOTE: if for whatever reason ImgBurn seems 'frozen', you can immediately shut it down (along with ALL other programs using Wine) by issuing 'wineserver -k' (without the ') from terminal and press ENTER and it will immediately stop.

 

I tested out a quick burn and verify with ImgBurn with a Clonezilla ISO on a CD-RW disc and it worked fine as it boots up etc.

[ThaCrip]

UPDATE: to my previous post above in regards to Imgburn/Foobar2000... lately I have been using PlayOnLinux (sudo apt install playonlinux) to keep Imgburn and Foobar2000 separate from my main Wine installation as things are more reliable this way as they run in their own Wine folder separated from the system. currently I am using '6.13-staging' (the 64bit one) to run Imgburn/Foobar2000. basically I plan on using the standard Wine installation for gaming with Lutris and for programs use the PlayOnLinux stuff as it should keep things more reliable this way (as lately prior to trying PlayOnLinux even Foobar2000 started to have trouble starting up etc, but now all is good again).

 

-Main Wine (i.e. standard system installed Wine) general folder goes to = ~/.wine

-PlayOnLinux makes it's own in = ~/.PlayOnLinux/wineprefix (it even creates one so it's easier to access without having to 'show hidden folders' etc, which one can access at 'PlayOnLinux's virtual drives' in ones Home folder, which accesses that same folder)

 

but using PlayOnLinux, I don't have to do any tricks to get ImgBurn to start up, it just works, although still requires the stuff I mentioned before with changing Wine to WinXP mode along with the SPTI in Imgburn.

 

NOTE: if you want to make it easy to launch a program from desktop shortcut with PlayOnLinux without having to load up PlayOnLinux first you basically do this... start up PlayOnLinux, left click the program you want to create the shortcut, then off to the left you will see 'Create a shortcut' and you simply click it basically.

 

NOTE: I use the following (which is optional) to create a keyboard shortcut to launch Foobar2000 on my Mint v20.3-Xfce install... 'Keyboard > Application shortcuts'. click 'Add' and and for 'Command' you basically enter the following...

 

/usr/share/playonlinux/playonlinux --run "foobar2000"

 

in my case I set Foobar2000 to launch by pressing CTRL+SHIFT+F

 

I just make sure to install Foobar2000/Imgburn etc into the same Wine container otherwise it wants to create it's own Wine folder for each program you install which will waste roughly 500MB-1GB of storage space if you do that for each new program you install the standard way in PlayOnLinux. so to save space I do this... start up PlayOnLinux, left click a already installed program(like the first one you installed for example), then off to the left you will see 'Configure', click it, then click on 'Miscellaneous', then click 'Run a .exe file in this virtual drive'. this way it installs the program to that same Wine installation and won't create a fresh one. they say it's safer to give each program it's own Wine thing but in my experience I doubt Foobar2000 and Imgburn will mess with each other as it seems to only potentially get out of whack when using games paired with programs as I noticed when switching back and fourth between programs to games on Lutris it seems to want to reconfigure Wine and I suspect this is what eventually got things out of whack because not long ago before I looked into this PlayOnLinux stuff that Foobar2000 was even having trouble starting up on the standard Wine install. so this is why I am using the PlayOnLinux for the programs and keep the standard Wine install reserved strictly for games. so things are likely to work smoother now and even if say the games got out of whack, I can always just backup the game save folder, delete the "~/.wine" folder, reload 'Configure Wine', which will recreate a fresh "~/.wine" folder and I am back in business and it won't interfere with Foobar2000/Imgburn as I got Foobar2000 a bit custom configured to my liking (spacebar is play/pause, arrow left rewinds 5sec, arrow right fast forwards 5sec, and got custom 'Convert' stuff there which is nice going from FLAC to MP3 etc) and don't want to have to redo that if I can help it and this helps prevent that from happening.

Edited February 27, 2022 by ThaCrip

[ThaCrip]

After playing around with ImgBurn v2.5.8.0 (I recommend getting it from MajorGeeks website since it does not contain the junk the installer on official site does) some more through PlayOnLinux (I am using Linux Mint v20.3-Xfce)... in short, I recommend using Wine v4.0.4 since ImgBurn works in it's default state that way in ASPI mode for CD/DVD burner detection and you no longer have to change ImgBurn itself to 'SPTI' mode for it to work (you still need to change Wine from default Windows 7 mode to WIndows XP mode though otherwise ImgBurn will hang on it's initial loading screen).

 

but after some limited testing... it seems Wine v4 series is the newest you can use with ImgBurn for it to still work with it's default ASPI mode CD/DVD drive detection as when using Wine v5 series or newer you got to switch ImgBurn itself to SPTI mode (i.e. Tools > Settings > I/O, select 'SPTI - Microsoft' then below where it says 'Device Enumeration Method' change it to 'Device Interface'). but you still got to change it from Windows 7 to Windows XP mode for it to work. also, if you use a old version like Wine v2.0.5 you won't even have to change Wine from Windows 7 to Windows XP mode since it defaults to Windows XP mode. but reason I suggest using Wine v4.0.4 instead is the fonts look better in ImgBurn vs when your using Wine v2.0.5. NOTE: without running Wine in Windows XP mode, ImgBurn will simply hang at the loading screen and is unusable.

 

I realize not many people burn CD/DVD's anymore but this is solid information for anyone wanting to use ImgBurn on Linux as I still consider ImgBurn to be basically the 'gold standard' of burning programs. hell, I even overburned a AUDIO CD (I used CD-RW as a test) by 1min15seconds with success (then use file manager to copy the last track back to the PC and listened to it with Foobar2000 to make sure there is no obvious audio flaws etc). the exact limit of the CD-RW disc I used while it's rated 74min/650MB, it's actually “74:40:73” (or 74min41sec) and I overburned to “75:55:53” (or 75min56sec). so I think it's probably fairly safe to burn 30sec to 1min or so over the capacity of a typical CD-R etc (and this seemed to be the case given a article I was reading online not long ago now). with that said, I don't overburn audio CD's much but it's nice on the occasion you make a custom audio CD and you go slightly over the 80min limit so instead of removing a song, you can fit a little extra on it and it plays on a old CD player I got from the early 1990's, so compatibility should be pretty good overall. also, I don't know how true it is but some claim slowing burn speed can increase compatibility with some picky CD players. I typically burn at 16x (probably would not need any slower than 8x to 12x from my best guesstimate) when I did some overburning on a audio CD years ago through ImgBurn and it worked on my CD player from early 1990's.

 

but one last thing... I noticed for whatever reason on my main PC, which does not occur on the two other computers I tried, is that the prefix I create with Wine v4.0.4 through PlayOnLinux after things are setup like with shortcut etc that it inflates that specific wine prefix folder from about 61MB to 1.2GB, but this does not occur on my two other computers. but the only obvious difference I noticed is on my main PC I got the system version of Wine installed (from winehq.org etc) where as the two other computers I tested only have PlayOnLinux installed with no system installed Wine. so my best guess is that has something to do with it. but I got a work-around on my main PC to dodge wasting that extra space and seems to have no negative effect on ImgBurn running is that after I use PlayOnLinux to setup a prefix to use with ImgBurn, and I install ImgBurn through the 'Configuration' screen etc, at this point the prefix folder is still about 61MB. so what I did was backup that folder first, then ran the shortcut creation, which is when the folder inflates to 1.2GB and after that was done, I simply deleted the 'windows' folder (which is where all of the file inflation occurred) and restored it from the 61MB backup and notice no negative effects with running ImgBurn (since it's now basically back to how the other two computers I tested PlayOnLinux are straight up). but for someone who does not have the standard system installed Wine and just uses PlayOnLinux, I suspect you won't have this issue and can just do things like you would normally expect.

 

p.s. I still suggest using '6.13-staging' (which takes up about 915MB after basic Wine prefix creation (but does not inflate any further like it did on my main PC for Wine v4.0.4)) for Foobar2000 though as that works slightly better than many others I tried in the sense when you say got a music file in Foobar2000 and hover the mouse pointer over the music track for a second or so, it shows that little small popup from hovering mouse, well when right clicking during that, with 6.13-staging I noticed it works as expected and registers the right click function. but when you do that with many other versions of Wine I used, it simply won't register the right click when that small little popup from hovering mouse is shown. this is not a big deal though, but it's nice that it functions properly on '6.13-staging' where as without that I have to react a bit quicker to get my right click in before the small little popup occurs from hovering mouse. so it's only a small inconvenience without it, as it's not a show stopper, but since that version works like it should, I tend to stick with that instead.

Edited March 14, 2022 by ThaCrip

[JustGeorge]

Does just having WINE installed leave you vulnerable to Windows viri? I've read/heard this in more than one place, but not the technicalities behind it.  I would think it would only apply when attempting to run a Windows application but I'm ignorant so....

[Mindovermaster Moderator]

On 13/03/2022 at 20:04, JustGeorge said:

Does just having WINE installed leave you vulnerable to Windows viri? I've read/heard this in more than one place, but not the technicalities behind it.  I would think it would only apply when attempting to run a Windows application but I'm ignorant so....

No it wouldn't, it just runs Windows progreams, like in its own shell. It can not hit any system files.

[ThaCrip]

On 13/03/2022 at 21:04, JustGeorge said:

Does just having WINE installed leave you vulnerable to Windows viri? I've read/heard this in more than one place, but not the technicalities behind it.  I would think it would only apply when attempting to run a Windows application but I'm ignorant so....

While I can't really give you any major level of detail, since I am no expert, I can probably say a little. bit but it's probably nothing new from what many others would say some variation of...

 

well I think it's pretty safe to say that if Wine is installed, for there to be a chance of infection, your pretty much going to have to run something through Wine as just using standard Linux programs will still be under the general Linux security standards which should be, at the least, high enough to where it's very unlikely your going to get a virus (especially if you keep browser up to date etc). so basically just having Wine sitting there installed, but not being used/running, probably ain't going to matter much.

 

hell, just given that many say you don't even need a anti-virus on Linux speaks volumes. I think even if for no other reason, Linux only has about 2% of the entire desktop market (Windows on the other hand is running on about 8 out of 10 computers, as it's the clear dominate desktop OS) so it's not exactly a appealing target for shady people and that alone keeps your security pretty high right off the start (so even if Wine is vulnerable to Windows viruses on some level, it's probably not at 'Windows level risk' for your typical virus is my best guesstimate) . plus, those shady people probably know that a average Linux desktop user is more tech savvy than a average Windows user, which would make it that much less appealing to them etc.

 

but to speculate (as I can't say this for sure)... do I think there could be 'some' Windows viruses that can do some level of damage to a Linux system running Wine? ; yes, but I suspect it's not common to find these and if there is not any obvious issues with it damaging ones files or data theft level, it's probably not that big of a deal. my guess is even under Wine, the risk of viruses is more towards low than high as a guideline.

 

either way, at the very least... regardless of ones OS I just tend to treat installing or running programs with a little caution, which should further lower the already probably low risk. because as a general rule, regardless of ones OS, only run programs you pretty much trust and be cautious of stuff online and the odds are clearly in your favor

 

with all of that said... if one is more of that hard-line security mindset, then yeah, having Wine installed would lower ones security to a degree. but overall I am not worried about it since I only run pretty much two Windows programs (Foobar2000/ImgBurn (both through PlayOnLinux lately even though I used to run them on the system installed Wine)) and a limited amount of games through Wine/Lutris (paired with GloriusEggroll's custom stuff for Lutris) combo (on standard system installed Wine).

 

but if someone uses say PlayOnLinux with no system installed Wine, that basically makes it so when someone downloads a .exe file and tries to run it, it simply won't do anything because it simply won't execute. because I know installing the newest Wine from the winehq.org website makes it so that when you click a .exe through the file manager it proceeds to load up. but if you go by what the Linux Mint team recommends for installing Wine, by simply issuing  'apt install wine-installer' from terminal (as shown here in their release notes (Mint v20.3-Xfce, but is the same on Mint in general basically)... https://www.linuxmint.com/rel_una_xfce.php ), I think it installs Wine v5 (on Mint v20.x series (I think Mint v19.x series installs Wine v4)) and does not automatically run .exe files by clicking on them through the file manager. so assuming that's true, one would have to run the .exe through the terminal for it to install... "wine /location/to/exe/file.exe". then even here, short of a virus somehow infecting other files on the system, it's generally going to be contained in the ".wine" folder in ones Home directory (which is the default location for the standard system install of Wine when you install programs) even though I think it's possible for stuff to escape it if the virus happens to run well through Wine (which it may not).

 

 

On 13/03/2022 at 23:59, Mindovermaster said:

No it wouldn't, it just runs Windows progreams, like in its own shell. It can not hit any system files.

 

While I don't know the details either, just off the top of my head, since Wine does not run as root, even if there is some level of infection (which I imagine risk is probably on the lower side, especially with most viruses(?)) it's probably going to be limited and won't touch anything that requires 'sudo' to access since Wine does not run with admin access. even looking around online for 'linux wine virus' does not really seem to have any clear cut answer and one article I was reading, although it's old now as it's from 2005, was running some Windows viruses on purpose under Wine and, in short, the damage was low enough not to really matter all that much as some did not really work and while some worked a bit better than others, it still never got to their intended effect like they do on Windows and basically closing out of Wine shut them down and clearing the '.wine' folder and re-creating it would basically have wiped out everything it did, at least on that particular persons test it seemed.

 

=================================

 

so I guess with all of that said... "can Windows viruses effect Linux Wine users?" ; I suspect that's probably a 'yes and no' answer as there is probably no clear cut simple answer to that question from what I can tell looking around online. so overall I would not worry too much, but at the same time exercise general caution about installing things you don't pretty much trust as this should apply regardless of the OS your using as if your more on the cautious side of things, that alone can keep your chances of a virus or the like at a minimum, even on Windows. like not only with exe stuff but with entering sensitive info into your browser as I would just assume any emails asking you to sign-in to a site are shady and, even if you believe they might be legit, just manually go to the website in question (assuming it's a legitimate website to begin with, obviously, otherwise I would just ignore it outright) instead of clicking a link in a email. because this way even if that link is shady or not, it won't effect you.

 

EDIT: here the official Wine website talks about malware a bit... https://wiki.winehq.org/FAQ ; under the "7.4" section.

Edited March 14, 2022 by ThaCrip

[ThaCrip]

In regards to my ImgBurn stuff... in short, I now suggest sticking with Wine v6.0.1 overall due to a potential Direct Show issue with a modified WAV file on versions of Wine prior to v5 series (see below for more info).

 

after playing with ImgBurn some more I noticed after editing a WAV file (I trimmed some silence from the beginning and end of a couple of songs which helped to keep my overburned audio CD to be a little shorter (a bit under 81min)) with Audacity (or Ocenaudio) (using... https://forum.audacityteam.org/viewtopic.php?t=99503#p345303  ; which keeps the audio lossless) that versions of Wine prior to the v5 series will error when burning a standard audio CD as it can't read the trimmed WAV files. but it appears the issue is not with ImgBurn but is with 'Direct Show' since apparently ImgBurn uses Direct Show to read the WAV files for burning to a standard audio CD. so it's basically a Wine issue, but can be fixed simply by using a newer version of Wine (i.e. v5 series or newer, I suggest v6.0.1 as it's what I am using currently).

 

but with that said... I suspect this won't be of help for many given the situation is not likely to occur since not many still burn audio CD's and those who do probably won't be using Linux and even if someone does burn audio CD's and is using Linux, probably ain't going to be using Audacity to trim the silence from some WAV files.

 

on a side note... KProbe works on Wine to which is nice for Lite-On DVD burners to check the quality state of burned DVD media. you just set read speed to 4x and, from what I remember in the old days, you generally don't want more than a PIF spike of 3 for optimal quality and PI are probably around 10 or less, but PIF's are more important. but even if you go a bit worse than these standards, your still almost surely well within a quality burn. but checking a handful of discs recently that are 12+, 14+ and 16+ years old and all turned out well. which I figure if DVD recordable media has lasted this long without any obvious degradation signs, chances are it will last for the foreseeable future. basically I think putting aside usual hard drive backup, quality DVD media (Verbatim/TY (Taiyo Yuden)) is still the best alternative for long term data storage, especially if you don't have a lot of data to burn. because if you got a lot of data then it's probably not practical to use DVD media (at which point hard drive backup is probably all-around best). but I typically use DVD media for high importance data backup (like a copy on each brand of disc) along with data on a couple of different hard drives.

 

p.s. also, one can use the x86 (32bit) versions of Wine with PlayOnLinux since they take up less storage space.

Edited March 29, 2022 by ThaCrip

[ThaCrip]

I upgraded to Mint 21.0-Xfce not long ago now, well I did a clean install even though the option to Upgrade from 20.3 to 21.0 is now available, and pretty much everything is about what I would expect.

 

but a couple of things I noticed so far that's a bit off on Mint 21.x vs Mint 20.x (one of the two (#2 below) will be fixed probably in Jan 2023 if the pattern holds)...

 

1)a small quirk I noticed that's better on Mint 20.x vs Mint 21.x is PlayOnLinux's 'Configuration' (and the like) windows are too small so you can't see everything on certain menu's and have to manually move mouse pointer to say the bottom of the open window and drag it down (which expands it so you can now see everything that you should be able to see, but you got to do this everytime you load that screen etc) so then you can see all of the stuff listed which is not a issue on Mint 20.x as it displays as it should on there. but this is not a show stopper though as the basic function still works as expected as far as I can tell so far. but I can see how someone a bit less familiar with computers would find that to be a issue.

 

2)at least currently one cannot install the 'stable' version of Wine on Mint 21 since there has been no stable release for Ubuntu 22.04 (which is what Mint 21 is based on) so you got to use either 'development' or 'staging' versions of Wine instead in regards to installing Wine from the official Wine website (although if you opt for the 'recommended' way the Mint team suggests installing Wine (i.e. apt install wine-installer) then things will be okay but you will be on a bit older version of Wine). I am currently using the 'development' version which is "wine-7.14" where as the 'stable' Wine is 7.0. but if the past is a rough indication of the stable release we probably won't see a stable version for Mint 21 (Ubuntu 22.04) until about Jan 2023.

 

also, when installing Wine through the official Wine website (i.e. https://wiki.winehq.org/Ubuntu ), there is one command they omit which is a good idea to use if you want proper Wine entries on your start menu for easier access... "sudo apt install wine-desktop-files" (I run this after installing Wine on the system through official Wine website) as this gives you the usual main 'Wine' entry on your start menu with four entries in the sub-menu (i.e. Browse C Drive/Configure Wine/Notepad/Uninstall Wine Software). NOTE: just after installation if you try to run 'Browse C Drive' it will error because there is no "~/.wine" folder yet as to create that you just run the 'Configure Wine' (or 'winecfg' from terminal) first and then if you try running 'Browse C Drive' it will then work as expected. but all that 'Browse C Drive' does is guide you to "~/.wine/dosdevices/c:" (or ~/.wine/drive_c) which then things are basically laid out like the typical Windows structure.

 

but personally I use PlayOnLinux for the handful of programs I use and keep the system installed Wine for the small amount of video games I play/replay. so basically the system install Wine stores it's general configuration etc in ones Home folder under "~/.wine" where as the PlayOnLinux stuff is stored "~/.PlayOnLinux/wineprefix/*NameOfWinePrefixHere*" (or more easily accessed with the shortcut PlayOnLinux creates in ones Home folder called "PlayOnLinux's virtual drives"). I prefer this as it keeps things separated from each other.