[SOLVED]Mint v20 | hard drives not shown in file manager after clean installation...

[ThaCrip]

I noticed during a clean installation (i.e. 'Erase disk and install Linux Mint') of Mint v20-Cinnamon that my additional hard drives are shown from the live desktop boot device, like expected, but after clean installation of the OS and after a rebooting, the hard drives are not shown in the file manager and I have these two folders/icons on desktop that say 'efi' and 'Filesystem root' (which can't be removed from the looks of things), which should not be there and normally are not when things install/function normally. but I noticed the 'lsblk' terminal command does see the that my additional hard drives connected (which are all EXT4 formatted). even plugging in USB thumb drives don't show up and are not accessible through the file manager like is normally expected (but 'lsblk' sees this to).

I even tried this... I disconnected the SATA cables from my additional hard drives so that only the SSD was connected (which is where the Mint v20 OS goes) and this installs fine and after reboot, the OS appears okay and things seem to work as expected as I connect a USB thumb drive and can access it like usual through file manager. but then I power the system off, reconnect my three hard drives SATA cables, and boot back up and things are back to the problem I described above with the efi/filesystem root stuff and hard drives are not shown in the file manager (but 'lsblk' see's them).

even Mint v20-Xfce reacts similarly, except during initial live boot it does not see the hard drives like Cinnamon does.

NOTE: I installed the OS from a USB card reader from a 4GB SD card (I used the 'USB Image Writer' within Mint v19.3 to make the bootable Mint v20 install from ISO). I even tried a DVD+RW disc (with 'xfburn' (I even briefly tried another burning app but I can't recall it's name with same result basically)) and that reacts basically the same. I even ran the integrity check to confirm everything was error free. I even checked the SHA256 hash of the ISO's and GPG stuff to. NOTE: speaking of DVD+RW, on my backup computer(laptop), Mint v20, with xfburn, won't even burn a disc as it throws a "Burn mode is not currently implemented" error. but doing that same stuff on Mint v19.3 works perfectly.

so assuming Mint v20 is shot on my desktop computer, is there any chance this (and the other issues) can be fixed for Mint v20.1? ; any thoughts/suggestions? ; because this is obviously a major/show stopper issue as after a clean install the Mint v20 OS not being able to access basic hard drive function through the file manager is a show stopper issue. I might try upgrading to Mint v20 once the official upgrade instructions are available and see what happens there(?).

p.s. luckily I made a Clonezilla image of my Mint v19.3-Cinnamon installation prior to attempting the clean install of Mint v20. it saved me as I am currently back on my Mint v19.3-Cinnamon installation (with v4.15 kernel) so it's like I never attempted the Mint v20 clean install in the first place and everything works great. one last thing... I am not 100% sure on this but it does seem like bootup times are slower on Mint v20 with 5.4 kernel vs Mint v19.3 with 4.15 kernel.

EDIT: ill add that when booting from the USB card reader with SD card, it does not seem to matter whether I select more of a standard boot or UEFI boot option as the results end up being the same.

----------------------------------------------------------------------------

on a side note... another question, is there any reason why grub don't default to installing to the drive you install Mint to? (this seems to be on Mint 19 and Mint 20) ; because I noticed that by default (I got one SSD and three HDD's) when clean installing Mint on my main PC it seems to automatically select one of the other hard drives to install grub to instead of putting it all on the install drive like I assume it should.

but I think I have found a work around... 'Erase disk and install Linux Mint', then select 'continue', then select hard drive, then select 'advanced partitioning tool', then 'Device for bootloader installation:' switch it to the HDD/SSD you want to use(which I put it the same as where I want to clean install Mint to), then click 'back', then 'install now' and it proceeds with installation. but it seems like I would not have to adjust the 'advanced partitioning section' at all as one would think it would default to the SSD/HDD you select to install the OS to but in my case it does not and seems to auto-select one of my hard drives which I don't want.

EDIT: see my last post for more info. basically I did not really solve anything but for whatever reason the bug is no longer there. my best guess is clearing BIOS and unplugging computer for a while may have fixed it(?)

[arvy]

but I think I have found a work around... 'Erase disk and install Linux Mint', then select 'continue', then select hard drive, then select 'advanced partitioning tool', then 'Device for bootloader installation:' switch it to the HDD/SSD you want to use(which I put it the same as where I want to clean install Mint to), then click 'back', then 'install now' and it proceeds with installation. but it seems like I would not have to adjust the 'advanced partitioning section' at all as one would think it would default to the SSD/HDD you select to install the OS to but in my case it does not and seems to auto-select one of my hard drives which I don't want.

Which boot mode: "legacy" or UEFI? For the latter, the installer will always put the Grub boot loader into the first EFI System Partition (ESP) that it finds with a boot flag, even if you do tell it to install the boot loader to some other ESP. As for those other symptoms, some kind of /etc/fstab confusion would be my first suspect for at least some of them.

[ThaCrip]

@ arvy

Which boot mode: "legacy" or UEFI? For the latter, the installer will always put the Grub boot loader into the first EFI System Partition (ESP) that it finds with a boot flag, even if you do tell it to install the boot loader to some other ESP.

when booting from SD card reader with a 4GB SD card in it to install mint I can choose standard boot or UEFI as it does not seem to matter which one I choose the results are basically the same to where my hard drives are not visible under Mint v20 file manager after the OS installs and I reboot the system.

and like I say... with all other hard drives completely disconnected before installing Mint v20 and I reboot after the installation, things are okay as I can connect a simple USB stick and it works as expected in file manager. but as soon as I power down computer, re-connect the SATA cables to the three hard drives I got and boot up, the major issue occurs as the hard drives are not shown at all in the file manager and I got those weird 'efi' and 'Filesystem root' icons on the desktop which should not be there and like I said before, even connecting a basic USB thumb drive is not even visible in the file manager either.

as far as looking through my BIOS on the 'boot' tab, about the only thing I see that's worth mentioning...'PCI ROM Priority' and it's defaulted to 'Legacy ROM' but I can change that to 'EFI Compatible ROM' if that matters? ; in the BIOS basic message in relation to that, says, and I quote... "In case of multiple option ROMs (Legacy and EFI compatible). specifies what PCI option ROM to launch"

p.s. looking at my HDD's with GParted, none have the 'boot' flag besides the SSD.

"As for those other symptoms, some kind of /etc/fstab confusion would be my first suspect for at least some of them."

but this is a clean install (wiped the drive and installed Mint v20 from scratch) as I would assume Mint v20 would not have any weird conflicts here, correct? ; since it's a basic configuration from scratch as I did not touch anything. because Mint v19.x series worked perfectly okay.

p.s. even a moment ago on Mint v19.3-Cinnamon, just to see what would happen, I loaded up the newest 5.4 kernel and rebooted and everything seems okay so far. so the 5.4 kernel, which is what Mint v20 uses, seems okay on my Mint v19.3-Cinnamon installation.

[arvy]

Does your system's UEFI configuration have the SATA controller set to AHCI mode? If set to any RAID or Intel Optane mode, that ain't gonna work well with a Mint installation, nor with almost any other Linux distro for that matter.

[ThaCrip]

@arvy

Yes, it's AHCI mode which I heard we want to use for SATA and no, I am not using RAID or anything else. it's been this way for a long time before I installed Mint v19 on it and Mint v19.x works perfect. so I would assume there is some sort of bug tied to Mint v20 but I have no idea what it is. maybe Ubuntu 20.04 base etc?

because I can run the 5.4 kernel on Mint 19.3-Cinnamon without issue (although I went back to 4.15 since it's LTS) and that's what Mint v20 is using. so maybe it's some sort of bug in Mint v20 or Ubuntu 20.04 base(?).

[ThaCrip]

Anyone else have any suggestions/fixes? ; as USB thumb drives (and general USB devices) and my additional hard drives are not shown in the file manager like typically expected even though 'lsblk' does see the hard drives.

because recently, just to confirm, I backed up my current Mint v19.3-Cinnamon install with Clonezilla then using the same device I used to clean install Mint v20-Cinnamon (i.e. a USB card reader with a 4GB SD card in it (I made the bootable media using Mint's 'USB Image Writer')), I put Mint v19.3-Cinnamon on it and did a proper clean install using UEFI and regular MBR (like at bios screen I press F8 which brings up BIOS's boot menu and from here you can select whether to boot UEFI or standard) and both of those work perfect as my hard drives show up fine in file manager and inserting a USB works as expected. but doing that same thing with Mint v20-Cinnamon, file manager does not see the hard drives even though, like I was saying the 'lsblk' command see's them and it has 'efi' and 'Filesystem root' folders on the desktop and in file manager under the 'Devices' section which should not be there. I think when I did the standard regular BIOS install, things reacted similarly but instead of the 'efi' and 'Filesytem root' folders being on desktop and in file manager, it was just 'Filesystem root' but the general bug remains the same in that my additional hard drives are not shown and connecting basic USB stick (and other USB devices) don't show up as expected in the file manager, but 'lsblk' see's them. so it must be some bug in Mint v20 not in v19.x series.

assuming no one has a fix for it now, is there a good chance it will be fixed by the time Mint v20.1 is released roughly 6 months from now?

but assuming no one has a fix, ill probably try upgrading to Mint v20 from my current v19.3-Cinnamon install and see if that fairs any better. if that fails and Mint v20.1 is no better, I assume my only hope is to use Mint v19.3 and wait until Mint v21 is released roughly a couple of years from now and hope that one works.

[arvy]

The biggest problem (for me at least) is trying to unscramble your narrative -- i.e.:
1) when are you talking about what happens while booted to the Mint "live" installer session,
2) when are you talking about the results of booting to the completed Mint installation,
3) how does any of it relate to your OP "side note" about putting Grub where you wanted it to be, and
4) what system boot mode configuration is involved for each of the above, or are you just switching boot modes at random? (You keep saying it doesn't matter which is true up to a point, but consistency matters very much.)

I suppose the only logical conclusion one can possibly derive from the information as stated thus far is that, if two Mint ISO downloads that were burned in the same way to the same installation media are producing different results, it's quite possible that the unwanted results may be due to one of them being a bad download. Try re-downloading and re-verifying the LM 20 ISO.

[ThaCrip]

@arvy

I suppose the only logical conclusion one can possibly derive from the information as stated thus far is that, if two Mint ISO downloads that were burned in the same way to the same installation media are producing different results, it's quite possible that the unwanted results may be due to one of them being a bad download. Try re-downloading and re-verifying the LM 20 ISO.

That's correct I used the same install process for both Mint v19.3 and Mint v20, but... I verified the ISO SHA256 hash and GPG and even on the built-in data integrity check once you boot to it passes with no errors. so from this perspective everything is 100% okay. even during the installation processes I tried recently, I did both v19.3-Cinnamon install and Mint v20-Cinnamon install exactly the same on UEFI and a standard boot install and v19.3 works perfect where as Mint v20 has the problem (like it does not seem to matter what I try, Mint v20 always ends in it not seeing my HDD's etc in file manager where as Mint v19.3 always works). both UEFI and standard fails on Mint v20, Mint 19.3 works as expected.

