I'm helping a friend in chicago into the world of linux, but we've hit some issues. I have never learned how to do UEFI boot. So when we install I know we need something of a 500MB ESP partition and then the other things, but past that I have no damn clue. We're installing Kubuntu so he has a nice big DE to play with. When he tries to boot he doesn't get the systemD boot select or grub or anything, just straight to windows, and then when he hits F11 and selects linux from there it just drops to the grub command line.
We're trying to set up separated root and home for him. He has an NVME SSD and then a 1TB drive. This is the scheme we've been trying to do.
Again, we try to boot and it just goes to windows or drops to grub rescue. I don't know what to do other than just switch the system over to bios mode, but will that fuck up the windows boot? We can't reinstall windows to fix that if it does and fuck if I know.
You know, I just thought of secure boot. Can we turn secure boot off and not have windows freak the fuck out? I know windows is a whiney child with these things.
And like its not like we're doing the partitions wrong. I know we need the ESP partition only... We're just missing something.
What motherboard does your friend have? Depending on the motherboard you would need to turn secure boot off you should be able to do that by deleting the PK key in bios.
The NVME drive is recognized in Ubuntu using a different convention. Instead of /dev/sda, /dev/sdb, etc. you get /dev/nvme0n1, /dev/nvme0n2 etc. Note the first drive is n1. The partitions within the drives are p1, p2, etc.
Grub should be installed in the MBR of the drive, not on the partitions. Ubuntu installed seems to get confused by the 0 in the drive identifier and tries to install grub in /dev/nvme and fails.
One can manually set to the correct device name /dev/nvme0n1 during installation. Or use the command:
Code: [View] sudo grub-install /dev/nvme0n1 Note, it is just /dev/nvme0n1. There is no p1 at the end.
No you definitely cannot. If windows was installed as a UEFI OS on a GPT partition it won't boot if you switch the system to Legacy mode only in the UEFI. There's no MBR on GPT partitions and so when your BIOS tries to boot the OS it won't find anything. If you already have windows it means you have an ESP, so you can just configure the ubuntu installer to mount that at /boot/efi. If you're not encrypting your root drive you just need a / partition and potentially a swap and you're good to go.
@shawnanastasio Care to explain further? There's no MBR on GPT partitions and so when your BIOS tries to boot the OS it won't find anything. Last time I checked MBR vs GPT only had a difference of size of the hard drive. I am curious to see how windows being on ESP, has anything to do with dual booting especially since it will be a dual boot with separate partitions. Assuming the already installed Windows 10 was assigned to ESP during installation most if not all nowadays run legacy mode. I thought the option to boot UEFI was to just get Ubuntu installed.? I apologise if it sounds like I'm disagreeing with you I'm just curious how you came to that conclusion.
On legacy BIOS systems with MBR drives, the boot process looks something like this: - System is powered on - System initializes hardware - System jumps to code at a fixed offset on the hard drive (called the MBR, or Master Boot Record) - MBR code loads and jumps to operating system
With UEFI, it's a bit different: - System is powered on - System initializes hardware - System mounts all ESP (FAT32) partitions - System looks for EFI binaries in the /BOOT/ folder of all mounted partitions - System loads one of the binaries into memory (as defined by the boot order) and executes it - The binary continues to load the OS
The main difference here is that with MBR, the bootloader code is expected to be at a fixed offset (the Master Boot Record), whereas on UEFI it's expected to be on a FAT32 partition as a PE binary. The two systems are certainly not compatible with each other (except for shudder GPT/MBR hybrid drives).
His best bet without reinstalling Windows as a Legacy/MBR OS would be to get Linux installed as a UEFI/GPT OS. I've done this on dozens of machines (including the one i'm typing on) and most of the time it was easier than dual booting an MBR drive. Albeit, these were mostly running Fedora, which in my experience has a much easier time with UEFI drives in the installer.
The issue seems to be with Ubuntu's installer not correctly identifying the ESP partition and/or the /boot partition. I'd suggest he install the OS with the following configuration:
500MB FAT32 /boot/efi - This should already exist for windows, so you just need to set the mount point in the installer.
1GB EXT4/XFS /boot - You will need to create this.
?GB Whatever / - Your root drive (self-explanatory)
If I recall correctly, the Ubuntu installer also has a dropdown menu of drives to install the bootloader to on the same partitioning screen. Here you'll want to select the same drive (but not partition!) that has your ESP partition. Probably /dev/nvme0.
Grub should be installed in the MBR of the drive, not on the partitions. Ubuntu installed seems to get confused by the 0 in the drive identifier and tries to install grub in /dev/nvme and fails. One can manually set to the correct device name /dev/nvme0n1 during installation. Or use the command:
Code: [View] sudo grub-install /dev/nvme0n1 Note, it is just /dev/nvme0n1. There is no p1 at the end