Just got Win 10 Pro & a Crucial SSD for my P750DM-G, but 0x080300024?

Hi all,

So I just got Windows 10 Pro, and a Crucial M.2 2260-size 250GB SSD. I used the Windows Media Creation tool to put an installer on a 32GB flash card I had laying around, then I booted into Linux and made a 32 GiB Linux-Swap partition and a 32 GiB Ext4 partition to reserve space for Linux, leaving 168.9 GiB available for Windows.

But, when I try to set it up (with custom install) to go on that partition, I get "We couldn't install Windows in the location you chose. Please check your media drive. Here's more info about what happened: 0x80300024."

I was looking online a little just now, and some ideas people gave (for different computers, also sometimes installing to a HDD) included physically removing other drives besides the one I'm installing to, or emptying the install drive of partitions and letting Windows do its thing. I'm going to try removing my 2TB HDD right now, but if it comes to the 2nd option, I hope that I can leave about 64 GB of space for Linux at the beginning of the drive preferably?

Also, in case it matters, when I first set up the SSD upon booting in Linux, I set the partition table type as MSDOS. Should I have left it blank? I know now, upon clicking the other partitions in the Windows installer where you select the partition, and seeing the error messages in the info popups, that it won't let you install to a GPT-formatted disk (which is what my 2TB HDD is set up as). (I didn't try installing it there.)

I think I remember something somewhere about some people needing to install a driver for Windows 7 install through USB, but I wouldn't think Windows 10 would need that?

What else should I try, besides removing the other hard drive and retrying the install, if that doesn't work? I don't have an external optical drive for the laptop. (One thing I thought of earlier was hooking up my desktop's blu-ray writer to the laptop's second HDD sata port, while powering it off the desktop's PSU, but I hope I don't need to implement a ghetto solution like that. I do have a Windows 10 DVD that I received today.)



Edit: So far removing the 2TB drive has let me get past that error message, fingers crossed ...

If it's successful, then after I get Windows installed, I have a drivers optical disk from RJTech/Clevo. What's a good way to copy that to the SD card, using my desktop computer? Should I boot into Linux and clone the DVD drive's partition onto the SD card, or is there a way to do it from within Windows? Maybe a tool like YUMI might work? Or should I use the "ghetto" solution I mentioned earlier, by hooking up my desktop's Blu-Ray burner? (I'd use the DVD burner but I'm having problems with it, at least writing discs. It is like 8 years old, so maybe it's reached EOL?)


Also, I'm currently running the SSD (Crucial MX200 M.2.2260 250GB) without a thermal pad, as I didn't have one on hand. If it's necessary to have one, where would I get one? (I'm hoping it's not needed as this is a SATA based SSD, not PCI Express so shouldn't be as fast / hot, I hope.)

 

If you're using EFI, you need to install Windows first to a blank hard drive (it has to make its own partitions - recovery, boot, system reserved, and the actual install partition) and then after that you can shrink your partition using Linux or Disk Management in Windows (safer) and then install Linux in EFI as well. Windows won't install in EFI to a non-GPT drive as far as I'm aware.

If you're in legacy CSM mode, as long as you have an MBR drive, Windows should install fine but it's still best to let Windows make its own partition (just click on the free space and click next).

Generally speaking, its best practice to install Windows first and then Linux and let GRUB take over as the bootloader.

 