even a moment ago running a SHA256 hash check on Mint v20 Cinnamon ISO comes out to... "2f6ae466ec9b7c6255e997b82f162ae88bfe640a8df16d3e2f495b6281120af9" which matches the one on the official site as I just checked again a moment ago.

p.s. one last thing... would it be worth trying to boot the live media in 'compatibility mode' instead of normal? ; because it gives this option shortly after boot to the live media.

1) when are you talking about what happens while booted to the Mint "live" installer session

Strictly in terms of the 'live session' on Mint v20 (which I just tested the following two times each and it was consistent)...

-UEFI boot (as in I boot from the Mint v20 live media using UEFI) = it see's my hard drives like expected in file manager and there is no 'efi' or 'filesystem root' folders on the desktop. so everything looks normal at this point. but after installation and reboot, things are out of whack with file manager not seeing my hard drives and USB sticks react the same and with the weird 'efi' and 'Filesystem root' folders on desktop and on the 'Devices' section in the file manager, which is not normal.

-Standard boot (as in I standard boot (NOT UEFI) from the Mint v20 live media) = it does not work properly in that you can see 'Filesystem root' and 'tmp' folders on the desktop and those are the only ones that show in the file manager under 'devices', which is not normal. but proceeding to install at this point, upon reboot the end result is the same... file manager does not see my hard drives or USB stick etc.

