Linux developers are in constant development of drivers and modules and other relevant software and it usually takes a little time for some of these elements to be put into the kernel. This happens with lots of hardware like wifi drivers, M2 arm chips etc, and so it is with storage disks. The reports I've come across so far, including from AI in post #23 suggest that the latest kernels can see this drive. It's just that most distro's installation media at present doesn't have such recent kernels. That's how it appears to me.
Can't detect my nvme SSD on Linux mint edge boot usb
- Thread starter banana789
- Start date
-
- Tags
- begginer linux mint nvme ssd
That's very true, now what to do ...
Brickwizard
Well-Known Member
Just one point kernel 6.5. Reached end of life support 6 months back, best look for something with 6.6 [LTS] release.
Or better still?
The Beta versions for Ubuntu 24.04 'Noble Numbat' are now available, and so I downloaded the one for Ubuntu Cinnamon, burned it to a stick and booted it - guess what?
Code:
ubuntu-cinnamon@ubuntu-cinnamon:~$ uname -r
6.8.0-22-genericSo that is as close to newest as might easily be found, other than a couple of Arch rolling releases that might provide too much of a learning curve for this part of the OP's Linux Journey.
So @banana789 you could try using that one and see if its GParted recognises the Lexar, other than that I would go with whatever @osprey suggests, as I have every faith in his advice (except when I am confused, which some might say is par for the course but I turn them into toads).
If you use the Ubuntu Cinnamon for now, you would only need to wait until end of June for a similar kernel to be available from Linux Mint.
You can get the above from
https://cdimage.ubuntu.com/ubuntucinnamon/daily-live/current/
Also, I wrote a review on it here, if that helps
https://www.linux.org/threads/review-ubuntu-23-04-lunar-lobster-cinnamon-wizards-corner.45095/
That was with the point release 23.04, which I later updated to 23.10 with no problems.
Friday here in Oz so
Avagudweegend
Wizard
@wizardfromoz wrote:
Thanks Wiz for that research. This is an excellent opportunity to see whether the later kernel can see the lexar disk, and would be the best bet so far, by simply writing that ubuntu-cinnamon .iso to a usb as Wiz suggests, and booting it, and running gparted or the command in terminal: lsblk.
Last edited:
IT WORKS!!! it's picking up the drive this is great!! Thank you @wizardfromoz .. this hopefully would mean mont should get the update soon yea??
So idk what I've done but I've tried to manually partition the drive when trying to install and now the drive doesn't show up again ... Still shows up windows though .. oh god what have I done
I would not try that.
I would reboot again, with the USB stick inserted, see if lsblk (at Terminal) or GParted detects the Lexar, and if so, start the installer.
Go through the preliminary steps, and and when you get to the following screen, choose as follows
I have not got past that stage, as I don't want to install, and I note that they are using a new Installer which is a little different to me. But it should offer you an option to choose the Lexar. If it does, choose that for both the storage drive and the bootloader, and let the Installer do the partitioning.
If none of that works, you may have to look at Osprey's options on installing to the smaller drive for now. He may have ideas on the Windows cloning, as I have said, I have not.
Let us know how you go, but I may be unavailable for chunks of my Saturday (today).
Wizard
Osprey is an east-coast Aussie like me, and he will be on the same timezone, here it is currently 11:15am Saturday, he was around before but may be out shopping or elsewhere now. You'll understand we are all volunteers, and have outside lives. 
Typically with cloning solutions, the target drive or partition has to be at least the same size (or slightly larger) as the source drive or partition, so you would have to make that adjustment for both operations or "directions".
Typically with cloning solutions, the target drive or partition has to be at least the same size (or slightly larger) as the source drive or partition, so you would have to make that adjustment for both operations or "directions".
It certainly sounds like a very frustrating ride with such a near miss. You can clone MS to the larger drive and implement something like the proposal in the last paragraph of post #23, or some combination of the ideas in that post. Note the partitioning idea there, which if implemented may only need a single cloning of MS to the larger disk, instead of cloning there, and then back later when linux is able to see both disks.
As @wizardfromoz has mentioned in post #51, the size of the MS installation needs to be taken into account. In this case, the size of the MS installation is about half the larger disk, so that brings the idea of the partitioning of the other half of that disk into play.
If you wish to limit MS to a particular size smaller than the large disk, you would need to partition it using MS tools because MS sees it, and that would be the first thing to do, then clone (or install), and then you could check that the newly cloned/installed installation works.
For the process of cloning MS, you will need to research that since I can't help because I'm long out of date on MS matters (windows 95 was about it for me). Fortunately I see a lot of information online about it which appears well informed. I guess it's also possible to install MS to the new disk in a new installation using the MS product key, but you can research that one to be more informed than me.
The only other suggestion that comes to mind at the moment is to use a specialised rescue disk like systemrescue from: https://www.system-rescue.org/
The aspect of interest with a disk such as this is that it is specialised to see and recover systems. I can't vouch for systemrescue on this problem, but I do keep an updated version of the disk on hand for problems that arise from time to time here on a few machines.
If you click the red exclamation icon for each it should show information, you could tell us what they say.
Wondered, with the bananas If you are an east-coaster, then at least you may have a broad idea of what times Osprey and I may be online.
Wondered, with the bananas
If you are an east-coaster, then at least you may have a broad idea of what times Osprey and I may be online.
No worries, mate, that's what we do. Or try to do, lol.
I'll put my thinking cap on (and have a beer shortly) to see if I get any bright ideas, but it may take me some time.
The GParted warnings on the Microsoft partitions should not preclude you from engaging in a cloning operation, but perhaps a journey to the Microsoft Forums for the Windows version you have may assist with the cloning or imaging from one drive to another.
It might pay to not mention that you want to put Linux on the freed up drive, but you did not here me say that.
@banana789, thanks for the info in post #55.
It looks fine to me. Here's a rundown of some observations:
/dev/nvme0n1p1 is the EFI partition. It's almost certainly in proper order since the MS system works. Recommendations for the size of the EFI partition range from 256MB to 512MB. If you don't plan to have a lot of different distros installed, this partition is fine. The more distros on the system, the greater the room they take up with booting data on this partition. Dual booting is fine at this size.
/dev/nvme0n1p2 is the MS reserved partition, about which wikipedia says:
/dev/nvme0n1p3 holds the main MS installation
/dev/nvme0n1p4 is the MS hidden partition which holds the Windows Recovery Environment (WinRE). It can be used by MS to repair some problems that prevent the system from booting.
If you have two installations, MS and linux on separate drives, you would install the grub bootloader on the partition with the ESP partition, if you wanted grub to be able to boot either system. If you wanted to have the two systems completely separated, each with their own EFI partitions, then you would need to use the BIOS/UEFI boot menu to choose which one to boot. There are other details to consider here that I'll leave for the moment.
It looks fine to me. Here's a rundown of some observations:
/dev/nvme0n1p1 is the EFI partition. It's almost certainly in proper order since the MS system works. Recommendations for the size of the EFI partition range from 256MB to 512MB. If you don't plan to have a lot of different distros installed, this partition is fine. The more distros on the system, the greater the room they take up with booting data on this partition. Dual booting is fine at this size.
/dev/nvme0n1p2 is the MS reserved partition, about which wikipedia says:
It's either unknown to gparted or unformatted, and since the system works it's not likely damaged.
/dev/nvme0n1p3 holds the main MS installation
/dev/nvme0n1p4 is the MS hidden partition which holds the Windows Recovery Environment (WinRE). It can be used by MS to repair some problems that prevent the system from booting.
If you have two installations, MS and linux on separate drives, you would install the grub bootloader on the partition with the ESP partition, if you wanted grub to be able to boot either system. If you wanted to have the two systems completely separated, each with their own EFI partitions, then you would need to use the BIOS/UEFI boot menu to choose which one to boot. There are other details to consider here that I'll leave for the moment.
You may not have messed it up at all. I can only speculate about what happened, but as I understand it, you booted up the beta ubuntu-cinnamon disk, and it saw the larger disk. You reported that it works in post #46. Then, when trying to install the distro, it failed to see the disk.
There are two processes involved here, one being the live disk running, and the other, being the installation dependent on the installer software. It may be the case that the installer software had fewer or older probing tools than the programs in the installation itself. I know that this has occurred in the past with wifi detection when a user has booted up the live disk where the wifi worked, but after installation, the wifi failed and the drivers and/or firmware had to be separately installed. Bear in mind that you are dealing with beta software, which means it's by definition potentially quite unstable. That's a speculation at this point.
Very true, and like you said.. it's just a waiting game untill mint uses this kernel so for now it's just wiring and trying to see what distro to use until then .. a lot of people have told me to try arch Linux but it looks very hard to use.. I mean I could always try it and then overwrite the sad if need be since it's on its own and won't touch windows . What do you think ?
