I went through the install process for bluefin, and all was fine, until I got this error:
I am trying to dual boot bluefin with windows 10. I’m not very experienced, so it would be nice if someone could give me an easy-to-understand explanation, thanks 
did you see this @equerty, that might help:
Thanks to the people that tried to help! It looks like the reliable option here is using bluefin as a standalone os, without windows. Windows has many issues on my laptop, so before doing anything can I ask, does bluefin automatically install drivers, and if not, how can I do it myself? Thanks again!
What kind of laptop is it? Can you get us a model number, GPU and wifi card will be most important.
It looks like the reliable option here is using bluefin as a standalone os, without windows.
I’m sorry for being late to the party, but I have very strong opinions on the topic that are at very strong odds with what seems to be the prevailing opinion. I have very specific requirements for my workstation (including the REQUIREMENT for Win10 to run some WMR VR stuff that is no longer supported under Win11) and had my partition strategy mapped out while the parts for my newest build shipped and long before I started shopping for a GNU/Linux distro. And why not? Custom partitioning and dual/multibooting were already well-supported options thirty-plus years ago and have only become more robust since, with UEFI and GPT. I am absolutely floored to come to these forums and to see people insisting that it isn’t any longer a supported option or even a possible one.
I worked through my install issues independently: for sure there’s at least one buggy install script in the upstream Fedora 40 install scripts that mangles the grub.cfg in such a way that no subsequent install of ANY Linux will work unless it’s done in such a way that the grub.cfg is overwritten instead of updated (eg, automatic install). My ego isn’t such that I feel my presence is some great boon, but had I shown up looking for help and been told “you can’t do that” I certainly wouldn’t have stuck around. I am not trying to direct anyone else to spend their time searching out the bugs or fighting the upstream politics to get a patch that makes it easier to run Windows because I am not presently engaged in doing it myself. But I wonder how many users have been turned away by the mantra of “you need extra disks to run Linux.” For an incipient distro, maybe one is too many.
For you, @equerty, I would break my habit of putting diagnosis before treatment in the name of expediency. Instead of spending a bunch of time trying to figure out if you’re getting the same grub.cfg corruption, I would have you just delete the entire bootloader and reinstall: I recommend you try rebooting Windows and mounting your ESP. You can for sure assign it a letter in diskpart or possibly also in the disk management gui tool. I recommend you then go into the EFI folder and delete the Fedora subdirectory entirely. Then try the reinstall process again and it will probably work fine with your custom partitions and dual-boot preferences.
If it doesn’t work, you have a couple of good options. The easiest would be to attempt installing from an older image (eg, Silverblue 39) that probably didn’t yet have the install bug and once installed to rebase over to Bluefin 40 (which, astonishingly, I have also seen people in authority say is an unsupported option).
The most direct option, which would also probably get you some good hands-on as well as diagnostic info for the community to pore over, is to ctrl+alt+f2 (IIRC, but try other function keys if that doesn’t do the trick) into a virtual console from the fatal error and delve into the logs. The ones you’re interested in will mainly be anaconda, program, storage, packaging, and syslog. IIRC, all can be found in /tmp or in /var (eg try cd /tmp, less package.log). It would be useful to copy the entire contents of whichever folder you find them in for review, since they will be wiped when you reboot. You could write them to a USB (maybe even the USB you booted from) or to your windows partition (not blindly recommended, in the case it’s encrypted w/ bitlocker): fdisk -l and look for a good place, then mkdir /mnt/LOGS and mount /dev/[XXXXXX] /mnt/LOGS. If that works (it should), then I’d create a new directory (mkdir /mnt/LOGS/LOGS) and copy over every pertinent logfile I could find (cp -r /tmp /mnt/LOGS/LOGS), and grab some additional diagnostics (eg, fdisk -l > /mnt/LOGS/LOGS/fdisk.log, mount > /mnt/LOGS/LOGS/mount.log, etc). It would also possibly be useful to grab a backup of your ESP partition. It may already be mounted at /boot/efi, but you could mount it yourself using the same procedure you used for your backup media (just give it a new folder name instead of LOGS). When you’re done collecting data, unmount whatever partitions you mounted using unmount /mnt/[FOLDERNAME] and you’re good to reboot. None of that effort will directly solve your problem, of course, but it will give you some good troubleshooting data.