NOTE: if this matters my current installation is Mint v19.3 which is using 'msdos'(so it's NOT GPT) on the SSD and is using standard boot as there is no EFI folder in the "/sys/firmware/". but once I did install Mint v20 not all that long ago (a day or two ago or so) testing things, there is a EFI folder as it was using UEFI. so I know when I am doing both installs with UEFI, that UEFI is working, and a standard MBR boot is working to but after the OS is installed to the SSD in it's typical usable state, I have the problem I am having with it not seeing my hard drives and USB stick etc. I even tried GPT on the SSD along with UEFI, which I would imagine is optimal for the UEFI setup, and things are basically the same.

2) when are you talking about the results of booting to the completed Mint installation

Basically in Mint v20's final installed/usable state, my hard drives and USB stick etc is not seen in the file manager like is normally expected but 'lsblk' does see the hard drives. also, I see 'efi' and 'filesystem root' folders on the desktop and they appear in file manager under 'Devices' and that's it (even though I got three other hard drives connected which normally show in that 'Devices' section and the 'efi' and 'filesystem root' should not be there). doing the same install processes on Mint v19.3, everything works as expected.

thanks for your time

[arvy]

You just can't seem to resist mixing up different situations together which makes it very difficult for anyone remote from the actual sequence of events to arrive at a logical analysis and conclusions. Even when you say "strictly in terms of the 'live session' on Mint v20" you then go on about what happens "after installation and reboot." Anyhow, I think I've managed to infer correctly that there are no problems whatsoever with the LM 20 installation media, nor with booting to the LM 20 "live" session in either boot mode, nor with the LM 20 "live" session itself, nor with the file manager within the LM 20 "live" session. If that is so, then there is no need or reason for "compatibilty" launching the "live" session when it works just fine "normally" launched.

