GPU/Grub issues

This is a sequel to Xrandr: Failed to get size of gamma for output default Apologies to @linesma for taking up his time, as I failed to really figure out what is the problem before asking.

Sometimes booting up into my system starts up the GPU (1060 6GB) just fine, sometimes it doesn’t, hence why the odd, regular restart did the trick. I’ve tried reinstalling the drivers many times, tried reseating the GPU and whatever else I thought of in the last two days. I don’t have a second Nvidia GPU to check if it’s an issue with my motherboard or another motherboard to see if it’s an issue with my GPU.

I can’t manually uninstall the drivers on the main installation, because they’re a dependency for Steam and things, which are dependencies for a bunch of other things…

I can’t even install a second, clean instance of Endeavour on a separate drive, to check if it’s an issue with the operating system, because Grub doesn’t want to work. This is what I get:

Installation Failed

Boost.Python error in job "bootloader"

Command 'grub-install --target=i386-pc --recheck --force /dev/nvme0n1' returned non-zero exit status 1.

Installing for i386-pc platform. grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. grub-install: error: embedding is not possible, but this is required for cross-disk install.


File "/usr/lib/calamares/modules/bootloader/", line 485, in run prepare_bootloader(fw_type)

  File "/usr/lib/calamares/modules/", line 457, in prepare_bootloader install_grub(efi_directory, fw_type)

  File "/usr/lib/calamares/modules/", line 362, in install_grub check_target_env_call(libcalamares.job.configuration["grubInstall"],
  File "<string>", line 6, in <module>

Manually updating Grub on the main install and booting into it throws me into a CLI, that I can log into and do whatever.

Installing the bootloader onto the same drive, again manually updating Grub from my main installation, then booting into it just throws me into the same CLI. I did install Nvidia drivers through Calamares both times, though doubt that’s relevant with this.

I honestly don’t know what to do or how to even begin fixing it. I’m just about ready to chuck the damn thing out the window and forget about technology all together. I’m not good at it.

Fixing Grub would be my first priority, any steps to troubleshoot this and get the system stable would be greatly appreciated.


:thinking: :face_with_raised_eyebrow:

No expert here, but aint’t i386 is a x32 architecture?
I assume your system is x64…So it’s some kind of weird mixture of architectures perhaps going on…
I don’t know, but it looks weird

Yeah, I have no clue why my system would be reporting itself a 32bit nor would I know how to change a python script within the Endeavour installer. Plus I’d confidently bet that any other distro would fail to install anyway, because this ain’t the installers fault.

Not sure wtf is going on really…Wait for someone more experienced to come.
Something is really messed up here :laughing:

But if that was me, at that point just to save time, i would probably:

  1. Backup all my data
  2. Check it again
  3. Verify it again
  4. Triple-check it just in case :upside_down_face:
  5. Make sure that in UEFI/BIOS all that secure boot / fast boot crap is turned off, and disks are in AHCI mode
  6. Wipe whole system disk and do GPT / ext4 partition, installing fresh Endeavour OS

Very important.

I remember I once backed up data, but for some reason, my school project files weren’t backed up. I ended up typing it again.

Since then I’ve caught the habit of running diff on output of tree on source and destination folders and even verifying hashes for the very important files.


I chucked most of my data into the hard drive that I wont touch, so it should be fine, unless I fat finger it – not unlikely, but I’ll take my chances.

I just want to avoid getting rid of the main install :smiley:

We’ll see what other gents will say.


Just checked BIOS as well, fast-boot always been off, disks are in AHCI.

The only extra thing I could disable is CSM.

Compatibility Support Module[edit]
The Compatibility Support Module (CSM) is a component of the UEFI firmware that provides legacy BIOS compatibility by emulating a BIOS environment, allowing legacy operating systems and some option ROMs that do not support UEFI to still be used.[48]

CSM also provides required legacy System Management Mode (SMM) functionality, called CompatibilitySmm, as an addition to features provided by the UEFI SMM. This is optional, and highly chipset and platform specific. An example of such a legacy SMM functionality is providing USB legacy support for keyboard and mouse, by emulating their classic PS/2 counterparts.[48]

Is it that?
I don’t know…I’d leave it enabled, coz personally HATE UEFI crap. But that’s up to you :slight_smile:


Yes it is. I can always flick it back on during my next boot from USB. Though I genuinely don’t know the difference between UEFI or BIOS and can’t even remotely tell the difference what uses which. They’re both just BIOS to me.

Summary of my view on it:

  1. UEFI requires creating additional small fat32 partition for boot stuff to stored in there

  2. It can give you a lot of errors in journal for unsupported stuff, coz each manufacturer tends to do their own crap and not following that vague specification…especially on laptops

So in a nutshell to me it’s just additional layer of problems, introduced to make things aka “more secure”, while in fact it’s just anothe bunch of corporate Intel / MS :ox: :poop:…Some people may disagree :upside_down_face:

More read:

1 Like


this GPT partition label contains no BIOS Boot Partition; embedding won’t be possible.

It looks as if you are trying to do a Legacy/MBR install on a disk with GPT. For that you will need a small unformatted partition like 8 MiB flagged as bios_grub at the beginning of the disk. I guess that is why the installation of the bootloader fails. The output of this command could be informative:

sudo parted -l

1 Like
Model: ATA Samsung SSD 860 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  500GB  500GB  primary  ext4         boot

Model: ATA WDC WD10EZEX-08W (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  1000GB  1000GB  ext4

Model: WDC WDS100T2B0C-00PXH0 (nvme)
Disk /dev/nvme0n1: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      2097kB  317MB   315MB   fat32              boot, esp
 2      317MB   1000GB  1000GB  ext4

Samsung is what I’m trying to get the secondary install on.

The NVMe is what my main install is on.

To me it looks like something in your partition could be wrongly set up. I suggest posting partition info and hardware. To get better help.

Another question is whether you created the live usb in legacy or uefi. That messed up my installs in the past.

1 Like

sudo parted -l is just above now. You’re welcome to request anything else, since I’m not sure what to give.

I just dd my images as I always have. That would make it… legacy?

I am a bit confounded, since:

Command ‘grub-install --target=i386-pc --recheck --force /dev/nvme0n1’ returned non-zero exit status 1.

indicates that you were trying to install on the NVME.

1 Like

One of your harddisks has a dos table, on which one did you try to instal EOS?

1 Like

@pebcak Correct me if I am wrong. It would be a good idea for him to remove his NVME drive. That drive has partition information on it that contains a “boot” flag. It would also keep that install intact. Especially since he is trying to install it on the Samsung 860 which is not the NVME drive but a Sata drive.


Yes, this is my 2nd attempt in trying to install a secondary instance of Endeavour. This time I was selecting the bootloader to go onto the NVMe which actually gave me an output.

Opposed to putting the bootloader on the same drive, which told me the install was successful, but I would boot only into a CLI after the install and manually updating Grub.

Apologies at my poor skills at explaining things.

1 Like

I don’t think that would matter that much. Personally I would create a GPT on /dev/sda and do an UEFI installation on that as well. Like this the grub will pick up on the other os as well. Otherwise with one installation in UEFI and another in Legacy one or the other will be left out of the Grub boot menu. Having ESP on each drive is not an issue.


@Oziach I do not know how to do what @pebcak suggests through the Calamares installer as I never use it. I do know how to do it as root in the terminal.