Ahh, I think I had disabled UEFI / secure boot in Bios. I set up my Crucial drive as msdos (that'd be Linux parliance for MBR, right?) and was able to install Windows on that. I briefly thought of setting it as GPT, but figured that msdos would be fine since the SSD isn't > 2 TB.

And I can still get to my existing Windows installation, and I didn't modify any bootloaders after install. I'm thinking about doing something, but there's no immediate urgency. One possible idea I have is using gparted (maybe from a live Linux environment from an SD card) to clone the grub bootloader to the SSD, then shrink the existing Linux install from 144 GiB to ~32 GiB or whatever I left available for it, and put it on the SSD. (If it'd be safer, I could clone it to some unused space on my 2 TB drive (besides the Linux partition & a swap partition I have a 1 TB ntfs partition for data, with the rest being unallocated), shrink it there, then move that to the SSD.

For now, if I want to boot Windows, I just start the computer normally and it boots from the SSD. If I want to boot Linux, I spam F7 while in the POST screen, and select the HDD, which has Linux and the GRUB bootloader.

Also, as far as installing the drivers from the driver DVD goes, copying the file structure from the DVD to a SD card using my desktop PC worked fine - I even put it in a subfolder on the same card I used to install Windows 10 on the laptop, and it was fine with that. (I've almost thought too about putting the Windows install disk on the SSD itself in another partition, too, but for now I don't think I'll do that. I briefly thought about plugging it into my desktop (my ASRock Z97 Extreme6 has an M.2 slot) and doing it there, as well, but I don't know that the Windows Media Creation tool would let me create a partition on the SSD, or use a pre-created-by-gparted partition on said SSD.)

 

I wouldn't clone GRUB. It really doesn't like being messed with. Honestly if it isn't a huge inconvenience to use F7, you can keep doing that (you don't have to spam it by the way, just hold it down as soon as you turn the machine on and it will pick it up) or you can just reinstall GRUB. I've always opted for the easiest route which meant that I used F7 rather than risking breaking my MBR or GRUB both of which I've done many times and one of the only advantages of EFI booting I can think of (EFI boot partitions can store multiple EFI boot entries, in fact the only way to remove them is with a special program that can read the partition and manually remove them unless you delete the partition itself - with MBR, you could still break GRUB even if it was on a different partition).

Depending on what you're doing, it may not make sense to put Linux on your SSD. Linux is so fast that I don't notice a huge difference between SSD and HDD really.

 

Ah, okay, I'll leave it the way it is then. As it is now, it apparently looks starting in SATA0 for the boot device, which is where the SSD is. The HDD is in SATA2. I haven't changed anything in the Bios, so now I'm assuming that previously, since it didn't find anything in SATA0, it looked in SATA1, found nothing, then there was the bootable HDD in SATA2.

The SSD, in SATA0, has Windows on it, and the HDD, in SATA2, has Linux on it, plus the Linux Swap (I'm thinking of moving that to the SSD - should I? I left room for it.), a 1TB NTFS partition for data and about 600-700 MB of unallocated space. (I had left the unallocated space cause I was going on a camping trip over Christmas weekend, planning to copy files from some 256GB SD cards. I wasn't completely sure if Linux would balk at using the file system to copy from the card to the hard drive, so my backup solution would have been to copy the partition in GParted each time I filled the card. As it turned out, the normal filesystem copy method worked so I didn't have to do that. I haven't resized the NTFS partition yet, though, and I'd almost rather play it safe by making another partition when I run out of space rather than resizing it. Or, I could put the HDD in my desktop, copy stuff to one of my 4TB drives, repartition the 2TB, then copy the stuff back & put the drive back in the laptop. Then when I run out of space again, there's the other 2.5" bay...)

I actually prefer the way it is now - default booting to Windows, and hitting F7 to get to Linux. Also I was thinking maybe leave GRUB on the HDD (since it's apparently messy to move it to the SSD), move Linux to the SSD and change GRUB to point accordingly, but from what you said, I think I'll leave Linux on the HDD ... at least until I run out of space on there maybe. (It's Lubuntu 15.10. I tried several others and most of them didn't work or had some features very broken. This one still has some broken stuff but at least it boots into the GUI at full resolution. Windows is turning out better in this case though. I'd still like to get Linux tweaked so everything works though, but I'm not really gonna worry about it right now.)

Speaking of boot behavior ... do you know a way to get a similar behavior on my desktop, so that I have to hit a key to choose what OS I boot? (And if I don't hit a key the menu wouldn't come up, it'd just go with the default.) I default to Windows, but I also have Linux on there, memtest86+, and a few other things in GRUB (or whichever bootloader I put in there, I think it's grub since it's a plain text menu) which are probably just different options on Linux mostly. All the active OS's are on the one SSD, although I do have a couple clones of Windows on one of my hard drives as backups. (I don't think I'd want to boot directly off them, though, except in an emergency.)

Now if I could run both OS's at the same time, that would be nice. Except I'd want more than 8GB of RAM when I do that. For example, start Windows, then from in there start Linux (either with VirtualBox or another program). Then, if for whatever reason I want to shut down Windows, I can do that, it hibernates Linux, or just goes straight to Linux without POSTing. (Maybe I'd need a bare-metal hypervisor for that, though? I was looking some time ago, but didn't see anything that I like - free & open source, only needs the equivalent of a 386SX-16 CPU (speed, not architecture) and 1 MB PC-66 SDRAM or similar to run by itself, so as not to take resources away from the main OS's I'd be running, but supports the newest 64-bit OS's, etc.)