In the circumstances, it would also seem apparent that problems with your LM 20 installation must arise from some aspect of the installation procedure itself. And that must inevitably lead back to my earlier questions about the boot mode used and about your "side note" on putting the boot loader where you wanted to put it. Seems to me very much as if you yourself are likely responsible for "the weird 'efi'" being where it shouldn't be, especially since you say that your Mint v19.3 installation is set up for what you call "standard" (i.e., "legacy" BIOS-MBR CSM) booting. If you booted the LM 20 installation media that same way, there is no reason why you should see "weird efi" anywhere, let alone on your desktop. Please outline (brief point form if possible) the exact steps that you took when installing LM 20, including the boot mode used for that one "live" session and your "side trip", in precise chronological sequence please.

My tentative conclusion, subject to confirmation, would be that you need to start over installing LM 20 using the same boot mode (what you call "standard") for its installation media as was apparently used to install the existing LM 19.3 installation.

[ThaCrip]

@arvy

Sorry, ill try to make things easier to understand. but this should make it nice and easy to understand with much less words...

1)I used Mint v19.3-Cinnamon's 'USB Image Writer' to write the Mint v20-Cinnamon ISO to the 4GB SD card connected to USB card reader.

2)Reboot computer and upon computers BIOS screen I press F8 and select the media from 'Step 1'(above) so it boots in UEFI mode. everything appears completely normal at this point as the Mint v20 'live media' loads up to the desktop and my hard drives are visible in the file manager. so everything is perfectly normal so far.

3)What you see here in this 5 min YouTube video (i.e. https://www.youtube.com/watch?v=FPJk3PaFpa0 ) is basically what I did minus the "/home" and 'swap' stuff. so I just have it all on the "/". NOTE: I assume this is perfectly normal and should not cause any issues? ; because doing that works perfect on clean install of Mint v19.3, but not Mint v20.

4)After installation completes, I reboot computer (so Mint v20 is now running from my SSD) and my problem appears (i.e. no hard drives, or USB sticks, visible in file manager and 'efi' and 'filesystem root' appears on desktop and under 'Devices' in file manager which should not be there. but 'lsblk' shows that my hard drives and even USB drive is connected)

that should make things much easier to understand ; any suggestions?

NOTE: if I use those same four steps above using standard BIOS boot instead of UEFI to the live media, there is already a issue on Step 2 in that once I boot the live media, I already have a problem with 'tmp' and 'filesystem root' on desktop and under 'Devices' in file manager and my hard drives are not visible (like nothing is visible to the file manager besides 'tmp' / 'filesystem root' and the like). plus, the YouTube video process is a little different since when booting in standard BIOS mode one can't create a 'EFI Partition System' like shown in the video which I assume is normal since UEFI is not available when using a standard BIOS boot.

My tentative conclusion, subject to confirmation, would be that you need to start over installing LM 20 using the same boot mode (what you call "standard") for its installation media as was apparently used to install the existing LM 19.3 installation.

That's the thing... I do use the exact same process to install Mint v20 that I used on Mint v19.3, but Mint 20 has the file manager issues etc where as Mint v19.3 does not and works perfectly fine after the OS is installed to the SSD(the main boot drive). I can boot using standard BIOS or UEFI on Mint v19.3 and it always works no matter which installation method I use. but no matter what I try on Mint v20 (using same method(s) I used on Mint v19.3), the file manager problem appears once the OS is installed and ready to use.

