Win 8.1 & Linux Mint 17 dual boot; different methods ?

[Xyga]

Hi!

I plan to install Linux Mint 17 on a laptop which already has Win 8.1 on it.
It's for me and other people who have asked me to do this for them but I havent done it in ages and previously only with old Ubuntus.

So I've read a bit about how to do this and turns out there are different methods/opinions about the best way to do it.

1. What will be the difference between installing 'alongside' Windows, and on a separate partition ?
2. Does installing 'alongside' means the two OS'es will share some fundamental folders ? (and you just select which OS you want to use on boot?)
3. In case it's 'alongside' shouldn't the Linux install use NTFS too ?

4. If I go for the completely separate partition install; which size for the swap zone would you recommend ? I have read all kinds of different stuff, like just 4GB, or 5GB or even twice the size of the RAM...
5. I quite don't remember but; was there a way to access the Windows folders even in this situation ? (separate partition install, assuming even different file systems of course)
6. Is it still as easy to find and install drivers as it was 5-6y ago ? (yeah haven't touched Linux in a long time :p)

Thanks in advance for your advice !

[HydrogLox]

Not sure if it is relevant but I just came across this yesterday:
How To Dual Boot Windows 8.1 And Linux Mint

4. If I go for the completely separate partition install; which size for the swap zone would you recommend ? I have read all kinds of different stuff, like just 4GB, or 5GB or even twice the size of the RAM...

Both references I came across actually were mentioning swap partitions (if that is the same thing) that were EQUAL to the size of the physical RAM.

That being said, there is still a lot I have to figure out and I'm expecting to go through a few configurations that I'll end up not being happy with so I'm predicting that as a side effect I'll become quite familiar with Macrium Reflect.

Edit: OK 5.1. What is Swap Space? - it's just virtual memory (equivalent to pagefile.sys in Windows), so "it depends". The article explains it in detail - basically you need more than your RAM if you have just a little RAM (2GB->4GB, 3GB->5GB), less than your RAM once you hit 32GB.

[beatsgo]

1. What will be the difference between installing 'alongside' Windows, and on a separate partition ?

Depends how you define this, which includes Virtual Machines. 'Alongside' would be on one HDD on 2 separate partitions. The other configuration is placing both OS on separate HDD and on their own partitions. If you're not clear what a partition is, partition is a section on a HDD dedicated space for something to operate it, like an OS. A HDD can have multiple partitions, which any OS will detect them as 'Drives'.

2. Does installing 'alongside' means the two OS'es will share some fundamental folders ? (and you just select which OS you want to use on boot?)

No, they will be on separate partitions (unless you went your way to installing Mint OS installer through Windows). See above for explanation of partition. Mint will see Windows partition, but not the other way around because....

3. In case it's 'alongside' shouldn't the Linux install use NTFS too ?

Typically Linux main partition is in ext3 format. I don't recall Windows 8 or below seeing this type of format (unless I live in the Stone Age or something)


(WOOHOOO, post 800 yo!)

[Xyga]

(I'll be working on single HDD's)

It's just that some guides have you take the 'alongside' option (first one on that pic);



It's not saying it will require another partition although it seems to require one to be created. I don't recall seeing this with Ubuntu.
Apparently if you choose that one it offers you the option tu use a disk partition managing tool.

Then there's the 'something else' option where you create the partition and install...using a different partition manager...

It's very confusing, none makes clear and obvious what the difference between the two methods is.
Confusion... that at least hasn't changed with Linux !

EDIT: @HydrogLox: well that seems simple for the swap I'll just do RAM+1GB then.

[noko_bombette]

The "alongside" option will automatically create the partitions, so probably you will only have to tell it the size you want for Linux.
For example: you have free 200 GB in your hard drive and you want to give 100 GB for Linux. The installer will create the partitions for you, that will probably be a ext3/4 for the system and a swap partition of the recommended size. Windows will be kept and, in the next boot, a boot menu will appear to select Linux or Windows.

The "something else" option means that you can manually set up the partitions, as in old Linux installers. Ubuntu, Mint, ... do a great job in automating the Linux setup and making it user friendly so you can almost forget about partitions.

[Xyga]

^ I see now, makes sense when formulated like that. Thanks !

God ! couldn't they have just said so !? Haha. ^^

[BuckoA51]

I did this on my laptop simply by purchasing a USB3 64gig drive. Mint runs reasonably well though I don't use it that often. Linux handling of NTFS has always been dire and I'd avoid it if possible, last time I used it in Mint I ended up with a corrupt mess of files (I've no idea how Windows EXT reading software performs).

[Xyga]

With a pal we just did the same as you (on a 64GB thumb drive) because we weren't certain the UEFI bios of his laptop (preinstalled Win8 ) would even allow Grub to appear.
Bothersome though as we haven't found how to boot directly from it without going though a Windows restart first (shift key pressed for accessing menu)

The reason is Safe Boot on that UEFI cannot be disabled, for some reason access seems to be locked.

Another option called 'Safe Boot Control' can be enabled/disabled, but evn though it's enabled by default we still cannnot disbale Safe Boot...

Any idea guys ? It's a relatively recent ASUS laptop with Win 8 (not 8.1) and bios v2.15.1226

[Kurozumi]

I never had a problem between EFI-Dual Boot on a Windows GPT Partition and a Linux GPT Partition, although i have no experience with Linux Mint (i'm an Arch Linux user).
Grub usually finds it, without any problems, too, ok on arch you need the os-prober package from the repo, but that's another story.
And you're of course right, you need to disable secure boot, or at least select the option, that the PK (platform key) can be changed. If i recall correctly the option is called "other OS" in the Secure Boot Menu, usually that's set to "Windows".

I've heard, that the function to change the PK isn't mandatory anymore for prebuilt PCs any kind of, but i'm not completely sure about that. So that could be bad news....

[BuckoA51]

Ah yes I'd already disabled secure boot as I wanted to use Truecrypt. Shouldn't cause any issues to do so except of course you lose the whole "secure against viruses" thing.. whatever

[Xyga]

Well turns out my pal's ASUS laptop has an UEFI bios with factory-locked Secure Boot, and it won't allow dual booting anything.

My ACER laptop's UEFI lets me disable whatever I want so it's okay, Grub shows on startup.

I guess for his ASUS we would have to find a workaround such as using legacy of flashing an alternative bios, dunno, but that's going a bit too far for what he wants.
So as mentioned earlier we've just made a live Mint 17.2 USB stick, it's 64Gb but I'm not sure how the space is used or not, if he can store files and make changes or not, we've set 4GB of space for persistent files without knowing what we were doing though lol.

By the way is Secure Boot really that important ? People go nuts when I say I've disabled mine...

[Kurozumi]

By the way is Secure Boot really that important ? People go nuts when I say I've disabled mine...

Are they like PC freaks, IT-People, the people that can do stuff with a command line or are they more like the usual persons and pseudo geeks? (no offense here)
If they are the second category, i guess their brains only think "oh crap, he's disabling something that says secure"....

It's not bad, because the bootloader is "signed" with a key, it makes it more secure, because it validates the boot routine. (all Mainboards that are Win 8 ready and upwards afaik have that feature)
But of course, if you want to install an alternative OS, you've got to disable it.

[Xyga]

Only 'pseudo' had that reaction, including an after-sales guy who scared my pal.
People who post on various Linux communities don't seem to give a shit.

Okay, well it's annoying to realize it is apprently impossible to disable on some pc's.

----------

I'll try to learn more about Linux on USB thumb drives. I've installed one but i don't know what can be done or not with it.

First annoying thing: of course it doesn't seem that I can just start the pc and boot from USB if there's not a key somewhere allowing me to access a boot device selection menu.
Again my ACER laptop's got one, the ASUS does not... WTF ASUS

[HydrogLox]

Well turns out my pal's ASUS laptop has an UEFI bios with factory-locked Secure Boot, and it won't allow dual booting anything.

My ACER laptop's UEFI lets me disable whatever I want so it's okay, Grub shows on startup.

It may be worthwhile to have a look at rEFInd Boot Manager. Its supposed to be able (with help) to deal with Secure Boot. Of course it is going to be easier to figure things out on a system where Secure Boot can be disabled temporarily. I'm going to give it a try once my SSD comes in and I'll do a clean install of Windows 10. For the time being I'm fiddling around with Windows 10 Pro that upgraded a Windows 7 installation - which raised some important points.

• Before starting create a Recovery Drive on a USB flash drive with RecoveryDrive.exe. Also image your Windows installation with something like Macrium Reflect in case the recovery drive isn't enough (already saved me some grief when bootrec.exe couldn't help me).
• Typically articles assume you have a pre-installed or clean install of Windows 8 or 10. When Windows 8/10 installs on a physical disk without any partitions it uses GPT (GUID Partition Table) which is needed for UEFI. If however Windows 8/10 is installed to a disk that already uses MBR (Master Boot Record) like when you are upgrading an existing Windows 7 installation, then Windows 8/10 simply stays with MBR and isn't able to support UEFI regardless of what the hardware/BIOS is capable of. The takeaway being that with Windows 8/10 that uses MBR you have to stick with a "alongside Windows 7" guide.
• GPT versus MBR directly affects the boot manager. On an MBR disk the boot loader has to be installed to the master boot record which is the first "device" on the disk. On a GPT disk the boot loader has to be installed to the partition marked as type "efi" (typically a small FAT32 partition) which may or may not be the first "device" on the disk. Note that rEFInd Boot Manager can only be used on GPT/UEFI disks.
• On an MBR disk there is the additional wrinkle that it can only support up to 4 primary partitions. After a Windows 10 upgrade often all those 4 partitions are already used up: (1) partition with system files (2) Windows Installation (3) Windows 10 backup partition (4) OEM recovery partition. Typically the OEM recovery partition is victimized after being backed up. As there is only one primary partition available it becomes necessary to set up an extended partition for all the linux partitions (e.g. root, home, swap area). Strangely enough the installation partition manager included in the Linux Mint 17 KDE distribution doesn't include the option to create an extended partition. So basically create an extended partition with the Windows diskpart.exe that uses all of the free space before you start the Mint installation. I used GParted to prep all the extended and logical partitions that I was going to use and then "Changed" the logical partitions during the Mint install to make them available.
• Typically the only way to change a disk from MBR to GPT (and vice versa) is by deleting all the partitions from the disk and starting over. However AOMEI Partition Assistant is supposed to be able to transform the partition styles in place.

TLDNR: "Dual Boot Windows 8.1 And Linux" guides assume a GPT/UEFI disk and do not apply to Windows 8/10 installations running on a legacy MBR disk (i.e. use the Windows 7 approach for those).

[HydrogLox]

Still not messing around with Secure Boot as there were way too many other fires to fight...

Ultimately after my first experiment I decided to ditch "Linux Mint 17 Qiana KDE Edition" because it would invariably freeze on me - most of the time before login and I don't think it was ever stable enough to let me get to a clean shutdown (even going straight to it after login). I didn't even try one of the Ubuntu flavors as they have too much in common with Mint and I figured that they would suffer the exact same problem. I figured with these "everything but the kitchen sink" cookie cutter distros I had no chance in hell as a neophyte to figure out what the problem with my particular hardware was. So I really only had one choice - to "Build Your Own Beast" with Arch Linux - hopefully carefully building up my configuration I would be able to catch the culprit and take corrective action on the spot. It had nothing to do with the fact that pacman is Arch's package manager.

For the impatient: The approach worked - apparently my laptop's Intel HD Graphics 4600/NVIDIA Quadro K2100M (2GB GDDR5 VRAM) Hybrid Graphics hardware was at the core of the problem.

I can't over-emphasize the importance of having a backup solution like macrium reflect around and making liberal backups of known good states of your partitions before making your "next big move". While in many cases (but still not all) it is possible to "hack yourself" back to a bootable system - it is just so much easier as a neophyte to simply blast yourself back to your last known good state when all of a sudden everything goes down the toilet. Creating backup images to an external USB3 drive from Windows 10 is pretty quick (and the same can be said for the restore).

I was also fortunate enough to get two handfuls of inexpensive 8GB Lexar USB2 flash drives during the current "back to shool" frenzy. They are a lot faster and more convenient than optical media drives for the various boot media required (installion, recovery, repair, etc.). Being paranoid I stuck to USB2 flash drives and always used them in a USB2 (not USB3 (SS)) port (under certain circumstances USB2 in USB3 would not boot). I used USBWriter on Windows 10 to prepare an Arch 4.1.6 installer USB drive and a GParted Live USB with the gparted-live-0.23.0-1-i586 ISO.

Replaced the Toshiba MQ01ACF050 500GB with a Samsung 850 Pro MZ-7KE512BW in the laptop and switched to "UEFI-only" in the BIOS. Booted the GParted Live USB and created an EXT4 partition consuming the latter half of the SSD in order to deny it to Windows 10. Then used the flash drive prepared by the Windows 10 media creation tool to install Windows 10 on the first half of the SSD.

Aside: I already upgraded the laptop previously via Windows Update from Windows 7 to Windows 10 on the Toshiba HDD. Strangely enough ProduKey wasn't able to recover the new Windows 10 product key - all I could get was the OEM (Windows 8.1) product key that resides in the BIOS - which of course doesn't work for a Windows 10 installation. Presumably the "Windows Update" upgrade registered my laptop's hardware profile with MS. So when I performed a clean install of Windows 10 the installation let me repeatedly "skip" the product code entry - but eventually my clean install activated successfully (still with no product key to be found with ProduKey).

Once Windows 10 was done there were 4 new partitons on the SSD:

1. 450 MiB Recovery (NTFS)
2. 100 MiB EFI System Partition (FAT32)
3. 16 MiB Microsoft Reserved (MSR) Partition (unknown)
4. 200+ GiB system (NTFS)

Windows 10 also elected to create a 128 MiB MSR at the beginning of my secondary HDD (Western Digital WD10SPCX).

Now Windows 10 was only using 25% of the EFI System partition - so it is possibly OK "as is" - but that partition will be mounted as the linux /boot partition and the Arch Beginner's Guide recommends 512 MiB for the EFI System Partition. GParted can't deal with the MSR partition and refused to resize the EFI System partition even when there was space. So:

• Use AOMEI Partition Assistant to deal with the NTFS, EFI and MSR partitions.
• Use GParted for the linux partitions (EXT4, swap partition, etc.).

Using AOMEI Partition Assistant I shrunk/moved the System partition further to the end, moved the 16 MiB MSR further to the end and expanded the EFI System Partition to 512 MiB.

Before starting the Arch Linux install I prepared the target partitions with GParted:

1. Deleted the EXT4 partition at the end of the SSD to make room.
2. Created a partiton for '/' (i.e. root).
3. Created a partition for '/var'.
4. Used the remaining space for a partition for '/home'.
5. Created a 32 GiB swap space at the end of my secondary HDD space. Given that I'm running with 32 GB of RAM I'm not too concerned about the swap space being on a slow 5400 rpm drive. I don't expect that it will ever get used - it is simply there of the "compatibility reasons" (whatever...).
6. ... and remember the existing EFI system partition will become your '/boot' partition.

There are no hard and fast rules about the partition sizes and some people simply use a single partition for '/', '/var', and '/home'. I have resized these partitions multiple times because I like some "head room" (partially for dealing with future bad clusters) - but most of my allocations are probably insane overkill. The current installation - Arch Linux (1 user set up) + Gnome 3.16 (& extras)+ Chromium + Sublime Text 2:

• /boot: 512 MiB / 57 MiB used
• /: 64 GiB / 147 MiB used (GParted shows 2.4 GiB used - but I blame that on the other mounted partitions).
• /var: 32 GiB / 1.8 GiB used
• /home: 142 GiB / 2.5 GiB used

Once all the partitions were prepared I simply followed the relevant sections of the Arch Beginners Guide to finish the basic installation - I ended up using systemd-boot as the boot loader.

And guess what - the kernel would still freak out 2 out of 3 boot ups even with this minimal configuration. At least occasionally I had a boot that would let me fix some stuff. At this point I found out about Intel/AMD microcode (actually I should have paid closer attention to the Beginner's Guide). Microcode is loaded into the CPU to address hardware bugs. Typically this is done by the BIOS but linux has it's own mechanism for updating (volatile) microcode so that the newest microcode can be loaded even before the hardware BIOS is updated. In my case it turned out that my recently updated BIOS already loaded the most recent Intel microcode update for my Intel Core i7-4900MQ.

But then I noticed that the kernel module nouveau would often complain just before the kernel would launch into a tyrade. Nouveau is the open source module for NVIDIA graphics - not to be confused with the proprietary NVIDIA module. Once I blacklisted the nouveau module, the kernel tyrades stopped - the problem seemed to be addressed - for now.

I went ahead and installed the NVIDIA module. Sailing was still smooth - time to install Gnome 3.16 - which borked the configuration. Arch would only boot into an infinite Gnome 3.16 "Oh no! Something has gone wrong" cycle. Using the Arch Live USB drive I had to disable the Gnome Display Manager to regain control over the boot process.

I consulted an alternate guide that made it clear that all wasn't well. For some reason I stumbled onto bumblebee which seemed to address my particular hardware situation. After installing bumblebee, X11 started to work and Gnome was happy. After that installing Chromium (and gSoftware [pacman -S gnome-software]) was a snap.