[arvy]

Okay, I'll keep this short. Your Mint 19.3 installation was installed on a drive with a Master Boot Record (MBR) and "msdos" partitioning for booting by your system in "legacy" (what you call "standard") mode. You've been trying to install Mint 20 for booting in UEFI mode which requires a GPT drive with an EFI System Partition (ESP). So you can either (1) boot the installation media in "legacy" (a.k.a. "standard") mode so that Mint 20 is installed the same way Mint 19.3 was installed, or (2) you can reconfigure your system and reformat the target drive with a GUID Partition Table and an EFI System Partition so that Mint 20 can be installed for UEFI-GPT booting. In either case, instructions to the installer for Grub boot loader installation specify only the drive, not a partition.

[ThaCrip]

@arvy

Your Mint 19.3 installation was installed on a drive with a Master Boot Record (MBR) and "msdos" partitioning for booting by your system in "legacy" (what you call "standard") mode.

but I have already done this before. it has no effect. the bug remains in Mint v20.

Mint 19.3 works, Mint v20 does not.

You've been trying to install Mint 20 for booting in UEFI mode which requires a GPT drive with an EFI System Partition (ESP).

I have already tried that to. it has no effect. the bug remains in Mint v20.

basically I tried "GPT + UEFI" and "MBR(msdos)+standard boot" and both ultimately react basically the same after installation.

p.s. but I know it's using UEFI because of the "/sys/firmware/" folder listing a 'EFI' folder there as if there is no EFI folder from what I read it's using standard boot.

In either case, instructions to the installer for Grub boot loader installation specify only the drive, not a partition.

but I kind of assume, given that YouTube video, that it automatically sets things up properly with boot stuff on that 512MB partition(?). I would imagine so since Mint v19.3 has zero issues unlike Mint v20 which consistently acts up no matter what I try.

so with all of that said, any other suggestions?

p.s. there is at least one other person who experienced a similar issue to myself... viewtopic.php?f=50&t=323910 ; he specifically mentioned "I cannot access my memory stick, it is not being displayed on the file manager." ; which is part of my issue along with HDD's not being shown in file manager either. but like I mentioned before... if I clean install Mint v20 with all of my other hard drives disconnected besides the main SSD boot drive, and reboot, I can connect a USB thumb drive and it works as expected. but as soon as I power down, reconnect the three other hard drives I got to the SATA cables connected to the motherboard like usual, power up, I immediately have the 'efi' / 'filesystem root' problem and nothing is shown in file manager.

[ThaCrip]

Well I attempted the Mint v20 upgrade hours ago, the upgrade completed, but the problem remains as even though my hard drives are mounted, it's due to my previous manual use of UUID to mount them to a specific location etc (i.e. /etc/fstab). but basically USB sticks are not automatically mounted so the issue remains and I see 'Filesystem root' under 'Devices' which was not there previously (even if this is a new addition to Mint v20 that was not there in Mint v19, that still does not explain how my hard drive/usb sticks are not visible in the file manager).

so in other words... ill have to see what happens by the time Mint v20.1 is released roughly 6 months from now as I figure if it's still out of whack by then, chances are it won't be fixed in the Mint v20.x series and ill have to wait and see if Mint v21 is any better. but if that fails, then I pretty much won't have any choice and will have to consider alternatives because by then Mint v19.x series will lose support not all that long after Mint v21 is released. but assuming all of that happens to where the mainline Mint version continues not to like my PC (with seeing hard drives/usb stick in file manager), I am hoping Mint's alternative release, LMDE, will work. which is why I might test that out soon just to see how it works on my computer and while I am at it I can get a proper 'GPT + UEFI' setup to as I was playing with it in a virtual machine recently and I suspect it will probably be a good alternative to the mainline Mint should I have to use it.

so unless someone has some suggestions, what I said above looks like my only real choices currently.

[arvy]

Very sorry about your continuing problems and also sorry that I couldn't be more helpful, but those two installation alternatives are the only ones I know about. And the fact that any attempt to mix them "half-and-half", so to speak, just doesn't work very well in my own experience. If, as you say, you've tried each system configuration and installation boot mode carefully and independently of the other, and neither works properly for you, I can only agree that you've reached an impasse. It's a highly unusual, if not unique, situation for which, regretfully, I can think of nothing else to suggest.

[ThaCrip]

@arvy

Very sorry about your continuing problems and also sorry that I couldn't be more helpful, but those two installation alternatives are the only ones I know about.

At the very least... I got to thank you for your time/patience with your attempted help

If, as you say, you've tried each system configuration and installation boot mode carefully and independently of the other, and neither works properly for you, I can only agree that you've reached an impasse. It's a highly unusual, if not unique, situation for which, regretfully, I can think of nothing else to suggest.

Given my previous post it appears at least one other person is likely experiencing what I am (i.e. viewtopic.php?f=50&t=323910 ). so it's not like I am the sole person with this bug (although I would imagine what I am experiencing is more on the rare side, or at least uncommon). but I imagine this would be hard to narrow down? ; because I would not mind assisting someone a bit (within reason) to help narrow down the bug.

also, I am pretty sure what I did is standard/proper installations for each boot method...

1)Standard boot(BIOS) (like to Mint v20 live media) + MBR(msdos) on SSD.
or...
2)UEFI boot (like to Mint v20 live media) + GPT on SSD. plus, I confirmed that UEFI must be in use after OS installation given the "/sys/firmware" folder contains a 'efi' folder which from reading online says that won't be there if your using standard BIOS.

both of those work perfectly okay on Mint v19.3 where as Mint v20 has the file manager issue with additional HDD's and USB sticks not showing up as they should.

but I suspect ill try LMDE 4 soon if not for anything else just to see how it works out with the usual 'UEFI + GPT' and if the basic file manager can see my additional hard drives and USB stick(s) after installation. but if/when I do, ill probably come back in this topic and report my results.

p.s. for those who may wish to know more details on my motherboard... my exact motherboard is a 'ASUS P8H61-M LX Plus' and I am running the newest firmware v4601 which is from May 2014. so my computer has some age on it, but it's not exactly ancient either (as it's more fast than slow) as I had the basic motherboard since May 2012. I would guess the motherboard itself is probably around mid-to-late 2011.

[ThaCrip]

Well earlier this year I got a hold of a Marvell 9215 controller card (i.e. https://www.amazon.com/IO-Crest-Control ... 00AZ9T3OU/ ) so I could use my two optical drives since all four of my motherboards SATA II port were full, but this was after my Mint v20 issues explained above which at that time I was solely using my motherboards SATA II ports with my SSD and HDD's. so recently I decided to try out the Mint v20.1 Cinnamon BETA and it installed fine (using UEFI+GPT(I did not test BIOS mode but I doubt it will be any different)) without the HDD/USB thumb drive issue. so I was thinking Mint 20.1 actually fixed the bug at this point.

but just to be sure... I decided to try installing the Mint v20 release from earlier this year (the one I had the bug with as explained in my above post) and even that installed fine as hard drives are visible in the file manager like usual along with inserting a USB thumb drive shows up in file manager like expected to, which basically tells me that whatever the bug was no longer appears when using that Marvell controller card.

so about the only thing I can still test is how Mint v20.1 Cinnamon BETA would install (like if the issue would reappear upon a clean install of the OS) if I don't have anything connected to the Marvell 9215 card and only use my on-board SATA ports as that would help further confirm that nothing was fixed in Mint v20.1 regarding this issue (like if the bug shows up on Mint v20.1 beta when I am only using onboard SATA II ports then it would appear nothing was fixed from Mint v20 to Mint v20.1 beta release). but I have not directly tested that much. but given the above info, it seems most likely that the issue would still be there, and that the Marvell 9215 controller card is a work-around for it so that the issue does not turn up after a clean install of the OS and that I probably won't bother to do this last test unless someone thinks otherwise(?).

so I guess, at least given my current setup, I can now shift over from Mint v19.3 Cinnamon to Mint v20.1 Cinnamon once it's released soon as that HDD/USB thumb drive issue was a show stopper (which is why I had to stay on Mint v19.3) that no longer appears to be there when using that Marvell 9215 controller card and my issue is fixed but it does not appear that Mint v20.1 fixed it, but the controller card causing the bug not to trigger.

so I guess, at the very least, if someone is experiencing a issue similar to myself, it's possible a different SATA controller card could fix your issue as it appears to be the case for me.

NOTE: I am NOT using RAID, just a standard SATA connection.

p.s. I doubt this would matter, but I have been using Ventoy ( ventoy.net ; basically a easy-to-use multiboot USB thumb drive as you simply copy over the ISO file to the USB stick, boot to it in BIOS or UEFI mode, and then select the ISO and proceed to install like usual) recently to install Mint etc which I did not use during my Mint v20 install earlier this year.

[ThaCrip]

Well, in short, everyone can ignore this entire topic now as the bug no longer appears to exist on my PC.

because a moment ago I was trying to get the bug to trigger using the same exact ISO (i.e. linuxmint-20-cinnamon-64bit.iso ) I used back when I consistently had the issue as shown in my above posts but I could not get the bug to trigger as I thought the Marvell 9215 card had something to do with it, but I even completely removed that controller card from the PCI-E slot and then connected a couple of my hard drives along with my main SSD boot drive to the motherboards SATA ports (which is pretty much the situation when I had the bug months ago), did a clean install of Mint v20 (the ISO I mentioned above that previously had issues for me and I setup the SSD to GPT with GParted and then did a UEFI install. after install I checked '/sys/firmware/efi' to make sure it was using UEFI mode and it was) and after the OS installed, I rebooted, then I expected to see the bug, but nothing. everything works as expected in the file manager and even connecting a USB thumb drive works as expected now. so it's like the bug never existed now on the same PC that previously would not work regardless of whether I tried BIOS+MBR or UEFI+GPT installs.

my best wild guess (which I could easily be wrong here)... is maybe I had some weird glitch in my BIOS(?) as I believe I cleared the BIOS settings (using jumper on motherboard), reconfigured everything, and even unplugged the computer for a while at some point not all that long ago. who knows, maybe it was some weird configuration in the BIOS that triggered the bug, who knows(?). but the important thing is, all seems to be good now

also, I am using Ventoy (ventoy.net) to install Mint that I was not using earlier this year. but I can't imagine this would matter.

also, my on-board audio died earlier this year (but it was sometime after the Ming v20 bug I was experiencing) but I can't imagine that would cause a bug like I had(?). currently the onboard audio is disabled in the BIOS and I am running one of those USB audio devices for my audio output to my speakers. but it would seem unlikely this would cause my bug that I had that's no longer there.

so thanks again for those who attempted to help me though

p.s. on a side note... I imagine unplugging the power from the wall so the PC is completely unplugged is something people would not even consider. but years ago we had a TV that had some issue, I can't recall what it was off the top of my head, and we thought the TV was shot. but we found out that simply unplugging the TV from the wall socket for a while and then plugging it back in fixed it. you would never guess something THAT easy would fix it, but in that case it did. but I never seen anything like that since.

[ThaCrip]

UPDATE (June 3rd 2021): I just noticed earlier that if I have a old Sony 128MB USB stick inserted into my USB port and reboot, those 'efi' and 'filesystem root' type of stuff appears in the file manager. it's got to be some weird bug as that's the only USB stick I have that acts up like that (it's fine if I plug it in after Mint v20.1-Cinnamon boots up, but if I have it plugged in and boot the system up is when the issue occurs). I even remember having issues booting up a while ago if that same USB stick was inserted into the back of the motherboard's USB port as it seemed to prevent the system from booting etc.

but I just shutdown the computer, removed the Sony 128MB USB stick, powered up and all is back to normal once again. I can even use the USB stick like normal once the system is powered up as the issue only seems to occur if I boot up with the USB stick inserted.

but I imagine finding out what exactly this bug is probably won't be easy, although I thought I would just make a updated post on the off chance someone else has this weird bug.

[Shapiro]

Hi,

even if it's done for you, I just wanna show you and other people, who are stumbling across this thread, a possible workaround.
I experienced the same issue some months ago on Mint and on Ubuntu 20.04 after I did an complete system-update.

After some googling I found similiar posts but no solution:

• On this forum #1
• On this forum #2
• On askubuntu.com #1
• On askubuntu.com #2
• On askubuntu.com #3
• On reddit.com

My solution was to edit grub:

Code: Select all

sudo nano /etc/default/grub

adding acpi=off

Code: Select all

GRUB_CMDLINE_LINUX="acpi=off"

then

Code: Select all

sudo update-grub

and reboot.

I know this is not an optimal solution, 'cause it will disable ACPI completely including things like fan control and power-button-customization. In my case it's only a spare machine, which I rarely use. So no big deal for me. Nevertheless I'm still interested in a proper solution to this bug.